클래스

“이 데이터들을 함께 사용하는데, 관려된 로직이 이것이다” 라고 이야기하고 싶을 때 클래스를 사용하자.

단순한 상위 클래스 이름

클래스 계층의 최상위 클래스 이름은 단순하게 이름 짓자.

한정적 하위 클래스 이름

상위 클래스와의 유사점과 차이점을 분명히 드러내도록 이름 짓자.

추상 인터페이스

인터페이스와 구현을 분리하자.
여기서 인터페이스란, “구현이 빠진 여러 연산의 집합” 이다.
자바에서는, 자바 인터페이스나 상위클래스를 이용할 수 있다.

소프트웨어는 유연해야 하지만, 유연성에는 비용이 들고 언제 어디에 유연성이 필요한지 예측하기 쉽지 않다.
그러므로, 실제 필요해지는 경우에만 시스템에 유연성을 부여하자.

인터페이스

“패턴, 가치, 원칙” 세 가지를 사용하면 균형있는 개발을 할 수 있다.

• 패턴은 지금 당장 무엇을 해야할지 알려준다.
• 가치는 패턴을 사용해야하는 동기를 알려준다.
• 원칙은 동기를 어떻게 행동으로 바꿔줄지 알려준다.

가치

훌륭한 프로그래밍에서 공통적인 가치는, “커뮤니케이션, 단순성, 유연성” 이다.

커뮤니케이션

코드를 쉽게 이해하고 수정하고 사용할 수 있으면, 그 코드는 개발자와 커뮤니케이션을 한다.

프로그램을 작성할 때 타인을 고려하면, 코드는 이해하기 쉽고 명확해진다.
또한 경제적으로도 효과가 높아진다.
기존 코드를 읽고 수정하는데 걸리는 시간이 새로 짜는데 걸리는 시간을 압도한다.
따라서 이 개발 비용을 줄이기 위해 이해하기 쉬운 코드를 작성해야한다.

단순성

복잡도를 낮추면, 프로그램을 읽고 수정하는 사람들이 프로그램을 쉽게 이해할 수 있다.

프로그램을 최대한 단순화하자.
의미 없는 코드는 제거하고, 설계 시 과도한 요소는 제거하자.
요구 사항을 분석해서 꼭 필요한 사항만 추출하자.

켄트 백은 다음 규칙을 따르는 설계를 “단순하다”고 말한다.

1. 모든 테스트를 실행한다.
2. 중복을 없앤다.
3. 프로그래머 의도를 표현한다.
4. 클래스와 메서드 수를 최소로 줄인다.

모든 테스트를 실행해라

테스트 케이스를 만들고 계속 돌리자.
그러면, 시스템은 낮은 결합도와 높은 응집력을 따르게 된다.
테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 높아진다.

크키가 작고 목적 하나만 수행하는 클래스가 나오게 된다.
SRP 를 준수하면 테스트가 쉬워지기 때문이다.

결합도가 높으면 테스트 케이스 작성이 어렵다.
그래서, DIP 원칙을 적용하고 DI, 인터페이스, 추상화 같은 도구를 사용해 결합도를 낮추게 된다.

리팩토링을 해라

테스트 케이스를 모두 작성했으면, 리팩토링을 하자.
테스트 케이스가 있으므로, 코드를 정리하면서 시스템이 깨질 걱정할 필요가 없다.

중복을 없애라

깨끗한 시스템을 만들려면 단 몇줄이라도 중복을 제거해야한다.
중복은 추가 위험, 불필요한 복잡도를 뜻한다.

깨끗한 클래스를 만드는 방법을 정리한다.

클래스는 작아야한다

1
2
3
4
5
6
7

public class SuperDashboard extends JFrame implements MetaDataUser {
    public Component getLastFocusedComponent()
    public void setLastFocused(Component lastFocused)
    public int getMajorVersionNumber()
    public int getMinorVersionNumber()
    public int getBuildNumber()
}

위 SuperDashboard 는 책임이 너무 많다.

클래스 이름은 클래스 책임을 기술해야하는데, 클래스 이름이 모호하면 책임이 많아서이다.
예를 들면, Processor, Manager, Super

그리고 클래스 설명은 if, and, or, but 을 사용하지 않고 가능해야한다.
SuperDashboard 클래스는 다음 처럼 설명할 수 있다:
“마지막으로 포커스를 얻은 컴포넌트에 접근하는 방법을 제공하며, 버젼과 빌드 번호를 추적하는 메커니즘을 제공한다”

“~하며” 는 SuperDashboard 에 책임이 많다는 증거다.

단일 책임 원칙

SRP 는 클래스나 모듈을 변경할 이유 (책임) 가 단 하나뿐이어야한다는 원칙이다.
SuperDashboard 는 변경할 이유가 두 가지다.

1. 소프트웨어 버젼 정보를 추적하는데, 소프트웨어를 출시할 때마다 달라진다.
2. 스윙 컴포넌트를 관리하는데, 스윙 코드가 변경되면 버젼 번호가 달라진다.

테스트 코드가 방치되어 망가지면, 실제 코드도 망가진다.
테스트 코드를 깨끗하게 유지하는 방벙을 정리하자.

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성하기 전에, 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로 실제 코드를 작성한다.

위와 같이 하면, 실제 코드를 전부 테스트하는 테스트 케이스가 나온다.
하지만 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

깨끗한 테스트 코드 유지하기

테스트 코드는 실제 코드 못지 않게 중요하다.
테스트 코드가 복잡할 수록,

1. 실제 코드를 작성하는 시간보다, 테스트 케이스를 추가하는 시간이 더 걸린다.
2. 실제 코드를 변경해 기존 테스트 케이스가 실패하면, 실패 테스트 케이스를 더 통과하기 어려워 진다.
3. 팀이 테스트 케이스를 유지 보수하는 비용도 늘어나게 된다.

하지만 테스트 슈트가 없으면 수정한 코드가 제대로 동작하는지 확인할 방법이 없다.
테스트 케이스가 있으면 변경이 두렵지 않다.
테스트 케이스가 없다면 모든 변경이 잠적정인 버그이다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 만들려면, 가독성이 중요햐다.
가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다.