[Clean Code] 11장 시스템

Clean Code 내용 정리; 11장 시스템

깨끗한 코드로 구현함으로써 낮은 추상화 수준에서 관심사를 분리하는 것에서 더 나아가 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다.

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

실제로 필요할 때까지 객체를 생성하지 않는 '초기화 지연', '계산 지연'기법 은 불필요한 부하가 걸리지 않고 어떤 경우에도 null 포인터를 반환하지 않는다는 장점이 있지만, 남발되었을 때는 모듈성이 깨지고 중복이 심각해지기에 전반적이고 일관적인 다른 방식을 취할 필요가 있다.

시스템 생성과 시스템 사용을 분리하는 방법에는 다음과 같은 것들이 있다.

1. Main 분리
   

: 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮겨 애플리케이션은 그저 모든 객체가 생성되었고 모든 의존성이 연결되었다는 가정 하에 객체 사용만 하도록 만든다.

- 객체가 생성되는 시점을 애플리케이션이 결정해야 하는 경우에는 ABSTRACT FACTORY 패턴을 사용해 객체가 생성되는 시점은 애플리케이션이 결정할 수 있게 하되 객체를 생성하는 코드는 main이나 main이 호출하는 모듈에서 맡아 애플리케이션이 모르도록 만든다.

2. 의존성 주입
   

: 제어 역전(IoC)기법을 의존성 관리에 적용하여 사용과 제작을 분리하는 강력한 메커니즘. DI 컨테이너가 필요한 객체의 인스턴스를 만든 후 클래스에서 제공하는 생성자 인수나 setter 메소드를 사용해 의존성을 설정한다. 스프링 프레임워크는 가장 널리 알려진 자바 DI 컨테이너를 제공한다.

시스템의 확장을 고려하라

처음부터 올바르게 시스템을 맞출 순 없다. 깨끗한 코드는 물리적인 시스템을 조정하고 확장하기 쉽게 만든다. 소프트웨어 시스템은 물리적인 시스템과 다른데, 소프트웨어 아키텍처 역시 점진적인 발전이 가능하도록 만들려면 관심사를 적절히 분리해 관리해야 한다.

관점 지향 프로그래밍은 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다. AOP에서의 모듈 구성 개념은 관점aspect이다. 자바에서 사용하는 관점 혹은 관점과 유사한 메커니즘은 다음과 같다.

1. 자바 프록시

: 프록시 패턴이란 실제 기능을 수행하는 객체 대신 가상의 객체를 사용해 부가적인 작업이나 비용이 많이 드는 작업들의 흐름을 제어하는 디자인 패턴을 말한다.

자바 프록시는 코드의 양이 많고 크기가 크기 때문에 단순한 상황에 적합하다. 프록시를 사용하면 깨끗한 코드를 작성하기는 어렵다.

보다 자세한 개념은 프록시 패턴을 참고하자.

2. 순수 자바 AOP 프레임워크

: 프록시 코드는 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 자바 프레임워크를 사용하여 자동화할 수 있다.

스프링은 비즈니스 논리를 POJO로 구현하고 POJO는 순수하게 도메인에 초점을 맞추기에 애플리케이션에는 스프링 관련 자바 코드가 거의 필요 없고, 사실상 스프링과 독립적이다. 모든 정보가 애너테이션 속에 있으므로 코드 자체는 깔끔하고 깨끗하게 만들 수 있다. 애너테이션에 들어있는 정보를 xml로 옮기면 완전히 순수한 POJO만 남길 수 있다.

3. AspectJ 관점

: AspectJ 언어는 관심사를 관점으로 분리하는 가장 강력한 도구이다. AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어의 확장이기에 새 언어 문법을 익혀야 한다는 부담이 있었으나 최근에 AspectJ 애너테이션 폼이 나와 이러한 부담이 완화되었다.

스프링 AOP와의 차이점을 간략히 언급하고 넘어가자면

스프링은AOP는 Proxy 기반 AOP 프레임워크이기에 런타임 Weaving* 만 가능한 반면 AspectJ는 런타임 Weaving이 불가능하고 컴파일 시점/컴파일 전/로드시점 Weaving* 을 지원하여서 성능이나 적용 가능 범위면에서 더 우수하지만 그만큼 더욱 복잡하다.

*런타임 Weaving : Aspect가 대상 객체의 Proxy를 사용하는 애플리케이션의 실행시에 Weaving됨

보다 자세한 설명은 Spring AOP와 AspectJ 비교하기를 참고하자.

도메인 특화 언어를 적절히 사용한다.

좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 의사소통 간극을 줄여준다.

도메인 전문가가 사용하는 언어로 도메인 논리를 구현하면 도메인을 잘못 구현할 가능성이 줄어들고, 고차원 정책에서 저차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 포현할 수 있다.

결론

<깨끗하지 못한 아키텍쳐>

도메인 논리를 흐리며 기민성을 떨어뜨린다. -> 도메인 논리가 흐려지면 버그가 숨어들기 쉽고 생산성이 낮아져 TDD의 장점이 사라진다. -> 제품 품질이 떨어진다.

따라서 시스템 역시 깨끗해야 한다. 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 Aspect와 같은 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.

<깨끗한 아키텍쳐>

애플리케이션 도메인 논리를 POJO로 작성할 수 있다. 즉, 코드 수준에서 아키텍처 관심사를 분리할 수 있다. -> 설계가 최대한 분리되어 각 추상화 수준과 범위에서 코드가 적당히 단순하다. -> 결과물을 재빨리 내놓은 후 기반 구조를 추가하며 조금씩 확장해나갈 수 있다. -> 진정한 테스트 주도 아키텍처 구축이 가능해진다!

또한 관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공하여 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기 쉽게 만들어주고 결정의 복잡성도 줄인다.