Working Effectively With Legacy Code (Michael Feathers, 2004) 독후감

TDD(Test-Driven Development, 테스트 주도 개발)를 처음 접했을 때, 개발 방법이 충격적이었다. 테스트를 먼저 추가하면서 시작되는 TDD의 리듬을 타면 테스트가 바탕이 된 매우 견고한 코드로 갈 수 있을 것 같다. 하지만 낯선 개발 방법에 적용하는 시간과 노력, 그리고 그에 따른 시행착오 때문에 실무에 적용하기는 무척 망설여진다. 하지만 단단한 코드를 짜는데 도움을 주는 Unit Test만큼은 꼭 해야겠다고 생각했다.

만약 이제 시작하는 프로젝트면 작성하는 코드를 다 Unit Test를 하겠건만 이렇게 절묘한 타이밍으로 맞아떨어지는 경우가 거의 없다는 게 문제다. 이미 작성된 엄청난 양의 레거시 코드(Legacy code)를 보며 Unit Test를 하고는 싶은데, 어떻게 해야 할지 감이 안 온다. 뭐~ 속 편하게 다음 프로젝트를 할 때는 시작할 때부터 꼭 Unit Test를 해야지하고 생각하고 미뤄버릴 수도 있다. 아니면 기초 라이브러리부터 Unit Test를 하는 방법도 있다. 모든걸 다 테스트해버리겠어! 뭐~ 하다가 지쳐버리겠지만.

하지만, 이 책을 접하고 테스트 없이 작성된 레거시 코드에 새로운 피처(Feature)를 추가하거나 버그를 수정할 때 어떻게 Unit Test를 하는지에 대해 많은 걸 깨닫게 되었다. 저자가 두뇌로만 코딩하는 사람이 아니라 직접 실무에서 온갖 삽질을 다 한 사람인 거 같다. 풍부한 예제와 그 예제를 통해 어떻게 피처를 추가하고 버그를 수정하는지를 보여 주는데, 보면서 많은 감탄을 했다.

동작하는 코드는 위대하다. 구조가 좀 엉망이더라도 어때. 멋진 구조를 가진 제대로 동작하지 않는 코드보다는 위대한 코드임이 분명하다. 하지만 이 코드에 새로운 피처를 추가하거나 버그를 수정하기 위해 코드에 손을 댈 때부터 문제는 시작된다. 좀 엉망이지만 서비스되면서 검증받은 코드를 수정할 엄두가 나지 않아 그 코드를 최대한 유지한 채 작업을 하게 되는데, 이러면서 코드는 더 지저분해지고 뒤로 갈수록 코드 수정에 더 많은 시간이 걸리게 된다. 뭐~ 그 소스 파일을 열면 코드가 워낙 많아서 스크롤바 크기고 쬐그맣게 변한다. 이럴 땐 보통 “휴~ 담에 진짜 리펙토링 한번 해야겠네” 하면서 체크인하고는 파일을 닫는 게 보통이다. 뭐~ 다음이란 없지만…

레거시 코드 동작을 유지한 채 수정사항에 대해 어떻게 Unit Test를 하며 어떻게 Unit Test 대상 클래스를 늘이며 결국엔 Unit Test하에 안전하게 리펙토링을 하는지 이 책을 통해 많이 배웠다. 레거시 코드로부터 자유로운 프로그래머가 있을까? 굳이 TDD나 Unit Test에 관심이 없어도 레거시 코드를 가지고 작업을 하는 프로그래머에게도 도움이 되는 책이다.