[클린코드] 11장 시스템

"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다."

- Ray Ozzie, 마이크로포스트 최고 기술 책임자

 

 

시스템 제작과 시스템 사용을 분리하라

소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.

 

 

1. Main 분리

• 생성과 관련된 코드응 모두 main이나 main이 호출하는 모듈로 옮긴다.
• 나머지 시스템은 모두 객체로 생성되었고, 모든 의존성이 연결되도록 한다.
• 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모르게 된다.

 

2. 팩토리

• 객체가 생성되는 시점을 애플리케이션이 결정할 때는 팩토리를 사용한다.
• 이런 경우 ABSTRACT FACTORY 패턴을 사용하여 객체를 생성한다.

 

3. 의존성 주입 (DI)

• 의존성을 주입하는 방법으로 설정자 메서드나 생성자 인수를 제공한다.
• DI 컨테이너는 필요한 객체의 인스턴스를 만든 후 생성자 인수나 설정자 메서드를 사용하여 의존성을 설정한다.

 

 

확장

소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리하여 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

 

 

테스트 주도 시스템 아키텍처 구축

• 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 아주 단순하면서도 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가는 것이 좋다. (엄청난 예시로 카카오톡과 라인이 있다.)
• 좋은 API는 걸리적거리지 않아야 한다. 그리하지 않으면 아키텍처에 발이 묶여 고객에게 최적의 가치를 효율적으로 제공하지 못하게 된다.

 

의사 결정을 최적화하라

• 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.
• 최대한 정보를 모아 최선을 결정을 내리기 위해서는 결정을 미루는 것이 최선의 방법이다.
• 성급한 결정은 불충분한 지식으로 내린 결정이다.

 

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

• 표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽다.
• 적절한 경험을 가진 사람을 구하기 쉽다.
• 좋은 아이디어를 캡슐화하기 쉽다.
• 컴포넌트를 엮기 쉽다.
• 하지만 만드는 시간이 너무 오래 걸린다.

 

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

• 좋은 DSL(도메인 특화 언어)은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 '의사소통 간극'을 줄여준다.
• 도메인 전문가가 사용하는 언어로 도메인 논리를 구현하면 도메인을 잘못 구현할 가능성이 줄어든다.
• 덕분에 개발자가 적절한 추상화 수준에서 코드 의도를 표현할 수 있다.

 

결론

• 시스템 역시 깨끗해야 한다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
• 모든 추상화 단계에서 의도를 명확히 표현해야 한다.
• 돌아가는 가장 단순한 수단을 사용하자.