클린 코드 11장 시스템

노개북 2기 완주 이후 Extra(공식 스케줄 외 나머지 부분 정리)

• 11장 시스템(pp.194~214)

요약 및 느낀 점

시스템 제작(construction)과 시스템 사용(use) 분리

• 준비과정과 런타임 로직을 분리해야 함
• 시작 단계에서 관심사(concern)를 분리
• 초기화 지연(lazy initialization), 계산 지연(lazy evaluation)
  • 장점
    • 불필요한 부하 줄임 -> 애플리케이션 시작 시간이 빨라짐
    • Null 반환할 일이 없음
  • 단점
    • 메서드가 생성자 인수에 명시적으로 의존
    • 책임이 둘이 됨 -> SRP 위반

*SRP=Single Responsibility Principle=단일 책임 원칙

p.196
체계적이고 탄탄한 시스템을 만들고 싶다면 흔히 쓰는 좀스럽고 손쉬운 기법으로 모듈성을 깨서는 절대로 안 된다.

Main 분리

• 생성 관련 코드 -> main, main이 호출하는 모듈에 위치
• 나머지 -> 모든 객체는 생성됐고 모든 의존성은 연결됐다고 가정
• 애플리케이션은 main이나 객체 생성 과정을 모름

팩토리

• Abstract factory 패턴 사용
• 애플리케이션은 객체 생성 시점은 알고, 생성 코드는 모름

의존성 주입 Dependency Injection, DI

• 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용
• 한 객체가 맡은 보조 책임을 새 객체에게 넘김
• 넘겨받은 책임만 맡음
• 따라서 SRP 맞음

확장

p.199
'처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다.

횡단(cross-cutting) 관심사

• 영속성 프레임워크와 도메인 논리의 모듈화
• 관점 지향 프로그래밍 Aspect-Oriented Programming, AOP
• 관점 Aspect 이란 특정 관심사를 지원하려면 특정지점 동작 방식을 일관성있게 바꿔야 한다는 것

자바 프록시 vs. 순수 자바 AOP 프레임워크 vs.AspectJ

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

• 코드 수준에서 아키텍처 관심시를 분리하면 가능해짐

p.211
좋은 API는 걸리적거리지 않아야 한다. 그래야 팀이 창의적인 노력을 사용자 스토리에 집중한다. 그리하지 않으면 아키텐처에 발이 묶어 고객에게 최적의 가치를 효율적으로 제공하지 못한다.

의사 결정 최적화하기

p.211
우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다.

명백한 가치(목적, 이유)가 있을때만 표준 사용

• 아무때나 아무데나 막 사용하지 말라.

도메인 특화 언어

• Domain-Specific Language, DSL
• 도메인 개념과 구현 코드 사이 의사소통 간극이 줄어듬

더 공부할 내용

• 테스트 전용 객체
• 시스템 아키텍처
• 팩토리 패턴
• 관점 지향 프로그래밍 AOP
• Plain Old Java Object, POJO
• up-front design
• Domain-Specific Language, DSL