[Book]Clean Code 12장

창발적 설계로 깔끔한 코드를 구현하자

• 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 4가지가 있다면?
  1. 모든 테스트를 실행한다.
  2. 중복을 없앤다.
  3. 프로그래머의 의도를 표현한다.
  4. 클래스와 메서드 수를 최소로 줄인다.

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

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

단순한 설계 규칙 2~4 : 리팩토링

• 테스트 케이스를 모두 작성했다면, 코드를 점진적으로 리팩터링 해나간다.
• 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!

중복을 없애라

• 우수한 설계에서 중복은 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다.

표현하라

• 좋은 이름을 선택한다. 이름과 기능이 딴판인 클래스나 함수로 유지보수 담당자를 놀라게 해서는 안된다.
• 함수와 클래스 크기를 가능한 줄인다. 작은 클래스와 작은 함수는 이름짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다.
• 표준 명칭을 사용한다. 디자인 패턴은 의사소통과 표현력 강화가 목적이다. 클래스 이름에 패턴 이름을 넣어주면, 다른 개발자가 클래스 설계 의도를 이해하기 쉬워진다.
• 단위 테스트 케이스를 꼼꼼히 작성한다.

클래스와 메서드 수를 최소로 줄여라

• 중복을 제거하고 의도를 표현하고 SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득보다 실이 많아진다.
• 때로는 무의미하고 독단적인 정책 탓에 클래스 수와 메서드 수가 늘어나기도 한다.
• 클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준은 좋은 예다.
• 자료 클래스와 동작 클래스는 무조건 분리해야 한다고 주장하는 개발자도 좋은 예다.
• 가능한 독단적인 견해는 버리고 실용적인 방식을 택한다.
• 목표는 함수와 클래스의 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는데 있다.
• 이 규칙은 간단한 설계 규칙 4가지 중 우선순위가 가장 낮은데, 클래스와 함수 수를 줄이는 것도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻이다.