로버트 마틴과 장인 정신 <클린 코드> 요약 #3

 

Clean Code 클린 코드 로버트 C. 마틴 저/박재호,이해영 공역

차례

1장. 깨끗한 코드
2장. 의미 있는 이름
3장. 함수
4장. 주석
5장. 형식 맞추기
6장. 객체와 자료 구조
7장. 오류 처리
8장. 경계
9장. 단위 테스트
10장. 클래스
11장. 시스템
12장. 창발성
13장. 동시성
14장. 점진적인 개선
15장. JUnit 들여다보기
16장. SerialDate 리팩터링
17장. 냄새와 휴리스틱

 

 

8장. 경계

외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. Map에서 봤듯이, 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자. 어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아지며, 외부 패키지가 변했을 때 변경할 코드도 줄어든다.

 

9장. 단위 테스트

TDD법칙 세 가지

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

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

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.

테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다. 테스트 코드가 지저분할수록 실제 코드도 지저분해진다. 결국 테스트 코드를 잃어버리고 실제 코드도 망가진다.

테스트 당 assert 하나

가장 좋은 규칙은 "개념 당 assert 문 수를 최소로 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"라 하겠다.

F.I.R.S.T.

Fast: 테스트는 빨라야 한다.
Independent: 각 테스트는 서로 의존하면 안 된다.
Repeatable: 테스트는 어떤 환경에서도 반복 가능해야 한다.
Self-Validating: 테스트는 bool값으로 결과를 내야 한다.
Timely: 테스트는 적시에 작성해야 한다.

 

결론

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 어쩌면 실제 코드보다 더 중요할지도 모르겠다. 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다. 그러므로 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 API를 구현해 도메인 특화 언어(DSL)를 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다.

 

 

10장. 클래스

클래스 체계

클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. static public 상수가 있다면 맨 처음에 나온다. 다음으로 static private 변수가 나오며, 이어서 private 인스턴스 변수가 나온다. public 변수가 필요한 경우는 거의 없다.
변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다.

클래스는 작아야 한다!

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.

응집도를 유지하면 작은 클래스 여럿이 나온다.

변경하기 쉬운 클래스

새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.

요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다. 객체 지향 프로그래밍 입문에서 우리는 구체적인(concrete) 클래스와 추상(abstract) 클래스가 있다고 배웠다. 구체적인 클래스는 상세한 구현(코드)을 포함하며 추상 클래스는 개념만 포함한다고도 배웠다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.

 

참고

TDD 법칙 세 가지, http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
BUILD-OPERATE-CHECK 패턴, http://www.butunclebob.com/FitNesse.AcceptanceTestPatterns
Dave Astel, One Assertion Per Test, 2004
에릭 감마, <GoF의 디자인 패턴>, 프로텍미디어, 2015
Rebecca Wifts-Brock, <오브젝트 디자인: 소프트웨어 개발의 성공 열쇠>, 인포북, 2004
로버트 C. 마틴 외, <소프트웨어개발의 지혜>, 야스미디어, 2004

 

- James Song