[클린코드 요약] 11. 시스템

 소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다.

public Service getService() {
	if (service == null)
    	service = new ServiceImpl(...);
	return service;
}

 초기화 지연(Lazy Initialization) 혹은 계산 지연(Lazy Evaluation) 기법

• 실제로 필요해지기 전까진 객체를 생성하지 않으므로 불필요한 부하가 없고, 어떤 경우에도 null 포인터를 반환하지 않는다.
•  하지만 의존성의 문제도 있고, 일반 런타임 로직에다 객체 생성 로직을 섞어놓은 탓에 모든 실행 경로도 테스트해야 함. -> 단일 책임원칙을 깬다!

의존성 주입(Dependency Injection) : 사용과 제작을 분리하는 강력한 매커니즘 중 하나. 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용한 매커니즘. 초기 설정은 시스템 전체에서 필요하므로 대개 '책임질' 매커니즘으로 'main' 루틴이나 특수 컨테이너를 사용.

 AOP에서 관점이라는 모듈 구성 개념은 "특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다"라고 명시.

 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면 진정한 테스트 주도 아키텍처 구축이 가능해짐.

 '아주 단순하면서도' 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮음. 그렇다고 아무 방향 없이 프로젝트에 뛰어들란 말은 아니고, 변화하는 환경에 대처해 진로를 바꿀 능력도 반드시 유지해야 함.

 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어트림. 도메인 논리가 흐려지면 제품 품질이 떨어짐. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라짐.

 모든 추상화 단계에서 의도는 명확히 표현해야 함. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 매커니즘을 사용해 각 구현 관심사를 분리해야 함.