[Clean Code] 11장 시스템

도시를 세운다면?

 

온갖 세세한 사항을 혼자서 직접 관리할 수 있을까? 불가능하다.

도시에는 큰 그림을 그리는 사람들도 있으며 수도, 전력, 교통 등 작은 사항에 집중하는 사람들도 있다.

 

도시가 돌아가는 또 다른 이유는 적절한 추상화와 모듈화 때문이다.

그래서 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다.

 

흔히 소프트웨어 팀도 도시처럼 구성한다.

그런데 막상 제작하는 시스템은 비슷한 수준으로 관심사를 분리하거나 추상화를 이뤄내지 못한다.

 

깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.

이 장에서는 높은 추상화 수준인 시스템에서도 깨끗함을 유지하는 방법을 살펴본다.

 

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

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

• 준비 과정: 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 과정
• 런타임 로직: 준비 과정 이후에 이어지는 과정

 

시작 단계는 모든 애플리케이션이 풀어야 할 관심사다.

관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다.

 

불행히도 대다수 애플리케이션은 시작 단계라는 관심사를 분리하지 않는다.

준비 과정 코드를 주먹구구식으로 구현할 뿐만 아니라 런타임 로직과 마구 뒤섞는다.

 

public Service getService() {
    if (service == null)
        service = new MyServiceImpl(...); // 모든 상황에 적합한 기본값일까?
    return service;
}

 

이것이 초기화 지연 혹은 계산 지연이라는 기법이다.

• 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다.
• 애플리케이션을 시작하는 시간이 빨라진다.
• 어떤 경우에도 null 포인터를 반환하지 않는다.

 

많은 장점이 있지만 단점 또한 존재한다.

• 메서드가 생성자 클래스와 인수에 명시적으로 의존한다.
• 런타임 로직에서 생성자 클래스를 사용하지 않더라도 의존성을 해결하지 않으면 컴파일이 안 된다.
• 테스트가 어렵고 단일 책임 원칙을 위배한다.
• 생성자 클래스가 모든 상황에 적합한 객체인지 모른다.

 

초기화 지연 기법을 수시로 사용하면 모듈성이 저조해진다.

체계적이고 탄탄한 시스템을 만들고 싶다면 객체를 생성하거나 의존성을 연결할 때 모듈성을 깨서는 안 된다.

설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.

 

1) Main 분리

main()에서 생성 분리

생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고

나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

• main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘긴다.
• 애플리케이션은 객체가 생성되는 과정을 전혀 모르고 그저 객체를 사용할 뿐이다.

 

2) 팩토리

팩토리로 생성 분리

때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 생긴다.

이때는 추상 팩토리(Abstract Factory) 패턴을 사용한다.

• 예를 들어 주문처리 시스템에서 LineItem 인스턴스를 생성해 Order에 추가할 때
• LineItem을 생성하는 시점은 애플리케이션이 결정하지만 생성하는 코드는 모른다.

 

3) 의존성 주입 (DI)

제어 역전 기법을 의존성 관리에 적용한 메커니즘으로 제어 역전은 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.

• 객체는 의존성 자체를 인스턴스로 만드는 책임을 지지 않고 새로운 객체가 맡는다. (SRP : 단일 책임 원칙)
• 대신에 이런 책임을 다른 전담 메커니즘에 넘겨야 한다. 그렇게 함으로써 제어를 역전한다.
• 초기 설정은 시스템 전체에서 필요하므로 대개 책임질 메커니즘으로 main 루틴이나 특수 컨테이너를 사용한다.

 

2. 확장

처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다.

오늘 주어진 사용자 스토리에 맞춰 시스템을 구현하고 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.

 

이것이 반복적이고 점진적인 애자일 방식의 핵심이다.

테스트 주도 개발, 리팩터링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.

 

하지만 시스템 수준에서 소프트웨어 시스템과 물리적인 시스템은 다르다.

관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

 

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

코드 수준에서 아키텍처 관심사를 분리할 수 있다면 진정한 테스트 주도 아키텍처 구축이 가능해진다.

그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수도 있다.

 

세계 최대 웹 사이트들은 고도의 자료 캐싱, 보안, 가상화 등을 이용해 아주 높은 가용성과 성능을 달성했다.

설계가 최대한 분리되어 각 추상화 수준과 범위에서 코드가 적당히 단순하기 때문이다.