실용주의 단위 테스트. 8장. 깔끔한 코드로 리팩토링하기.

리팩토링 실습입니다. 정리를 위해 오랜만에 다시 읽으니 저자의 친숙한 말투와 농담이 새삼 눈에 띄네요.

 

메서드 추출

리팩토링하고자 하는 메서드의 복잡도를 줄여 코드가 무엇을 담당하는지 쉽게 이해할 수 있도록 합니다. 이미 앞에서 단위 테스트를 작성해두었기 때문에 수정에 부담이 적습니다.

 

메서드를 위한 더 좋은 집 찾기

메서드 추출을 해보면, 때로는 해당 객체와 직접적인 연관성이 없는 걸 발견할 수도 있습니다. 요즘 읽고 있는 오브젝트, 듣고 있는 TDD 강의 내용들이 함께 머릿 속을 지나갑니다. 유사한 내용을 각각의 관점에서 다룹니다.

 

자동 및 수동 리팩토링

메서드 인라이닝이라던가... IDE가 제공하는 리팩토링 기능을 충분히 사용하라는 조언입니다. 이클립스가 언급되길래 출판연도를 확인했는데, 원서는 2015년, 번역서는 2019년입니다.

 

과한 리팩토링?

하나의 반복문으로 이루어진 코드를 리팩토링 했더니 3개의 메서드에서 각각 반복문을 호출하는 모양이 되었습니다. 의미는 명확해졌지만 성능에 대한 우려가 제기됩니다.

• 보상 : 구현을 세 단계로 변경하면서, 메서드는 이제 즉시 이해할 수 있을 정도로 전체 알고리즘이 깔끔하게 정리되었습니다. 각 도우미 메서드는 구현 세부 사항을 숨겨주며, 명확하고 고립된 방식으로 구현되었습니다.
• 성능 염려: 성능이 즉시 문제가 되지 않는다면 어설픈 최적화 노력으로 시간을 낭비하기보다는 코드를 깔끔하게 유지해야합니다.
• 최적화된 코드는 일반적으로 가독성이 낮고 유지 보수 비용이 증가하고 설계 또한 유연하지 않습니다.
• 반대로 깔끔한 설계가 이루어진다면, 최적화가 필요해졌을 경우 유연하게 대응할 수 잇습니다.

 

자바와 JUnit을 활용한 실용주의 단위 테스트