[Study][CleanCode - 3] 11. 시스템

📋 목차.

11. 시스템
    .시스템 제작과 시스템 사용을 분리하라
    .확장
    .횡단 관심사
    .테스트 주도 시스템 아키텍처 구축
    .의사 결정을 최적화하라
    .명백한 가치가 있을 때 표준을 현명하게 사용하라
    .시스템은 도메인 특화 언어가 필요하다.
    .결론

---

✔️ 내용.

 

11. 시스템

 

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

 

 하나의 도시를 한 사람이 관리할 수는 없다. 각자의 역할에 맞는 팀과 사람이 있어야 잘 돌아가게 된다.
도시가 돌아가는 또 다른 이유는 적절한 추상화와 모듈화 때문이다. 그래서 큰 그림을 이해하지 못하여도 개개인이 관리하는 '구성'요소'는 효율적으로 돌아간다.

 소프트웨어 팀도 도시처럼 구성한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.
이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다.

 

---

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

 

 우선 제작은 사용과 다름을 명심한다. 즉 소프트웨어에서 시스템은 준비 과정과 런타임 로직을 분리해야 한다.

시작 단계는 관심사(Concern)다. 관심사 분리는 가장 오래되고 가장 중요한 설계 기법 중 하나이다.

 

 불행히도 대다수의 애플리케이션은 시작 단계에서 관심사를 분리하지 않는다. 다음이 전형적인 예다

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

 

 위 코드는 초기화 지연(Lazy Initialization) 혹은 계산 지연( Lazy Evaluation)이라는 기법이다.

 

장점

 

 - 실제로 필요할 때까지 생성하지 않으므로 불필요한 부하가 걸리지 않는다. 따라서 애플리케이션을 시작하는 시간이 그만큼 빨라진다.

 - 어떤 경우에도 Null 이 발생하지 않는다.

 

단점

 

 - 의존성이 생긴다.

getService 메서드가 MyServiceImpl와 (위에서 생략된) 생성자 인수에 명시적으로 의존한다.

런타임 로직에서 MyServiceImpl 객체를 전혀 사용하지 않더라도 의존성을 해결해야 컴파일 가능하다.

 

 - 테스트 문제.

MyServiceImpl이 무거운 객체일 경우 단위 테스트에서 getService 메서드를 호출하기 전에 적절한 테스트 전용 객체(Test Double이나 Mock Object)를 servie 필드에 할당해야 한다. 또한 런타임 로직에 객체 생성 로직을 섞어 놓은 탓에 (service가 null인 경로와 null이 아닌 경로 등) 모든 실행 경로도 테스트해야 한다.

 책임이 둘이라는 말은 작게나마 단일 책임 원칙(SRP)을 깬다는 의미이다.

 

 - 상황에 적합한 객체인가?.

getService 메서드를 포함한 클래스가 전체 문맥을 알 필요가 있을까? 과연 이 시점에 어떤 객체를 사용할지 알 수나 있을까? 현실적으로 한 객체 유형이 모든 문맥에 적합할 가능성이 있을까?

 

 - 모듈성은 저조하고 대개 중복이 심각하다.

 초기화 지연 기법을 한 번 정도 사용한다면 큰 문제가 아니다. 하지만 많은 애플리케이션에서 이처럼 좀스러운 설정 기법을 수시로 이용한다. 그래서 전반적인 설정 방식이 애플리케이션 곳곳에 흩어져 있다.

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

객체를 생성하거나 의존성을 연결할 때도 마찬가지다. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. 또한 주요 의존성을 해소하기 위한 방식, 즉 전반적이며 일관적인 방식도 필요하다.

 

---

 

- Main 분리

 

 시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로, 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

 제어 흐름은 main 함수에서 시스템에 필요한 객체를 생성한 후 애플리케이션에 넘긴다. 애플리케이션은 사용만 할 뿐 main이 객체가 생성되는 과정을 전혀 모른다.

 

---

 

 - 팩토리

 

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

