외부 코드 사용하기
인터페이스 제공자와 인터페이스 사용자 사이에는 특유의 긴장이 존재한다.
패키지 제공자나 프레임 워크 제공자는 적용성을 최대한 넓히려 애쓴다.
반면 사용자는 자신의 요구에 집중하는 인터페이스를 바란다.
이런 긴장으로 인해 시스템 경계에서 문제가 생길 수 있다.
경계 인터페이스인 Map을 Sensors 안으로 숨긴다. 따라서 Map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않는다. 제네릭스를 사용하든 하지 않든 더 이상 문제가 안된다. 또한 Sensors 클래스는 프로그램에 필요한 인터페이스만 제공한다.
Map 클래스를 사용할 때 마다 위와 같이 캡슐화 하라는 소리가 아니다. Map을 여기저기 넘기지 말라는 말이다.
단위 테스트
애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세다. 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 사실을 놓쳐버린다.
TDD 법칙 세가지
1. 실패하는 단위 테스트를 작성할 때 까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 유지하기
지저분한 테스트 코드를 내놓는 것은 테스트를 안 하나 오십보 백보, 아니 오히려 더 못한다는 사실을 인지해야 한다. 실제 코드가 진화하면 테스트 코드도 변해야 한다. 그런데 테스트 코드가 지저분할 수록 변경하기 어려워진다.
테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.
깨끗한 테스트 코드
깨끗한 테스트 코드를 만들려면? 가독성이 중요하다. 명료성, 단순성, 풍부한 표현력이 필요하다. 진짜 필요한 자료유형과 함수만 사용한다.
그러므로 코드를 읽는 사람은 온갖 잡다하고 세세한 코드에 주눅들고 헷갈릴 필요없이
코드가 수행하는 기능을 재빨리 이해한다.
테스트당 개념 하나
테스트 함수마다 한 개념만 테스트하라!는 규칙이 더 낫다. 이것거것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
- 빠르게
- 독립적으로 : 각 테스트는 서로 의존하면 안된다.
- 반복 가능하게
- 자가검증하는 : 테스트는 부울 값으로 결과를 내야 한다.
- 적시에 : 테스트는 적시에 작성해야 한다.
느낀 점
이번 Clean Code 8장과 9장을 읽으면서 솔직히 많이 이해를 하지 못하였다. 아직 테스트 코드를 작성해 본 적이 없어서 TDD에 대한 개념이 모호하다.
테스트 코드도 작성 할 수 있도록 공부를 해야겠다 느꼈다.
