[Clean Code] #11 시스템

테스트 주도 아키텍처 구축

코드 수준에서 아키텍처 관심사를 분리할 수 있으면, 테스트 주도 아키텍처를 구축할 수 있게 된다. 

 

테스트 주도 아키텍처를 통해 새로운 기술을 추가하면서 초기의 단순한 아키텍처에서 복잡한 아키텍처로 성장시켜나갈 수 있다.

 

의사결정을 최적화하라

모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.

모든 부분에서 한 사람이 모든 의사결정을 할 수는 없기 때문에 그 부분에 적합한 사람이 직접 의사결정을 하는 것이 바람직하다.

 

그리고 빠르게 결정을 내리는 것보다 최대한 많은 정보를 참고하여 최적의 결정을 내리기 위해 충분한 시간을 가지고 기다렸다가 결정을 내리는 방법 또한 바람직한 방법이다.

 

명백한 가치가 있을 때 표준을 현명하게 사용하라

 어떤 한 분야의 표준을 사용한 다는 것은 기존의 아이디어와 자료들을 사용하기 쉽고, 적합한 경험을 한 사람을 찾기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽다.

하지만 이 표준에 얽매여서 표준을 사용하려 했던 본연의 가치에 집중하지 못하게 될 때가 있다.

 

표준을 사용할때는 분명한 의도를 가지고, 실현하고자 하는 가치에 표준이 부합할 때사용하는 것이 좋다.

 

시스템은 도메인 특화 언어가 필요하다

도메인 특화 언어 (Domain-Specific Language, DSL)은 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다.

 

좋은 DSL은 도메인 개념과, 그 개념을 구현한 코드 사이에 존재하는 '의사소통 간극'을 줄여준다.

DSL을 효과적으로 사용하면 적절한 추상화 수준에서 코드 의도를 표현할 수 있다.

 

나의 결론

이번 장에서는 거의 절반 이상의 내용을 이해하지 못하고 읽은 것 같다.

그래서 몇 번을 다시 읽어보고 했지만... 🤯

 

하지만 저번 장부터 비슷한 말을 반복하고 있는 느낌이 들었다.

이번 장에서는 관심사로 표현이 되어있는 부분과, 저번 장에서는 '개념'이라고 표현되어있는 부분이

같은 의미를 내포하고 있는 단어가 아닐까 하는 생각을 계속했다.

 

컴포넌트든 메서드든 시스템이든 하나의 의도, 개념, 관심사를 가지고 있는 것이 클린 한 코드이다라는 점을 반복하고 있는 것 같다.

 

이번장은 다음에 다시 돌아와서 읽고 추가로 내용 정리를 해야겠다...