예로 주문처리 시스템에서 애플리케이션은 LineItem 인스턴스를 생성해 Order에 추가한다. 이때 Abstract Factory 패턴을 사용한다. 그러면 LineItem을 생성하는 시점은 애플리케이션이 결정하지만 LineItem을 생성하는 코드는 애플리케이션이 모른다.

 

---

 - 의존성 주입

 

의존성 주입(Dependency Injection, DI)은 제어 역전(Inversion of Control. IOC) 기법을 의존성 관리에 적용한 메커니즘이다.

 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙(SRP)을 지키게 된다. 의존성 관리 맥락에서는 객체는 의존성 자체를 인스턴스로 만드는 책임을 지지 않는다. 대신 이런 책임을 다른 '전담' 메커니즘에 넘겨야 한다. 그럼으로써 제어를 역전한다.

 초기 설정은 시스템 전체에서 필요하므로 대게 '책임질' 메커니즘으로 'main' 루틴이나 특수 컨테이너를 사용한다.

 

 의존성 주입 기법은 초기화 지연으로 얻는 장점을 그대로 사용할 수 있다. 대다수 DI 컨테이너는 필요할 때까지 객체를 생성하지 않고, 대부분 계산 지연이나 비슷한 최적화에 쓸 수 있도록 팩토리를 호출하거나 프락시를 생성하는 방법을 제공한다. 즉, 계산 지연 기법이나 이와 유사한 최적화 기법에서 이런 메커니즘을 사용할 수 있다.

 

 

---

 

.확장

 

 '처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이다. 대신 우리는 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다. 테스트 주도 개발, 리펙터링, (TDD + 리팩터링으로 얻어지는) 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다.

 

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

---

 

.횡단 관심사

 

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

 영속성을 예로 들면, 프로그래머는 영속적으로 저장할 객체와 속성을 선언한 후 영속성 프레임워크에 위임한다. 그러면 AOP 프레임 워크는 대상 코드에 영향을 미치지 않는 상태로 동작 방식을 변경한다. 자바에서 사용하는 관점 혹은 관점과 유사한 메커니즘 세 개(Java Proxy, 순수 자바 AOP 프레임워크, AspectJ 관점)가 있다.

 

---

 

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

 

 관점으로 관심사를 분리하는 방식은 위력이 막강하다. 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다. 필요에 따라 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수도 있다.

 

 최선의 시스템 구조는 각기 POJO 객체로 구현되는 모둘화 된 관심사 영역(도메인)으로 구성된다. 이렇게 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

---

 

.의사 결정을 최적화하라

 

모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 이러한 모든 결정을 한 사람이 내리기는 어렵다. 

따라서 가장 적합한 사람에게 책임을 맡기는 게 가장 좋다. 우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 잊고는 한다. 게으르거나 무책임해서가 아니라 최대한 정보를 모아 최선의 결정을 내리기 위해서이다.

 

---

 

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

 

EJB2는 단지 표준이라는 이유로 많이 사용하곤 했다. 하지만 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례가 발생하게 된다.

 

 표준을 사용하면 컴포넌트 재사용이 쉽고, 관련 경험이 있는 사람을 구하기 쉽고 등등 다양한 장점이 있지만. 때로는 이러한 표준 때문에 제정한 목적을 잊어버리곤 한다.

 

---

 

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

 

 DSL은 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다. 

좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 '의사소통 간극'을 줄여준다. 도메인 전문가가 사용하는 언어로 도메인 논리를 구현하면 도메인을 잘못 구현할 가능성이 줄어든다.

 효과적으로 사용한다면 고차원 정책에서 저 차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표현할 수 있다.

 

---

 

.결론

 

 시스템 역시 깨끗해야 한다. 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 시스템이든 개별 모듈이든 가장 단순한 수단을 사용해야 한다.

---

📝 느낀점.

 - 깨끗한 아키텍처 구성을 위해 노력해야 한다.
 - 관점 혹은 관점과 유사한 메커니즘을 사용해 구현 관심사를 분리하자.
 - '가장 단순하게!' 항상 생각하며 설계 밑 개발을 하자.