마틴 파울러의 refactoring 15장의 Putting It All Together를 보고 정리한 내용이다.
가장 마지막장의 내용으로 마틴 파울러가 설명한 리팩토링에 대한 내용들을 정리하는 내용인데, 나는 리팩토링의 마음가짐이라고 정리해본다.

리팩토링을 알고 기법이랑 테스트를 알아도 리팩토링을 완전히 이해했다고 볼수는 없다.
리팩토링은 가벼운 마음으로 해야하는데 리팩토링을 하는데 마틴 파울러의 팁이 있다.

경험이 있는 개발자들에겐 어쩌면 당연한 내용들이면서도 생각하고 작업하면 좋을 내용들이어서 정리해본다.

습관적으로 목표를 정하자

코드에서 구린내가 풍기면 구린내를 없야겠다는 결의를 다진 후 목표를 향해 나아가자.
리팩토링의 목표는 아름다운 코드가 아니라 이해하기 쉬운 코드, 퇴화하는 프로그램의 통제력을 되찾는 작업이다.

,

이게 생각보다 어려운 사람들이 있다.
어떤 사람이랑 일하면 당연하게 구린내를 제거하는데 어떤 사람들은 구린내에 냄새를 더 더한다.
개발자는 코가 민감해야 한다는 생각을 같이 일하다보면 느끼게 된다.

확신이 없으면 중단하자

목표를 향해 전진할 때 현재 작업이 프로그램 로직을 보전하리란 사실을 입증할 수 없는 순간이 닥칠 수 있다.
그렇다면 작업을 중단해야 한다.
중단한 시점에 코드가 개선됐다면 결과물을 반영하고 그렇지 않다면 코드를 버린다.

,

코드를 버리는걸 잘 못하는 사람들이 있다.
한 번은 동료가 리팩토링 방향을 잘못잡고 개발한걸 버리지 못하고 넣어서 되잡는데 시간을 더 오래썼다.

되돌아가자

리팩토링은 방향이 잘못들기 쉽다.
테스트를 돌리지 않고 여러 수정이 반영됐다면, 테스트가 도는 시점으로 되돌아가서 다시 수정사항을 반영하며 테스트 결과를 확인하는 것이 더 합리적이다.
1시간을 개발한 코드를 다시 짜는 것은 10분이면 되는데 이걸 디버깅하려면 2시간이 걸릴수도 있다.

,

이건 확신이 없으면 중단하자의 내용과도 이어지는 것 같다.
여기서 중요한건 리팩토링 하면서 중간중간 테스트를 돌려야 한다는 것.

작업은 둘이서 하자

리팩토링은 조심히 체계적으로 해야한다.
내가 보지 못한 부분을 파트너가 챙겨줄 수 있을 것이고.
둘 중 한명이 이해하지 못한다면 리팩토링을 중단해야할 시점이라는 것도 알 수 있다.
포기하고 싶을 땐 함께 작업을 이어갈 수 있다.

,

완전히 동의되지는 않는 부분이기도 하다.
리팩토링을 페어 프로그래밍 하는것도 되겠지만 복합 리팩토링에서의 설계를 같이 나누거나 리팩토링의 한 부분을 나누는 것도 괜찮은 것 같다.
결국 페어 프로그래밍은 꼼꼼한 리뷰로 커버가 되기도 하니까.

두 개의 모자

리팩토링할 땐 리팩토링 전의 기능을 그대로 유지하는것이 필수다.
구린내가 나더라도 일정상 현재 리팩토링을 진행할 수 없다면 리팩토링을 잠시 보류할 필요도 있다.

,

일부 팀원들한테 많이 했던 얘기중 하나는 리팩토링 코드와 기능 개발 코드를 같이 커밋하지 말라는 얘기였다.
라인을 정리한다거나, 클래스 이동 같은 리팩토링이 기능 개발과 같이 들어가서 리뷰가 어려워지고 히스토리 관리가 안되는 경우가 빈번한 사람들이 있다.
리팩토링은 커밋을 나누거나, PR까지 나눠도 좋을 것 같다.

reference

• 마틴 파울러, 리팩토링 15장