[클린 아키텍처] 3장 패러다임 개요 & 4장 구조적 프로그래밍

3~6장은 프로그래밍 패러다임을 다룬다.

 

2부 _ 프로그래밍 패러다임

---

소프트웨어 아키텍처는 코드로부터 시작한다. 따라서, 코드가 처음 작성된 시점의 프로그래밍부터 설명한다.

 

👀 프로그래밍의 역사... 다시보기 

1938년, 바이너리 언어를 사용하던 시기에도 반복문, 분기문, 할당문, 서브루틴, 스택 등의 구조를 이용했다. 

1940년 후반, 어셈블러(assembler)의 등장으로 바이너리 언어를 사용하지 않음이 가능해졌다.

1951년, 그레이스 호퍼는 컴파일러(complier)라는 용어를 만들고, 최초의 컴파일러인 A0 를 발명했다. 

이후 Fortran, COBOL, PL/1, SNOBOL, C, Pascal, C++, Java 등 언어가 우루루 나왔다.

 

이후, 프로그래밍 패러다임에도 혁신적인 변화가 일어났다.

프로그래밍 패러다임(paradigm) 은 "프로그래밍을 하는 방법"으로, 대체로 언어에는 독립적이다.

패러다임은 어떤 프로그래밍 구조를 사용할지, 언제 이 구조를 사용해야하는지를 결정한다. 

 

3장 패러다임 개요

---

✔︎ 구조적 프로그래밍

- 무분별한 점프(goto 문장)을 사용하지 않고, if/then/else 와 do/while/until 과 같은 제어구문을 사용하도록 하는 방식

- 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 

= goto 문장을 쓰지 못하도록 한다.

 

✔︎ 객체 지향 프로그래밍

- 함수 호출 스택 프레임(stack frame)을 힙(heap)으로 옮기면, 함수 호출이 반환된 후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견

- 즉, 힙에서 호출한 함수는 클래스의 생성자가 되었고, 오랫동안 유지된 지역 변수는 인스턴스 변수, 중첩 함수는 메서드가 되었다.

- 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.

= 함수 포인터를 특정 규칙에 따라 사용한다.

 

✔︎  함수형 프로그래밍

- 수학적 문제를 해결하는 과정에서 람다(lambda) 계산법을 발견했다. 

- 람다 계산법의 기초가 되는 개념은 불변성(immutability)으로, 심볼(symbol)의 값이 변경되지 않는다는 개념이다.

- 함수형 언어에는 할당문이 전혀 없다는 뜻과 같다. (변수 값을 변경하는 방법을 제공하지만 까다로운 조건내에서만 가능)

- 함수형 프로그래밍은 할당문에 대해 규칙을 부과한다.

= 할당문을 쓰지 못하도록 한다.

 

=> 각각의 세가지 프로그래밍 패러다임은 일종의 규칙을 부과함으로써 프로그래머에게서 특정 권한을 박탈하고 있다.

패러다임은 무엇을 해야할지 말하기보다는, 무엇을 해서는 안 되는지를 말해준다.

 

 

4장 구조적 프로그래밍

---

유명한 다익스트라.. Dijkstra 프로그래머의 이야기부터 시작한다. 👀

1952년 네덜란드 최초의 프로그래머, 프로그래머라는 직업이 없던 시절, 이론 물리학자라고 말해야했던 시절부터 프로그래밍의 원리나 과학을 증명하기 위해 노력한 사람이다. 

 

증명

데이크스트라가 초기에 인식한 문제

- 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘 하지 못한다.

- 프로그램은 너무 많은 세부사항을 담고 있고, 작은 세부사항이라도 간과하면 결국 예상 외의 방식으로 실패하곤 한다.

 

수학적인 원리 "증명(proof)"을 적용해 이런 문제를 해결하고자 했다.

- 수학에서의 유클리드 계층구조를 프로그래머도 사용할 수 있을거라고 믿었다.

- 그의 비전은 공리, 정리, 다름정리, 보조정리로 구성되는 유클리드 계층구조를 만드는 것이었다.

- 프로그래머는 입증된 구조를 이용, 이들 구조를 코드와 결합, 코드가 올바르다는 사실을 스스로 증명하게 되는 방식을 기대했다.

 

