클린 코드(Clean Code) - 11장, 12장

11장. 시스템 📡

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

  제어 흐름을 따라가기 쉽다. main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘긴다. 애플리케이션은 그저 객체를 사용할 뿐이다. main과 애플리케이션 사이에 표시된 의존성 화살표의 방향에 주목한다. 모든 화살표가 main 쪽에서 애플리케이션 쪽을 향한다. 즉, 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다는 뜻이다. 단지 모든 객체가 적절히 생성되었다고 가정한다.

 

11장 결론

  시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.

  모든 추상화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.

  시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

(해당 장에서는 시스템과 관련된 DI, IoC, Proxy, POJO 등에 관한 내용이 많습니다. 자세한 내용을 알고 싶으시다면 꼭 11장을 읽어보시는 것을 추천합니다.)

 

 

12장. 창발성 🎠

  켄트 벡이 제시한 단순한 설계 규칙 네 가지를 이용하여 우수한 설계의 창발성을 촉진하여 보자. (중요도가 높은 것들을 먼저 소개하는 방식으로 글을 적겠다.)

 

단순한 설계 규칙 1 : 모든 테스트를 실행하라

  테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 좋아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다.

  "테스트 케이스를 만들고 계속 돌려라"라는 간단하고 단순한 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는, 객체 지향 방법론이 지향하는 목표를 저절로 달성한다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다.

 

단순한 설계 규칙 2 : 중복을 없애라 (리팩토링)

  우수한 설계에서 중복은 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다. 똑같은 코드는 당연히 중복의 한 형태이고 구현 중복도 중복의 한 형태이다. 

  아래는 구현 중복의 한 형태와 구현 중복을 제거한 형태를 나타낸 것이다.

// 구현 중복
int size() {} // 메서드 개수를 반환
boolean isEmpty() {}

------------------------------------

// 구현 중복 해결
boolean isEmpty() {
    return 0 == size();
}

 

단순한 설계 규칙 3 : 프로그래머의 의도를 표현하라 (리팩토링)

  소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다. 코드를 변경하면서 버그의 싹을 심지 않으려면 유지보수 개발자가 시스템을 제대로 이해해야 한다. 하지만 시스템이 점차 복잡해지면서 유지보수 개발자가 시스템을 이해하느라 보내는 시간은 점점 늘어나고 동시에 코드를 오해할 가능성도 점점 커진다. 그러므로 코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다. 아래는 이를 위한 4가지 방법을 제공한다.

• 좋은 이름을 선택한다.
• 함수와 클래스 크기를 가능한 줄인다
• 표준 명칭을 사용한다
• 단위 테스트 케이스를 꼼꼼히 작성한다.

 

단순한 설계 규칙 4 : 클래스와 메서드 수를 최소로 줄여라 (리팩토링)

  중복을 제거하고, 의도를 표현하고, SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득 보다 실이 많아진다. 클래스와 메서드 크기를 줄이자고 조그만 클래스와 메서드를 수없이 만드는 사례도 없지 않다. 그래서 이 규칙은 함수와 클래스 수를 가능한 줄이라고 제안한다.

  목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다. 하지만 이 규칙은 간단한 설계 규칙 네 개 중 우선순위가 가장 낮다. 다시 말해, 클래스와 함수 수를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻이다.