[IT 도서 리뷰] 클린 아키텍처 (2부 벽돌부터 시작하기: 프로그래밍 패러다임)

책 정보

---

https://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24

3장 패러다임 개요

---

• 패러다임?
  • 프로그래밍을 하는 방법
  • 대체로 언어에는 독립적
  • 어떤 프로그래밍 구조를 사용할지, 그리고 언제 이 구조를 사용해야 하는지를 결정
• 구조적 프로그래밍
  • 최초로 적용된 패러다임
  • 다익스트라는 무분별한 점프(goto 문장)는 프로그램 구조에 해롭다는 사실을 제시
  • 이러한 점프들을 if/then/else와 do/while/until과 같이 더 익숙한 구조로 대체
  • 요약하면, 제어흐름의 직접적인 전환에 대해 규칙을 부과
• 객체 지향 프로그래밍
  • 요한 달과 크리스텐 니가드에 의해 등장
  • ALGOL 언어의 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견
  • 이 함수가 클래스의 생성자가 되었고, 지역 변수는 인스턴스 변수, 그리고 중첩 함수는 메서드가 되었음
  • 요약하면, 제어흐름의 간접적인 전환에 대해 규칙을 부과
• 함수형 프로그래밍
  • 최근에 겨우 도입되기 시작했지만, 가장 먼저 만들어짐
  • 알론조 처치에 의해 발명된 람다 계산법(수학적 문제를 해결하는 방법)에 영향을 받아 만들어짐
  • 람다 계산법읠 기초가 되는 개념은 불변성(심볼의 값이 변경되지 않음)
  • 요약하면, 할당문에 대해 규칙을 부과
• 생각할 거리
  • 패러다임은 무엇을 해야 할지보다 무엇을 해서는 안 되는지 말해줌
    • 패러다임은 각각 goto문, 함수 포인터, 할당문을 앗아감 
  • 프로그래밍 패러다임은 이렇게 딱 세가지.
  • 1958년부터 1968년까지 10년 동안 만들어졌으므로, 새롭게 등장할 패러다임은 없을 것!
• 결론
  • 아키텍처와 어떤 관계가 있는가? -> 모두 다 관계가 있음
  • 객체 지향: 아키텍처 경계를 넘나들기 위한 메커니즘으로 다형성 이용
  • 함수형: 데이터의 위치와 접근 방법에 대해 규칙을 부과
  • 구조적: 모듈의 기반 알고리즘으로 사용

4장 구조적 프로그래밍

---

• 다익스트라
  • 결혼 당시 네덜란드에서는 직업을 적어야 함
  • '프로그래머'가 인정받지 못해 '이론 물리학자'로 만족해야만 했음
  • 진공관 시대에 경력을 시작하며 원시적인 환경에서 위대한 발견을 해냄
• 증명
  • 초기에 인식한 문제
    • 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못한다
    • 아주 작은 세부사항이라도간과하면 프로그램이 동작하는 것처럼 보이더라도 결국엔 X
  • 증명이라는 수학적인 원리를 적용하여 해결하고자 함
    • 공리, 정리, 따름정리, 보조정리로 구성되는 유클리드 계층구조를 사용하는 방식을 프로그래머도 사용가능할 것이라 믿음
    • 즉, 프로그래머는 입증된 구조를 이용, 그리고 구조를 코드와 결합시키며, 코드가 올바르다는 사실을 증명
    • 연구 과정에서 goto 문장이 모듈을 더 작은 단위로 재귀적으로 분해하는 과정에서 방해가 생김을 발견 (분할 정복 사용 불가) -> if/then/else & do/while
    • 이러한 제어 구조는 순차 실행과 결합했을 때 특별!
  • 순차(sequence), 분기(selection), 반복(iteration)의 세 가지 구조만으로 표현가능
    • 순차: 단순 열거법
    • 분기: 열거법 재적용
    • 반복: 귀납법 사용
• 해로운 성명서
  • 논쟁끝에 goto 문장은 사라짐
• 기능적 분해
  • 프로그래머는 대규모 시스템을 모듈과 컴포넌트로 나눌 수 있고, 더 나아가 모듈과 컴포넌트는 입증할 수 있는 아주 작은 기능들로 세분화할 수 있음
• 엄밀한 증명은 없었다
  • 하지만 끝내 증명은 이루어지지 않음
  • 다만, 과학적 방법이 존재
• 과학이 구출하다
  • 과학은 근본적으로 수학과 다르다. 뉴턴의 운동 제2법칙이나 만유인력법칙의 경우에도 옳다고 증명할 수 없다. 시연 혹은 측정은 가능하지만 수학적으로는 증명할 수 없다.
• 테스트
  • "테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다." (다익스트라)
  • 이처럼 소프트웨어 개발은 수학적인 시도가 아니며 오히려 과학과 같다. 
  • 구조적 프로그래밍은 프로그램을 세부 집합으로 분해할 것을 강요 -> 테스트를 통해 거짓인지를 증명 -> 거짓 증명이 실패한다면, 충분히 참!
• 결론
  • 구조적 프로그래밍이 가치있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 능력
  • 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록(테스트하기 쉽도록) 만들기 위해 분주히 노력해야 한다.

5장 객체 지향 프로그래밍

---

• 객체 지향 프로그래밍
  • 흔히 "실제 세계를 모델링하는 새로운 방법"이라 하지만, 모호하다.
  • 캡슐화, 상속, 다형성. 이 세가지 개념은 필수!
