클린 아키텍처의 추천사

추천사의 원문 주소는 다음과 같다.

https://kevlinhenney.medium.com/architecture-as-journey-5e6af96ee102

 

책의 내용을 있는 그대로 요약하거나, 옮겨 적는 것은

저자나 번역가에 대한 예의가 아니라고 생각하여 가급적 하지 않는다.

 

추천사 자체보다는 공개된 구문들이니 예외...라고 생각하여, 기록하며 원문과 출처를 찾아본다.

아키텍처는 시스템을 구체화 하는 중요한 설계 결정을 표현하며,
그 결정의 중요도는 변경에 드는 비용으로 측정된다.

Software architecture represents the significant design decisions that shape a system, 
where significant is measured by cost of change.

- 그래디 부치 (Grady Booch)
- https://twitter.com/Grady_Booch/status/1071674450767048704

앞 문장은 원문을 읽어도 제대로 이해가 안 가는데, 뒷문장은 어느 정도 이해가 간다.

구조는 항상 변경되고, '그때는 옳았지만 지금은 아니다.'가 많이 발생한다.

구조를 바꾸는 과정은 적은 비용으로 이뤄져야 한다고 생각하고, 초기에 잘해둬야 한다.

 

좋은 아키텍처가 비싸다는 생각이 든다면,
나쁜 아키텍처를 시도해 보라.

If you think good architecture is expensive, try bad architecture.

- 브라이언 푸트(Brian Foote)와 조셉 요더(Josepth Yoder)
- http://www.laputan.org/mud/

좋은 아키텍처와 나쁜 아키텍처는 무엇일까?

완성된 결과물에 대해 '아쉽네...'라고 느끼는 부분들은 항상 있다.

 

과거의 나 혹은 다른 분들의 결과물이다.

 

최선을 다하지 않은 걸까? 아니다.

몰라서 안 한 걸까? 기일 수도 아닐 수도 있다.

그 당시에는 그게 어떤 이유던, 어떤 형태던 그 시점에서의 답이었던 것뿐이다.

 

 

아키텍처란 프로젝트 초기에 제대로 정할 수 있기를 바라는 결정사항이지만,
제대로 정할 가능성이 그 외 사항들보다 반드시 더 높지는 않다.

Architecture is the decisions that you wish you could get right early in a project, but that you are not
necessarily more likely to get them right than any other.

- 랄프 존슨(Ralph Johnson)

- http://files.catwell.info/misc/mirror/2003-martin-fowler-who-needs-an-architect.pdf
-> 마틴 파울러 아저씨가 쓴 아티클로 원문 아님

아키텍처는 정답이 없다고 생각한다.

다만 지금의 최선, 차선의 답안지가 나중에도 유효하리라는 보장이 없으니, 

변경에 비용을 최소화할 수 있게, 즉 잘 떼어 낼 수 있게...? 하는 게 필요해 보인다.

(msa 던 monolith 던 그런 걸 이야기하는 건 아니다.)

(나중을 위해 지금 당장 필요로 하지도 않는 고도화를 이야기하는 건 또 아니다. 이어서...)

 

 

그 외 추측성 일반화 (Speculative Generality)

이건 마틴 파울러 아저씨의 리팩터링 책에서 나온 이야기인 것 같다. (안 읽어봄)

https://refactoring.guru/smells/speculative-generality

당장 필요하지도 않은데 '이건 나중에 확장이나 구체화할 때 필요할 수도 있겠어'라는 것들(일반화)을 만들어 내지 마라

(코드던, 패키지던, 구조던)

 

이런 짓을 가끔 저지른다. (적절한 예 일지는 모르겠다.)

당장 notify 기능을 구현할 때 당장은 email로 notify 하는 기능이 필요한데, 미래의 언젠가 slack, http callback, 메신저 등등이 추가로 필요하지 않을까 해서 notifyEmail을 구현하기 앞서 notify 인터페이스를 고민한다.

 

물론 장점이 없지만은 않다.

정말 이 인터페이스의 추상 메서드가 notify만을 위한 필요한 정보들을 필요로 하는가? 하는 고민을 하긴 하게 된다.

하지만 당연하게도 전용 인터페이스가 될 수밖에 없다. 이후에 어떤 정보가 추가로 필요한지는 그때 가 봐야 알 수 있고 그때 가서 또 고쳐야 한다.

 

다만, 그런 고민 때문에 당장 해야 할 작업이 딜레이 되거나, 당장 필요로 하지 않으며 앞으로도 그럴 가능성이 낮은 부분을 붙잡고 시간을 쓰는 게 맞는가 계속 고민하게 된다.

(물론 나중에 가서는 왜 그때 안 해뒀을까 하는 일도 발생한다.)