[Clean Code] 11장. 시스템

11장. 시스템

목차

도시를 세운다면?

• 도시는 각 분야를 관리하는 팀이 있기에 돌아갈 수 있다
• 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다
• 이 장에서는? 높은 추상화수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 보여준다

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

• 제작(construction)과 사용(use)은 완전히 다르다.
  • 건축물이 만들어질때의 모습과, 완성되어서 사용자가 사용할때의 모습은 완전히 다르다

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

• 런타임 로직과 준비 과정이 뒤섞여있는 예시

public Service getService() {
    if (service == null)
        service = new MyServiceImple(...);
    return service;
}
// Lazy Initialization (초기화 지연) or Lazy Evaluation의 예시

• 장점
  • 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하 X, 따라서 App 실행속도가 빨라진다.
  • null을 반환하지 않는다.
• 단점
  • MyServiceImpl의 생성자에 의존하게 된다.
  • 실행시에 MyServiceImpl 객체를 안써도, 의존성을 해결하지 않으면 컴파일이 안된다.
  • service가 null인경우, 아닌경우 모두 테스트를 해야하므로, SRP가 깨지게 된다. (메서드가 작업을 두 가지 이상 수행한다)
• 그렇다면 어떻게 분리를 하는가?
  • Main 분리
    • 생성과 관련한 코드가 모두 main이나, main이 호출하는 모듈에서 이뤄진다고 가정
    • 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다.
  • 추상 팩토리 패턴
    • 객체가 생성되는 시점을 App에서 결정하고 싶을때 사용
  • 의존성 주입
    • 제어역전(IoC) 기법을 의존성 관리에 적용한 메커니즘이다.
    • 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.
    • 새로운 객체는 넘겨받은 책임만 맡으므로 SRP를 지키게 된다.

확장

• 처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다
• 소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리하면, 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

횡단(cross-cutting) 관심사

• 관심사란 프로그래밍 관점에서 하나의 기능이나 모듈이다
• 이때 횡단 관심사는 다른 관심사에 영향을 주는 프로그램의 aspect 이다
• 예시
  • 의무기록을 관리하기 위한 app에서 record의 인덱싱은 핵심 관심사(core concerns)이다. 한편 변경 이력 기록을 위한 DB 로깅, 인증시스템은 횡단(cross-cutting) 관심사이고, 이들을 프로그램의 더 많은 부분과 상호작용 한다.
• 횡단관심사도 프로그래밍 관점에서 보면 중복이라는 문제가 존재.
• 이러한 문제점을 해결하기 위해 AOP(관점지향 프로그래밍, Aspect Oriented Programming) 기법이 나오게 되었다.
• 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다
• AOP는 OOP를 좀 더 보완해주는 방식이다.
• aspect이라는 모듈 구성 개념은 특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다. 라고 명시한다.
• AOP는 횡단관심사들을 모듈화해서 중복을 최소화하는 프로그래밍 기법.
• 자바에서 사용하는 aspect or aspect와 유사한 메커니즘

자바 프록시

• 단순한 상황에 적합하다.
• 개별 객체나, 클래스에서 메서드 호출을 감싸는 경우가 좋은 예다.
• 단점
  • 코드의 ‘양’과 크기가 거대해진다.
  • 깨끗한 코드를 작성하기 어렵다.

순수 자바 AOP 프레임워크

• 순수 자바 관점을 구현하는 스프링 AOP같은 자바 framework는 내부적으로 프록시를 사용한다.
• Spring은 business logic을 POJO(Plain old java object)로 구현했다.

AspectJ 관점

• concern을 aspect로 분리하는 AspectJ언어 사용
• 자바 언어의 확장이다. 하지만 이걸 위해서 새 언어 문법과 사용법을 익혀야 한다.

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

• 아주 단순하면서도 분리된 아키텍처로 시작해서, 조금씩 확장해 나가는 방식
• 빠르게 실패하고, 피드백을 통한 빠른 성장..
• 하지만, 일반적인 범위, 목표, 일정과 결과르 내놓을 시스템의 일반적 구조도 생각한다는 전제가 깔려있다.

의사 결정을 최적화 하라

• 가능한 마지막 순간까지 결정을 미루는 방법이 최선일 수 있다.
  • 최대한 정보를 모아서 결정을 내리자.

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

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

• SQL, CSS, Regular Expression ...

내가 배운점

• 깨끗하지 못한 아키텍처는 도메인 논리를 흐리고 기민성을 떨어뜨린다. (결론임)
• Cross-cutting 관심사가 무엇인지? (아래 링크를 처음으로 약간 알아들을 수 있게 됨)
  • https://ko.reactjs.org/docs/higher-order-components.html#use-hocs-for-cross-cutting-concerns
• AOP는 횡단 관심사의 중복성을 해결하기 위해 등장했구나.
• 의존성 주입에서 다룬, 제어 역전은 결국 SRP를 만족시키는구나. 즉 객체 지향 설계를 위한 5가지 원칙(SOLID)을 계속 지켜가며 발전이 되었구나.
• 자바 프록시 등등.. FE를 공부하는 입장에서는 잘 와닿지 않았다.