Clean Architecture (로버트 마틴 저) 독후감
클린 아키텍처를 정리했는데..
사실 이 글은 다른 사람들에게 의미가 없다.
내가 정리할 겸해서 정리한거지 절대 이 책은 교과서마냥 암기를 하면 안된다. 덤으로 클린 코드도 마찬가지다.
일단 정리한 데까지는 올려봐야겠다.
12장 이후부터 정리를 안 했는데, 정리하는데 드는 시간도 꽤 걸리고 뒤로 갈수록 흐름을 타야한다.
하나의 스토리를 전부 이해해야 한다는 것
클린아키텍처 - 1장
설계와 아키텍처는 같다.
생산성을 빠르게 하다보면 코드가 지저분해지는데 흔히 이걸 나중에 고치자 생각하고 늘리면 이끌려 다니는 자신을 발견할 수 있다. 처음부터 제대로 짜자.
2장 두 가지 가치에 대한 이야기
기능 : 긴급하지만 중요하지 않을 때도 있음
아키텍처 : 중요하지만 긴급하지 않음.
동작이 불가능하지만 변경이 쉬운 소프트웨어를 주었을때 이를 동작 시키는건 쉽지만 변경이 불가능하고 동작하는 소프트웨어를 주었을때 이를 고치는건 어렵다.
3장 패러다임 개요.
구조적 프로그래밍 : 제어의 흐름의 직접적인 전환에 규칙을 부여
객체지향 프로그래밍 : 제어의 흐름의 간접적인 전환에 규칙을 부여
함수형 프로그래밍 : 할당문이 대해 규칙을 부여
4장 구조적 프로그래밍
구조적 프로그래밍의 goto문은 모듈을 분해하는데 방해한다. 데이스트라는 이를 증명하기 위해 싸웠고 승리
테스트를 통과했다고해서 결함이 없는것이 아니다.
5장 객체지향 프로그래밍
‘세계를 모델링한다’ 가 무슨 의민데?
데이터와 함수의 구조도 아니다.
상속, 캡슐화는 객체지향이 아니여도 구현은 가능하다.
다형성을 손 쉽게 만들 수 있도록 도와줌. 이러한 방식 덕분에 의존성역전을 구현할 수 있었고, 의존성 역전을 통해 컴포넌트 단위로 배포하여 독립적인 역할을 수행할 수 있게함. 이것이 객체지향이 가진 힘.
6장 함수형 프로그래밍
- 함수형 언어에서 데이터는 바뀌지 않음. 바뀌려면 제약조건을 지켜야함. 그렇기에 불변성을 유 지할 수 있고 불변성 컴포넌트와 가변성 컴포넌트로 분리할 수 있음. 불변성을 가지면 동시성 문제를 해결할 수 있다.
저장공간과 처리속도가 무한하다면 이벤트소싱을 통하여 모든것을 불변성으로 만들 수 있고 완전한 함수형으로 만들 수 있다.
7장 SRP 단일책임원칙
- 단일책임원칙이란 하나의 모듈이 하나의 액터에 대해서만 책임을 갖는다.
예를 들어 어떤 함수에서 돌아가는 알고리즘이 다른 분리된 서비스에서도 사용되어서 수정했을때 에러가 나면 안됨. 이를 분리해야함.
여러개의 클래스로 나누거나 퍼사드 패턴을 사용하여 해결.
8장 OCP 개방폐쇄의 원칙
- 개방폐쇄원칙이란 변경에 있어서 기존 코드에서 수정하는 것은 적어야하고 확장되는 코드만 있어야 된다는 것이다. 즉, 변경이 있어서 기존 코드를 수정할 일을 최소화해서 유연하게 작동해야한다.
이를 지키기위해선 컴포넌트별로 중요도를 생각하여 배치하고 하위 중요도가 상위 중요도에 의존성을 가져 상위 컴포넌트에 대한 불변성을 지켜야한다.
또한 인터페이스와같은 의존성역전을 통해 업무경계를 침범하지 않게하고, 추이종속성을 방지한다.
9장 lsp 리스코프 치환 원칙
- 리스코프 치환 원칙이란 가능한한 상속 등을 통해서 의존성을 제거하는 것을 의미하는 것 같다.
예를 들어 구글과 계약을 해서 서비스를 구글에서 dest/table/abc.pdf로 보냈다고 하고
이게 표준이었다가 네이버에서는 실수로 destination/table/abc.pdf로 보낸다하면 if문으로 네이버와 구글을 분리할 것이 아니고 클래스로 분리하고 상속받거나 config를 추가해서 관리하는것.
10장 isp 인터페이스 분리 원칙
- 상속 받은 클래스에서 필요없는 기능을 가진 상위 클래스가 있다면 이를 인터페이스로 분리하여 의존성을 제거하자는것. 그러지 않으면 상위 클래스가 변경되면 하위도 재 컴파일을 할 수도 있게 되기 때문이다.
아키텍처적으로 프레임워크를 사용하는 개발자가 어떤 데이터베이스 모듈을 사용한다하면 프레임워크에 의존적이면서 데이터베이스에 의존덕이게 되어, 데이터베이스의 에러가 모든 곳에 정파되어 영향을 끼침 이를 해결하기 위해서는 과도한 의존성을 제거해야함.
11장 dip 의존성 역전 법칙
- 제어흐름이 의존성과 반대인 경우를 말함.
이를 코드수준에서 더 확실히 지키기 위해서는
구체 함수에 의존하지마라(오버라이드)
구체 클래스에 의존하지마라
구체 클래스에서 파생되지 마라.
가 있다.
인터페이스를 통해 의존성 역전을 만들어낼 수 있다.
하지만 결국 이렇게 만들어낸 구체 컴포넌트와 인터페이스의 집합인 추상 컴포넌트가 분리되다보면 하나의 구체 컴포넌트에서 모든 의존성이 쏠릴 수 있다. 이를 방지하기는 어려우며, 보통 main이라는 함수를 포함하는 컴포넌트가 이를 관리하도록 한다.
모바일로 집가면서 메모한거라 이쁘게 정리는 안되었네.. 정리에는 소질이 없다.
이 이후 부터는 정리를 하지 않았다.
내가 이 책을 오히려 훼손하고 있다고 생각이 들었다.
이 책은 암기서적이 아니고 이해를 하면서 넘어가야하는 서적이다. 꼭 읽으면서 이해해야한다.
클린 아키텍처, 클린 코드를 읽으니 어떻게 하면 실용적이고 간편하게 코드를 짤 수 있을까 생각이 들었다.
어제만 해도 테스트 코드만 4시간 짜고 있었다. 계속 지웠다 썼다 반복하였다.
그리고 프레임워크를 공부하는것은 큰 의미가 없다고 생각이 들었다.
지금은 fastapi로 사이드 프로젝트를 진행중이지만, 필요할때마다 도큐를 읽는게 좋고 도큐 자체를 공부하는건 내가 fastapi에 의존하게 된다는 것을 알았다.
그게 중요한게 아니고 로직을 어떻게 짤지를 고민하는데, 클린 코드에 대해서 생각하는데에 시간을 쓰는게 더 낫겠더라.
2회독으로 마무리했지만, 나중에 또 꺼내겠지.
다음 책은 실용주의 프로그래머이다. 추천받았다.