9장, 단위 테스트
🤔
- 테스트의 목적을 이해할 수 있었다.
- 테스트로 시스템의 결함을 최대한 제거함으로서 안정한 서비스를 제공할 뿐만 아니라 코드 유지보수, 유연성을 달성할 수 있다.
- 하지만 테스트 코드 작성을 진심으로 한 경험이 없어서 책에서 말하는 ‘깨끗한 코드를 위한 원칙'을 잘 이해하지 못했다.
- 그래도 몇 개 알게된 것이 있다. 테스트 코드도 실제 코드 못지않게 깔끔하게 작성해야한다는 것. 실제 코드가 변경됨에 따라 테스트 코드도 함께 변경되야하기 때문이다. (지저분한 테스트 코드로 인해 수정이 힘들다면, 새로운 코드를 짤 수도 있겠지만, 이런 코드가 많다면 비용이 크다. 처음부터 깨끗한 테스트 코드를 작성하자.)
- 테스트 환경과 실제 환경(배포 환경)은 다르다. 실제 환경에서는 성능을 중시해야한다. 테스트 환경에서는 덜 그렇다. 때문에 테스트 코드를 작성할 때는 성능을 고려했지만 그 영향이 미미할때는 차라리 가독성에 신경을 쓰자.
12장, 창발성
📖
켄트 벡은 이 규칙들을 따르면 설계는 ‘단순하다'라고 말한다.
- 모든 테스트를 진행한다.
- 중복을 없앤다.
- 프로그래머의 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
- 모든 테스트를 실행한다.
- 검증이 가능한 시스템을 유지해야한다. 그렇지 않은 시스템은 시장에 내놓지 않아야 한다.
- 테스트가 가능한 시스템을 만들려고 하다보면 설계 품질이 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다.
- 결합도가 높으면 테스트 케이스를 작성하기 어렵다. 따라서 다양한 설계원칙 및 도구를 이용해 결합도를 낮추게 되면서 설계 품질을 향상시킨다.
- 테스트 케이스를 계속 만들고 돌리는 것 → 시스템의 낮은 결합도와 높은 응집력을 달성할 수 있다.
- 중복을 없앤다.
- 추가 작업, 추가 위험, 불필요한 복잡도를 유발한다.
- 추상화하다보면, 다른 맥락에서 재사용 할 기회까지도 얻을 수 있다.
- template method 패턴: 중복하는 일부 구현을 재사용 할 수 있는 방법
- 표현하자.
- 소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다.
- 복잡하고 이해하기 어려운 코드가 늘어나면 결함이 늘어나고 유지보수 비용을 증가시킨다.
- 좋은 이름을 선택한다. 함수와 클래스 크기를 가능한 줄인다. 표준 명칭을 사용한다. 단위 테스트 케이스를 꼼꼼히 작성한다.
- 주의를 기울이자. 나중에 코드를 읽을 사람은 자신일 가능성이 높다는 사실을 명심하며 주의깊게 코드를 작성하자.
🤔
- 코드를 개선할 때 문제점을 명확하게 파악한다면 문제점에 대한 해결방법을 쉽게 떠올릴 수 있을 것이다. 모호한 문제일수록 방법을 떠올리기 어려운 것을 경험해왔다.
- 다양한 코드 설계 원칙을 좋아보여서 무작정 적용하기 보다는 파악한 문제에 적절한 해결책인지 생각해야한다. 그렇지않으면 오히려 실이 될 가능성도 있을 것 같다. (코드에 어떤 원칙을 적용했는데 오히려 코드가 더 복잡하게 작성되었다든지...) 따라서 추후 득이 될 수 있는 방향으로, 상황에 맞게 해결책을 적용하자는 거다.
