이번에 출간된 채수원 님의 TDD 책을 보고 있습니다.
TDD 의 개발 주기 정제(리펙토링) 단계 에서는
"아이디어를 통합하고 불필요한 것은 제거하고 , 모호한 것은 명확히 해서 대답을 정제한다." 라고 합니다.
좀더 구체적인 행동지침이 필요하지 않을까 생각이들었습니다.
대부분 리펙토링에 대해서 아주 큰 그림을 그리고 있어서 저의 경우 처음 접하면서 어디서 부터 어떻게 해야하는지 모호했습니다.
TDD 자체가 가장 작은 메소드 단위이고 적절한 테스트의 크기가 일정수준 이상으로 커지면 곤란하다고 생각이들어서
checkList 를 두기에 적합하다고 생각이 들었습니다.
제 생각은
1. 변수와 속성 ,메소드 ,클래스의 이름이 의미하는 바가 적절한가?
2. 메소드가 행하는 행동이 한가지 이상인가? 한가지 이상이라면 Extract Method 하자.
3. 이전 단계에서 작성한 코드가 반복되는 구문이 있는가?
4. 메소드의 길이는 10줄 내외 인가?(정하기 나름이 겠지만 전 10줄이상 넘어가면 거부감이 나더군요)
더많은 스킬이 있겠지만 이정도로 생각이 납니다.
초보다보니 저런 구체적 checkList가 훈련하는데 도움이되지않을까 생각이 들었습니다.
어떻게 책은 재밌게 보고 계신지 모르겠습니다. :)
제가 보기에도 말씀해 주신 내용이
초급자들이 접하고 판단하기에 좀 더 구체적인 사례가 되는 것 같습니다.
그리고 읽으신 다른 분들에게도 도움이 될 것 같습니다. (감사합니다)
사실
TDD 책에서 리팩터링을 어느 정도 다룰 것인가의 문제는 쉽지 않은 부분이라
도입 부분에서는 정제에 많은 부분을 할애하지 않았습니다.
대신 정제의 방향성과 목표에 대해서 이해하기를 바랬습니다.
정제(리팩터링) 관련된 부분이나, 실제 코드를 어떻게 접근하고 다루어야 하는지에 대해서는
10장 실습예제 부분, 특히 자판기 예제쪽과
부록A.3. 코드리뷰에 좀 더 담았습니다.
참고하시면 읽으시는데
좀 더 도움이 되시지 않을까 조심스레 이야기 드려 봅니다.
책을 읽는 법에서 적어 놓았지만,
먼저 보시더라도 크게 상관은 없도록 만들어 놓았으니까
개의치 않고 보셔도 됩니다. :)
의견 감사드리고요,
TDD책 게시판이 아닌데도 답글아니 답글을 달게 되어
다른 분들께 죄송한 마음도 큽니다.
비슷한 아쉬움 가지시는 분이 혹 계실까 싶어 게시물로 남기게 되었습니다.
요즘은 참 이상한 장마철인데요, 건강 유의하시고요
기타 궁금하신 사항이나 의견 있으시면 언제든 tdd...@gmail.com이나 Q&A게시판을 통해 알려주세요.
(Q&A게시판: http://groups.google.com/group/tddbook-qna )
감사합니다!!