• 캡슐화?
  • 데이터화 함수가 응집력 있게 구성된 집단을 서로 구분 지음
  • 데이터는 은닉되며, 일부 함수만이 외부에 노출 (private, public)
  • C에서 C++, 자바, C#으로 가면서 캡슐화는 훼손
• 상속?
  • 상속이란 단순히 어떤 변수와 함수를 하나의 유효 범위로 묶어서 재정의하는 일
• 다형성?
  • 함수를 가리키는 포인터를 응용한 것이 다형성
  • 함수에 대한 포인터를 직접 사용하면 포인터를 초기화해줘야 하는 관례가 있음. -> OO 언어는 이러한 관례를 없애줌
• 다형성이 가진 힘
  • 복사 프로그램 예제 (새로운 입출력 장치가 생긴 경우)
  • 새로운 장비에서도 복사 프로그램이 동작하도록 만들려면 어떻게 수정해야 하는가? -> 아무런 변경이 필요 없음
    • 복사 프로그램의 소스 코드는 입출력 드라이버의 소스 코드에 의존하지 않기 때문!
  • 프로그램은 장치 독립적이어야 한다. (프로그램이 다른 장치에서도 동일하게 동작해야 함)
• 의존성 역전
  • 전형적인 호출 트리 : main 함수가 고수준 함수 호출 -> 고수준 함수는 중간 함수 -> 중간 함수는 저수준 함수를 호출
  • C의 경우 #include, 자바는 import, C#에서는 using에 해당하는 부분 (main함수가 고수준 함수 호출)
  • 하지만 다형성이 끼어들면 달라진다. (의존성 역전)
  • 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않음 -> 소스 코드 의존성을 원하는 방향으로 설정할 수 있음
  • 따라서 컴포넌트들은 개별적이며 독립적으로 배포 가능함 -> 배포 독립성
  • 그렇게 되면, 서로 다른 팀에서 각 모듈을 독립적으로 개발가능 -> 개발 독립성
• 결론
  • OO란 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력
  • 플러그인 아키텍처 구성 가능
  • 독립성을 보장하여 독립적으로 개발하고 배포가 가능해짐

6장 함수형 프로그래밍

---

• 등장
  • 프로그래밍 그 자체보다 앞서 등장
  • 람다 계산법이 핵심 기반. (1930년대)
• 정수를 제곱하기
  • 자바는 가변 변수를 사용
  • 리스프(함수형 언어)에서는 x와 같은 변수가 한 번 초기화되면 절대로 변하지 않음
• 불변성과 아키텍처
  • 왜 중요한지? -> race condition, deadlock, concurrent update 문제가 모두 가변 변수로 인해 발생하기 때문
• 가변성의 분리
  • 불변성과 관련하여 가장 주요한 타협 : 애플리케이션 내부의 서비스를 가변 컴포넌트와 불변 컴포넌트로 분리하는 일
  • 불변 컴포넌트 -> 순수하게 함수형 방식으로 처리 & 가변 변수도 사용 X
  • 애플리케이션을 제대로 구조화하려면 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야 함
• 이벤트 소싱
  • 저장 공간과 처리 능력의 한계는 사라지고 있음
  • 예시) 고객 계좌 잔고 관리  은행 애플리케이션
    • 입금 & 출금 트랜잭션이 실행되면 잔고를 변경해야 함
    • 계좌 잔고를 변경하는 대신 트랜잭션 자체를 저장 (누군가 잔고 조회를 요청할 때마다 계좌 개설 시점부터 발생한 모든 트랜잭션을 단순히 더함)
    • 이 접근법은 터무니없음
    • 하지만 이 전략이 영원히 동작하도록 만들 필요는 없음 -> 이벤트 소싱 (상태가 아닌 트랜잭션을 저장하자는 전략)
    • 이벤트 소싱 : 상태가 아닌 트랜잭션을 저장하고, 상태가 필요해지면 단순히 상태의 시작점부터 모든 트랜잭션을 처리
    • 애플리케이션은 CRUD가 아니라 그저 CR만 수행
    • 변경과 삭제가 발생하지 않으므로 동시 업데이트 문제 또한 일어나지 않음
    • 저장 공간과 처리 능력이 충분하면 애플리케이션이 완전한 불변성을 갖도록 만들 수 있고, 따라서 완전한 함수형으로 만들 수 있음
    • 이 이야기가 여전히 터무니없게 들린다면, 소스 코드 버전 관리 시스템이 정확히 이 방식으로 동작한다는 사실을 떠올려 보면 도움이 될 것
• 결론
  • 구조적 프로그램은 제어흐름의 직접적인 전환에 부과되는 규율
  • 객체 지향 프로그램은 제어흐름의 간접적인 전환에 부과되는 규율
  • 함수형 프로그래밍은 변수 할당에 부과되는 규율
  • 1946년 앨런 튜링이 전자식 컴퓨터에서 실행할 거의 최초의 코드를 작성할 때 사용한 소프트웨어 규칙과 지금의 소프트웨어 규칙은 조금도 다르지 않음
  • 도구는 달라졌고 하드웨어도 변했지만, 소프트웨어의 핵심은 여전히 그대로
  • 소프트웨어는 순차(sequence), 분기(selection), 반복(iteration), 참조(indirection)로 구성됨. 그 이상도 이하도 아님