Clean Architecture 1~2부: 소개 & 프로그래밍 패러다임

로버트 C. 마틴의 클린 아키텍처를 읽고 내용 요약 및 생각 정리용 포스트

요약

1부

• 설계(저수준)와 아키텍처(고수준)로 구분하려 하지만 결국 둘의 경계는 명확하지 않다.
• 소프트웨어 시스템의 가치는 행위와 아키텍처(구조)로 나눌 수 있다. 업무 관리자는 행위(소프트웨어가 잘 돌아가나)를 중시하지만 개발자는 아키텍처를 중시해야 한다.
• 아키텍처가 변경 불가능하면 비용이 극단적으로 상승하는 원인이 되기 때문.
• 그러나 개발자도 행위를 중시하게 되는 경우가 많은데, 이는 긴급하지만 중요하지 않은 것을 상위 우선순위로 두는 것과 같다. -> 업무 관리자는 아키텍처의 중요성을 잘 모르므로, 아키텍처를 우선시하지 않아 생긴 문제는 개발자의 책임.

2부

• 구조적 프로그래밍:

1. 소프트웨어 개발은 수학이 아닌 과학 -> 어떤 서술(코드)가 참임을 증명하는 것이 아니라 틀렸음을 증명하려 하고, 충분한 테스트를 통해 틀린 점을 발견하지 못했으면 그것으로 프로그램의 목표는 달성된 것. (테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다)

2. 이러한 의식을 바탕으로, 모듈을 재귀적으로 분해해서 입증할 수 있는 작은 기능들로 세부화

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

• 객체 지향 프로그래밍:

1. 캡슐화는 생각과는 다르게 객체지향 언어에서 더 약화(C->JAVA). 이는 개발자가 캡슐화된 데이터를 우회해서 사용하지 않으리라는 믿음을 기반으로 했으나 결론적으로는 캡슐화가 약화됨. 상속은 객체지향 언어에서 새로 만든 개념은 아니지만 데이터 구조에 가면을 씌우는 일을 편리하게 하도록 도와줌.
2. 한편 다형성은 객체지향 언어에서 발전할 수 있었는데, 기존의 다형성은 함수에 대한 포인터를 사용해서 이루어졌으나 포인터 초기화에 대한 리스크가 항상 존재했음. 객체지향 언어는 이 리스크를 없애주었고, 플러그인 아키텍처를 쉽게 적용할 수 있도록 했다. 또한 객체지향 언어의 다형성으로 제어흐름에 반하는 의존성을 설계하기 쉬워졌고(의존성에 대한 절대적 제어 권한), 이는 배포 독립성 -> 개발 독립성으로 이어졌다.

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

• 함수형 프로그래밍:

1. 함수형 언어의 특징은 변수의 불변성. 불변성이 중요한 이유는 경합조건, 동시성 문제, 교착상태와 같은 문제는 모두 가변적 변수에 의해 일어나기 때문. 자원상의 문제로 모든 변수를 불변화할 수는 없기에 불변-가변 컴포넌트를 나누어 통신하도록 했다.
2. 그런데 이제 저장공간, 처리능력의 한계라는 제약은 거의 사라지고 있어, 상태가 아닌 트랜잭션만 저장하는 방식(이벤트 소싱)을 통해 완전한 함수형 애플리케이션도 가능해지고 있다.

으악 포인트

• "지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때 생산성이 낮아진다" (X)
  "지저분한 코드는 시간과 상관 없이 항상 더 느리다 (O)"
• 60년 전 엘런 튜링이 코드를 작성할 때의 규칙과 현재 규칙은 달라진 것이 없다. 결국 순차, 분기, 반복, 참조의 구조는 변하지 않은 것.

질문

• 객체지향 프로그래밍을 검색하면 캡슐화가 OOP의 특징 중 하나라고 서술된 글이 많이 보이는데, 그러면 이 글들은 다 틀렸다는 말인가?

소감

• 60년전 규칙과 현재 규칙이 달라진게 없는데 내 코드는 왜...

추가 사항