프로젝트 리팩토링 어디까지 진행하는 것이 좋을까요?

제목이랑 본문이 다른 질문을 하는 거 같아서 먼저 어디까지 하는게 좋냐는 제목의 질문을 볼게요. 답을 하기 전에 양극단을 한 번 보죠. 극단적으로 리팩터링에만 몰두하고 기능추가를 안하면 엔지니어 이력서에는 리팩터링만 남고 회사가 망해서 월급이 끊길겁니다. 반대로 기능추가에만 몰두한다면 나중에 스파게티가 된 코드베이스 때문에 기능 추가가 매우 더뎌 엔지니어 이력서에 밀도가 낮아지고 역시 회사가 망해서 월급이 끊기겠죠. 저 양극단 사이에서 줄타기를 할 수 있도록 평소에 리팩터링을 위한 여유를 확보하는 것이 가장 적용하기 쉬운 전략이라고 생각합니다. 개발 소요시간을 측정할 때, 항상 리팩터링을 포함해서 측정하세요. 그런 여유도 주지 않을 만큼 회사가 빡빡한 일정을 요구하면 이직도 옵션에 넣으세요. 위의 두번째 극단의 예시처럼 자살골하는 상황이 올 수도 있으니까요. 그리고 다음은 실질적인 리팩터링 전략에 관한 제 생각입니다. 리팩터링은 미래에 발생할 소프트웨어의 유지보수 비용을 낮추는 목적을 가진 엔지니어링 활동입니다. 우리는 엔지니어로서 소프트웨어가 요구사항을 반영하도록 만들어야 합니다. 요구사항이 변했거나 혹은 소프트웨어가 요구사항을 오반영한 상황(버그)가 발견되면 소프트웨어를 수정해야 하는데, 위에서 말한 유지보수의 비용은 이 때 소프트웨어의 어느 부분이 변경이 필요한지, 어떻게 변경을 해야 하는지 알아내고 변경을 했을 때 의도대로 변경이 일어났는지 검증을 하는 전 과정을 포함합니다 이런 유지보수의 비용을 이루는 요소들의 관점에서 리팩터링 전략을 찾아내는 것이 적합하다고 생각해요. 유지보수의 비용의 뿌리는 결국 요구사항과 소프웨어어가 어떻게 변했느냐이기 때문에 프로젝트 A에 반영한 리팩토링 전략이 프로젝트 B에도 효과적일 것이냐는 정답이 없습니다. 그 리팩토링 전략이 왜 프로젝트 A에 효과적이었는지, 그리고 프로젝트 B도 그 전략이 효과적일만한 특성을 갖고 있는지 이해가 필요합니다. 그런 숨겨진 특성들을 찾아내고 유형화하는 것이 엔지니어에게 큰 자산이 될 거라 생각합니다.

개인이나 팀 프로젝트는얼마든지 가능하지만 회사 프로젝트는 아마 못할거라고 생각합니다

최근 출간된 Kent Beck 의 [Tidy First]를 추천 드립니다.