증명하기 위해서 단순한 알고리즘에 대해 기본적인 증명을 작성할 수 있는 기법을 고민했다.

- 이 과정에서 goto 문장이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에 방해가 되는 경우가 있음을 발견했다.

- 모듈을 분해할 수 없다면, 합리적으로 증명할 때 필수적인 분할 정복 접근법을 사용할 수 없게 된다.

- goto 문장을 사용하더라도, 방해가 되지 않는 경우는 분기(if/then/else) 와 반복(do/while) 이라는 단순한 제어 구조에 해당한다는 사실을 발견했다.

 

단순한 제어 구조는 순차 실행(sequential execution)과 결합했을 때 특별하다는 것을 깨달았다.

- 뵘과 야코피니는 모든 프로그램을 순차(sequence), 분기(selection), 반복(iteration) 이라는 세 가지 구조만으로 표현할 수 있다는 사실을 증명했다.

- 이 발견을 통해 모듈을 증명 가능하게 하는 제어 구조 == 모든 프로그램을 만들 수 있는 제어 구조의 최소 집합 임을 보여줬다.

-> 구조적 프로그래밍의 탄생 !

 

데이크스트라의 증명은 계속되고 유클리드 계층구조를 만들 수 있을 것이라 생각했다..

- 순차 구문 : 단순한 연거법을 이용해 입력부터 출력까지 순차적으로 추적

- 분기 : 분기를 통한 각 경로를 열거한 후 순차 구문과 같이 추적

- 반복 : 1의 경우가 올바름을 증명하고, N의 경우가 올바르다고 가정한 후 N+1의 경우도 증명하는 귀납법 사용

 

해로운 성명서 / 기능적 분해

- "goto 문의 해로움" 으로 편지를 써서 세 가지 제어 구조에 대한 자신의 의견을 피력했다.

- 이 논쟁이 10년 이상 지속되었지만.. 컴퓨터 언어가 진화하면서 goto 문장은 밀려나고 구조적 프로그래밍이 자리잡게 되었다.

- 구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었다.

- 이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻한다.

거대한 문제 기술서 - > 고수준의 기능들  - > 저수준의 함수들 - > 구조적 프로그래밍의 제어 구조로 표현 가능

- 1970 후반 ~ 1980 년대에 걸쳐 구조적 분석(structured analysis), 구조적 설계(structured design) 기법이 인기를 끌었다.

 

 

하지만.. 엄밀한 증명은 없었다.

프로그램 관점에서 정리에 대한 유클리드 계층구조는 만들어지지 않았다.

수학적인 증명만 있는 것이 아닌.. 과학적 방법(scientific method) 으로 올바른지를 입증할 수 있다.

 

- 수학 : 증명 가능한 서술이 참임을 입증하는 원리

- 과학 : 증명 가능한 서술이 거짓임을 입증하는 원리

 

데이크스트라는 "테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다" 고 말한 적이 있다.

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

=> 소프트웨어는 수학적인 구조를 다루는 듯 보이지만, 과학과 비슷하다고 볼 수 있다.

 

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 / 재귀적으로 분해할 것을 강요한다.

이후 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.

거짓임을 증명하는 테스트가 실패한다면, 이 기능들은 목표에 부합할만큼 충분히 참이라고 여겨진다.

 

 

결론 

구조적 프로그래밍의 가치는 "반증 가능한 단위를 만들어 낼 수 있는 능력" 덕분이다.

소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.

소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트가 쉽도록) 만들기 위해 분주히 노력해야 한다.

 

 

---

📝  마무리

소프트웨어의 동작 과정을 증명하고자 하는 시도들이 놀라웠고, 소프트웨어는 수학이 아닌 과학에 가깝다는 결론이 굉장히 와닿았다. 

증명 가능하도록 더 작은 구조로 쪼갠 것이, 모든 프로그램을 만들 수 있는 제어 구조의 최소 집합이라는 것도..

클린 코드에서 읽었던 메소드 작게 쪼개기, 클래스 단일 책임 원칙 등.. 모두 테스트를 위한 것이고, 모두 증명(반증)을 위한 것이다. 🤔