어제 문자열 덧셈 계산기 미션을 수행하면서 마지막에 if문 분기가 너무 많아졌다는 것을 느꼈다
물론 주어진 테스트 코드가 조건들을 테스트하는 것이였지만 같은 코드가 반복되는 것이 좋지 않은 것은 사실이다.
요즘 같은 미션을 하는 분들의 다른 코드를 보곤 하는데 공통적으로 많이 하셨던 것이 불변객체를 사용하는 것이었다.
사실 불변 객체에 대해 듣기만 들었지 실제로 와 닿지는 않았다. 평소에 회사에서 사용할 일이 있었다면 쓰겠는데 그러지 못하니 필요성은 당연히 느껴지지 않았겠지...심지어 불변 객체와 방어적 복사가 비슷한 것인지 알았다. TDD로 정리하는 것도 괜찮겠다
알고리즘과 TDD
평소 알고리즘에 대한 뭐랄까.. 항상 우선순위가 밀렸던 것 같다. 사실 시간을 많이 잡아 먹기에 시간대비 효율이 안나오는 학습이라 생각했다. 그래서 이력서 넣는 것에 조금 자신이 없었기도 했고.. 최근에는 알고리즘 문제를 계속 풀고 있다가 TDD 사이클을 한번 적용해봐야겠다는 생각이 들었다.
순서는 다음과 같다
- 조건들을 TODO 리스트에 넣는다
- 조건들 중 구현하기 가장 쉬운 조건을 구현한다
- 성공시킨다
- 리펙토링한다
- 성공시킨다
- 그 다음 구현하기 쉬운 조건을 구한다
위의 내용을 반복했다.
보통 30분 정도 구현하다가 안되면 해설을 보는데 이번에는 한 40분 정도 내로 해결 할 수 있었다.
계속 이 방법을 시도 해봐야겠다. TDD 사이클은 여러모로 유용하다. 역시 DTSTTCPW이 진리
테스트 주도 개발 일회독
드디어 켄트백 옹의 테스트 주도 개발을 완독했다. 한 1~2주 정도 걸린 것 같다. 사실 구현하는 부분을 뺴고는 대체로 지하철에서 가볍에 읽을 수 있어서 좋았던 것 같다. 개인적으로 1부 화폐 예제, 2부 xUnit 예시, 3부 중 디자인 패턴과 마지막에 실전 TDD가 많이 도움이 되었다. 특히 실전 TDD의 네트워크와 데이터베이스 테스트는 스프링부트에서 Mockito로 생각없이 작업했던 내용들이 원론적으로 왜 필요한지 뼈저리게 느끼는 기회가 되었다. 주말에 직접 작성하면서 정리해야 겠다.
