그러타. 이번에 4.15총선을 맞아 4장까지 읽었다. 이번에도 역시 책을 소개하기 보다 읽으면서 느낀점, 생각한 것을 정리하고자한다.
5장부터 이어지는 리펙토링 방식에 대해서는 (3)편이 아니라 따로 '컴퓨터 지식' 따위의 카테고리를 신설하여 소개할 것 같다. (3)은 1~4장의 내용을 정리하는 글이 될 것 같다.
쨌든, 이번에도 굉장히 재미있는 이야기가 많았다.
2장
2장은 리펙토링의 당위성과 관련된 내용이 담겼다. 간단히 리펙토링은 왜 필요하고, 왜 좋은지에 대해서 적혀있는 '장'이다.
이 장에서 가장 인상깊었던 것은 '리펙토링이 코드를 보기 좋게 수정한다는 심미적인 용어가 아니라 수정, 확장하기 용이하도록 코드를 수정하는 것'이라는 필자의 의견이었다. 평소 추상적으로 '리펙토링하면 코드가 이뻐진다.'라고 생각하던 나에게는 리펙토링이라는 것을 좀 더 깊게 생각하게 하는 계기를 주었다. 그냥 이것 저것, 중복을 없애고 좀 더 직관적인 이름으로 바꾸고 하는 것 따위가 그냥 '이쁜 코드를 만드는 행위'라고 생각했었다. '이쁜 코드'가 왜 '이쁜'지는 진지하게 고민해 본적없이 그냥 '이쁜 코드'라고 칭했다. 이제부터 '이쁜 코드'는 읽기 쉽고, 이해하기 쉽고, 수정하기 쉽고, 확장하기 쉬운 코드라고 딱 못박아야 겠다.
3장
3장은 코드를 리펙토링 해야할 때에 대해 알려준다. 이는 아무래도 리펙토링 기법을 정리하고 다시한번 봐야할 것 같다. 이번 글에는 적지 않겠다. 하지만 추후 리펙토링 방법에 대해 정리한 후에 (4)편 혹은 리펙토링 기법과 같이 서술하는 방식으로 진행할 예정이다.
4장
4장은 대망의 테스트 코드에 관한 내용이다. 필자는 이장에서 간단한 프로그램의 비지니스 로직의 테스트 코드를 예시로 보여준다. 필자는 테스트를 하나하나 추가하면서 어떤 방식으로 테스트를 추가하는 것이 좋은지에 대한 필자의 의견을 이야기한다. 나는 평소 테스트보다 기능개발을 먼저 했기에, 만들어진 함수의 스펙에 관해서 테스트를 작성했다. 그런데 필자의 경우, 테스트를 먼저 작성하기에 필요 스펙을 체크하는 것 뿐만아니라 예외상황을 좀더 중요하게 정리한다고 했다. 물론 나도 예외상황을 때때로 정리하기는 하지만 일단 돌리는게 우선이었기에 그리 중요하게 생각하지 않았던 것 같다. 역시 TDD가 짱인 것 같다.
이렇게 1~4장을 훑어 봤다. (3)은 리펙토링 기법을 정리하고, 3장에 대해 다시 정리한 후에야 쓸 것 같다.
그럼 이 글을 읽게될 미래의 나야 게으름 좀 그만 피우렴. ㅃ2