리팩토링 시점과 절차, 리팩토링이 필요한 이유

오래전 강연이지만 인상깊어 간단하게 정리하는 글..

마틴 파울러 강연 정리 (강연 링크 : https://www.youtube.com/watch?v=mNPpfB8JSIU)

 

TDD(Test-Driven Development) Refactoring

개발 과정은 아래 2단계로 나뉘어지고, 개발자는 항상 두 단계 중 하나만을 수행하도록 고려해야 한다.

(하지만.. 개발을 하다보면 생각보다 두 단계를 나눠서 개발하는 것은 쉽지 않은 것 같다..)

• 기능구현 단계
  • 실패 테스트에서 시작해서 성공테스트가 될때까지
  • 새로운 로직들이 추가되어 감
  • 코드를 잘 짠다기 보다는 일단 기능이 동작하도록 하는 것이 중요
• 리팩토링 단계
  • 기능은 동일하나, 새로운 코드로 만들기
  • 중복 코드 제거 및 정리
  • 테스트 코드를 통해 기존 기능이 잘 동작하는지 체크해서 실수가 없도록 함.

이 강연에서 설명하는 핵심은 두 단계를 나눠서 생각하고 개발하는 것.

만약 리팩토링을 하다가 버그가 발견되면 "리팩토링 단계"에서 버그를 수정하는 것이 아니라, 리팩토링을 멈추고 "기능구현 단계"로 돌아 가 고쳐야 함.

• Why? 리팩토링의 본질
  • 리팩토링이란 새로운 기능을 만드는 것이 아니라 기능이 이전과 동일하게 동작하면서 소프트웨어 내부 설계를 더 높은 수준으로 진화시키는 것.

그래서 "기능구현 단계"와 "리팩토링 단계"를 언제든지 변경할 수 있지만 한번에 한가지 단계만 수행해야 한다.

 

언제 리팩토링을 수행해야 하는가?

이 강연에서는 리팩토링을 5가지로 나누어 설명하고 있다.

- 쓰레기 줍기 리팩토링
- 이해를 위한 리팩토링
- 준비를 위한 리팩토링
- 계획된 리팩토링
- 장기적인 리팩토링

쓰레기 줍기 리팩토링

젤 하위 단계의 리팩토링이다. 발견하는 즉시 사소한 수정이라도 조금씩 그때그때 더 나은 코드로 만들어 나가는 리팩토링

• 좋지 않은 혹은 이상한 코드를 발견하면 정리
• 코드를 깨끗한 상태로 만듦
• 아주 작은 변경사항일지라도 이 전보다 나은 코드를 만듦

이해를 위한 리팩토링

다른 사람이 개발했거나, 레거시 코드들을 보게 되면 하고싶어지는 리팩토링.. 코드를 보았을 때 잘 이해가 가지 않는다면 이해하기 쉽도록 정리해야 한다. 이해하기 쉬운 코드로 리팩토링하여 다음 작업 시 작업 시간을 줄여줄 수 있다.

• 코드를 봐도 이해가 가지 않는 코드를 발견하면 정리
• 해당 코드를 힘들게 이해하더라도, 다음에 보면 이 코드는 똑같이 이해하기 어려운 코드
• 다음에 코드를 보는 사람은 작업이 수월하도록 이해한 로직을 코드로 녹여내는 것.

준비를 위한 리팩토링

새로운 코드를 도입하기 전에 기존 코드를 새 코드를 도입하기 위해서 리팩토링을 해야하는 경우이다. 실제로 개발하다보면 이러한 리팩토링이 필요한 경우가 많다..

• 새로운 기능을 하는 코드를 작성 했는데, 왜 이렇게 동작하는지 모르겠는 경우
• 새로운 코드를 추가했더니, 기존 구조와 달라지고 적절하지 않은 경우
• 리팩토링을 통해 기존 코드를 수정하고, 리팩토링된 코드 위에 새로운 코드를 추가해야 함

계획된 리팩토링

이 경우는 프로젝트를 진행하려고 할때 해당 프로젝트 범위에 아예 리팩토링 단계를 넣어버리는 것이다. 하지만 개발에 대해 모르는 사람이라면 리팩토링이 왜 필요한지 잘 모르고 필요성을 잘 느끼지 못하기 때문에 이유나 명분이 있어야 한다.

• 프로젝트 계획에 리팩토링 단계를 넣어 매번 코드를 깔끔하게 만들기
• 시점이 매우 명확한 리팩토링
• 그러나 리팩토링을 해야할 이유 또는 명분을 찾아야 하므로 지양 하는 것이 좋음

장기적인 리팩토링

장기적인 리팩토링은 커다란 의존성을 갖는 복잡한 코드를 수정할 때 처음부터 정해진 목표와 계획을 가지고 진행하는 리팩토링이다.

• 복잡한 의존성을 갖는 커다란 모듈을 수정해야 하는 경우
• 코드를 어떻게 고쳐야 할지 장기적인 비전과 명확한 목표가 있어야 함
• 최대한 작은 단위로 나누어 정해진 목표에 맞게 코드를 수정하는 것이 중요

 

리팩토링이 필요한 이유

이 강연에서는 리팩토링이 필요한 이유에 대해 이 그래프로 설명하고 있다. 

초기에는 그냥 아무렇게나 코드를 짜도 기능만 정상적으로 동작한다면 개발 속도가 빠르다고 느낄 수 있을 것이다. 하지만 서비스가 성장하고 많은 개발자들이 개발에 참여함에 따라 초기의 코드 위에서는 수많은 개발들이 추가적으로 일어날 것이다. 그렇게 되면 결국 어느순간 기존의 코드로 인해 개발속도가 더 느려지는 순간이 온다. 이때가 바로 리팩토링을 해야 하는 코드이다. 그래서 개발자로써 전문성을 가지고 있다면 항상 클린한 코드를 만들려고 노력해야 한다. 코드위에선 오직 개발자만이 좋은 설계를 가져갈지 나쁜 설계를 가져가서 느린 개발을 할지 선택할 수 있기 때문이다. 

마틴 파울러는 개발자가 클린한 코드를 만들지 않는다면 고객을 도둑질하는 것과 같다고 말한다. 회사로 하여금 새로운 기능을 만들 때 더 많은 돈과 시간을 쓰게 하기 때문이다. 그렇기 때문에 개발자는 자신이 하는 일이 어떻게 경제적으로 영향을 미치는지 판단해야 한다고 한다. 그렇게 때문에 리팩토링은 경제성 때문에 항상 해야한다고 말했다. 클린한 코드는 새로운 기능개발을 더 빠르게 한다.

 

이 강연을 듣고..

처음엔 리팩토링은 단순히 코드 생산성과 내가 보기 좋은, 만족스러운 코드 개발을 위해서 한다고 생각했다. 하지만 마틴 파울러가 말하는 바에 공감했고, 결국 내가 개발하는 코드는 회사의 경제성에 영향을 미친다는 것을 항상 염두에 두고 리팩토링의 필요성에 대해 더욱더 느끼게 되는 계기가 되었다. 시간이 부족하더라도 조금이라도 더 나은 코드를 위해 책임감을 가지고 개발해야 겠다는 생각이 들었다..

개발자라면 한번쯤 들어볼만한 강의라고 생각된다.