리팩토링은 점진적으로 그리고 테스트 작성부터

최근 회사도 그렇고 예전 회사에서도 프로젝트에서 좀 더 나은 구조를 위해 리팩토링을 시도한 적이 있습니다.

 

단순히 아름다운 구조가 아니라 지금 상태로 가면 나중에 문제가 크겠다 싶어(특히 예전 회사에서) 대대적인 리팩토링을 진행했었습니다.

 

하지만 안타깝게도 해당 리팩토링들은 결국 머지가 되지 못했습니다.

 

그 이유는 아래 4가지 정도 되는 것 같습니다.

 

1. 내가 작성하지 않은 부분에 대해서는 이해하기 위해 시간이 많이 필요하다.
2. 대대적인 수정이기 때문에 확인할 것들이 많고 하나씩 확인하다보면 시간이 많이 필요하다.
3. 수정하고 있다보면 기존 코드에 수정이 발생하고 그것을 리팩터링 브랜치에도 반영해야 하니 시간이 더 걸린다.
4. 리팩토링 할 것 이외에도 일이 많아 리팩토링 작업에 생각보다 시간을 많이 쓸 수 없다.

몇번의 실패를 통해 대대적인 리팩토링은 성공하지 못하는구나를 깨달았습니다.

하지만 그렇다고 해서 어떻게 해야하는지를 알게 된 것은 아니었는데요.

 

이번에 클린코더스 강의를 보면서, 또 현재 회사에서 2번의 구조 변경하면서 한번은 실패, 한번은 성공한 경험을 통해 알게 된 것을 정리해보았습니다.

1. 리팩토링은 계획을 세우고 점진적으로 해야 한다.

이번에 회사에서 잘되었던 구조 변경은 생각해보니 전체로는 조금 규모가 있었지만 하나씩 단계적으로 진행했었습니다. 

해당 부분에 대해서는 각 스텝이 제 머리에 잘 그려져서 그랬던 것 같습니다.

 

그런데 실패했던 것들을 생각해보면 전체적인 그림은 있는데 단계적으로 어떻게 할지 고민해보지 않았었네요..!

 

그래서 리팩토링 전에 개별적으로 머지 가능한 각 단계별로 쪼개고 구체적으로 어떻게 진행 것인지 계획을 세우는 것이 좋겠습니다.

 

2. 리팩터링을 할 때 가장 먼저 할 일은 리팩토링할 대상의 테스트를 작성하는 것이다.

클린코더스를 통해 배운 것인데 무엇을 리팩토링 하기 전에 먼저 그 기능의 동작을 확인해줄 테스트를 먼저 작성하는 것이 필요했습니다.

예전에는 테스트 코드 작성하는 것이 더 시간이 걸리는 것 같아 그냥 수동으로 확인했었는데요. 좋은 선택은 아니었네요.

 

테스트를 작성해두면 내가 진행하는 리팩토링 시에도 기능의 정상 유무도 쉽게 확인할 수 있지만

해당 테스트를 이용해 다른 사람들도 쉽게 리팩토링 할 수 있으니 좋을 것 같습니다.

 

그리고 리팩토링을 하지 않더라도 테스트 코드를 만들어 둔다면 나쁠 것은 없겠죠.

 

3. 리팩토링 후의 진짜 가치가 있는 것인지 생각해본다.

오버 엔지니어링을(헛수고를) 안 할 수는 없지만 그래도 줄일 수는 있습니다.

좋은 아이디어가 떠오르면 우선 구현부터 하고 보았는데.. 구현 완료 후 보니 더 쉬운 방법으로 해결할 수 있었고 기존 코드에 비해 크게 나아졌다고 하기 어려운 경우도 많았습니다.

 

정말 이게 기회비용(들이는 시간 or 다른 방법)까지 고려했을 때도 시간을 들일만한 가치가 있는지를 키보드를 치기 전에 고민해본다면 많은 시간을 줄일 수 있을 것 같습니다.