Clean Architecture 정리 - 2부 3, 4장

목차

3. 패러다임 개요

4. 구조적 프로그래밍

5. 객체 지향 프로그래밍

6. 함수형 프로그래밍

---

3장. 패러다임 개요

해당 장에서는, 2부에서 설명하는 세가지 패러다임을 간단히 설명한다.

또한, 패러다임은 무엇을 하지 말아야할지 규칙을 정해둔 것이라고 말한다.

---

4장. 구조적 프로그래밍

데이크스트라는 프로그램 관점에서 정리에 대한 유클리드 계층 구조를 만들고자 했다.
즉, 프로그램이 논리적으로 올바름을 가질 수 있도록, 마치 수학의 정리처럼 계층적으로 증명 가능한 구조를 만들고 싶어 했다.

이를 위해 코드의 올바름을 증명할 수 있는 방법을 고민했고, 분할 정복을 사용해 모듈을 재귀적으로 분해하는 접근을 시도했다.

 

데이크스트라는 연구를 통해, 모듈을 재귀적으로 분해해 증명하는 과정에서 goto 문장이 방해가 될 수 있다는 사실을 발견했다.
이는 프로그램의 흐름을 예측 불가능하게 만들고, 증명 과정을 복잡하게 꼬이게 했다.

반면, 일부 경우에는 goto를 사용하더라도 증명 과정에 방해가 되지 않았다.
그는 이러한 좋은 goto 사용의 예외가 if/then/else나 do/while과 같은 단순한 분기·반복 구조라는 점을 확인했다.

 

데이크스트라는 세 가지 기본 제어 구조만을 사용하면 코드의 증명이 가능하다는 사실을 발견했다.

또한, 세가지 제어 구조또한 올바름을 입증하였다.(이 부분은 생략한다)
세 가지는 다음과 같다.

• 순차(sequential execution): 단순히 한 줄씩 수행되는 구조
• 분기(selection)
• 반복(iteration)

 

이러한 생각을 기반으로 학술지에 "goto문의 해로움"이라는 제목으로 편지를 보냈고, 이 편지는 글로 실렸다.

이 글은 순차 구문, 분기, 반복이라는 세가지 제어 구조에 대한 데이크스트라의 의견을 피력했다.

 

결과적으로, 컴퓨터 언어가 진화하면서 goto 문장은 마침내 거의 사라졌다.

 

데이크스트라는 결국 프로그램 관점에서 정리에 대한 유클리드 계층 구조를 만들지는 못했다.

또한, 대개의 프로그래머도 세세한 기능 모두를 엄밀히 증명하는 것이 이익이라고 생각하지 않는다.

엄밀히 증명하는 대신, 테스트를 사용한다.

 

테스트는 프로그램에 잘못되었음을 증명할 수 있지만, 맞다고 증명할 수는 없다.

테스트에 충분한 노력을 들였다면, 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있는 정도이다.

 

하지만, 프로그램이 잘못되었음을 증명함의 올바름을 증명하려면, 입증 가능한 프로그램에만 적용할 수 있다.

즉 goto문을 사용된 코드라면, 테스트 또한 올바르게 작동한다고 확신할 수 없다.

 

=> goto문을 사용하지 마라!

 

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 2부의 3, 4장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.