클린아키텍쳐 2부 3~4장

클린아키텍쳐 2부 3장 패러다임

구조적 프로그래밍

• 제어흐름의 직접적인 전환에 대해 규칙을 부과한다.
• 최초로 적용된 패러다임이다.

객체 지향 프로그래밍

• 제어흐름의 간접적인 전환에 대해 규칙을 부과한다.
• 알골언어의 함수 호출 스택 프레임을 힙으로 옮기면 함수 호출이 반환된 후에도 함수 내에 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견했다.
• 이 함수가 클래스의 생성자가 되었고, 지역변수는 인스턴스 변수, 그리고 중첩함수는 메서드가 되었다.

함수형 프로그래밍

• 할당문에 대해 규칙을 부과한다.
• 함수형 프로그래밍은 컴퓨터 프로그래밍 자체보다 먼저 등장했다.

---

정리

1. 패러다임은 무엇을 하면 안 되는 지를 알려준다.
2. 아키텍쳐의 경계를 넘나들기 위한 메커니즘으로 다형성을 이용한다.
3. 우리는 함수형 프로그래밍을 이용하여 데이터의 위치와 접근 방법에 대한 규칙을 부과한다.
4. 우리는 모듈 기반의 알고리즘으로 구조적 프로그래밍을 사용한다.
5. 세가지 패러다임과 아키텍쳐의 함수, 컴포넌트 분리, 데이터관리가 어떻게 연관되는지를 주목하자.

---

클린아키텍쳐 2부 4장 구조적 프로그래밍

증명

다익스트라가 초기에 인식한 문제

1. 프로그래밍은 어려우며 프로그래머는 프로그래밍을 잘 하지 못한다.
2. 프로그램은 너무 많은 세부사항을 담고 있고, 작은 세부사항이라도 간과하게 된다면 예상 외의 방식으로 실패하게 된다.

수학적인 원리인 증명을 통해 이런 문제를 해결하고자 했다.

1. 수학에서의 유클리드 계층 구조를 프로그래머도 사용할 수 있을 것이라고 믿었다.
2. 다익스트라는 공리,정리,다름정리,보조정리로 구성되는 유클리드 계층 구조를 만드려고 했다.
3. 프로그래머는 입증된 구조를 통해 구조를 코드와 결합하고 코드가 올바르다는 것을 스스로 증명하게 되는 방식을 기대했다.

기능적 분해

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

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

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

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

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

테스트

• 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다

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

• 테스트에 충분한 노력을 들였다면 테스트가 보장할 수 있는 것은 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있게 해주는 것이 전부다.

---

정리

1. 구조적 프로그램의 가치는 반증 가능한 단위를 만들 수 있는 능력이다.
2. 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.
3. 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 만들기 위해 분주히 노력해야 한다.