[강연] 마틴 파울러의 강연 정리 - 리팩토링 시점과 절차, 리팩토링이 필요한 이유

아래의 내용은 마틴 파울러의 강연 내용을 정리한 것입니다.

 

 

 

1. TDD(Test-Driven Development, 테스트 주도 개발)과 리팩토링

---

[ TDD(Test-Driven Development) Refactoring ]

리팩토링이 필요한 대표적인 순간은 TDD로 개발할 때이다. TDD 프로세스는 다음과 같다.

• 기능구현
  • 실패 테스트 → 성공 테스트
  • 새로운 로직들이 추가됨
  • 코드를 잘 짜기 보다는 기능이 동작하는 것이 중요함
• 리팩토링
  • 중복 코드 제거 및 깔끔하게 정리
  • 기능은 동일하고 새로운 코드를 만듬
  • 테스트 코드를 통해 실수가 없도록 함

 

 

TDD가 아니여도 개발 과정은 "기능구현"과 "리팩토링" 두 단계로 나뉘어지는데, 언제든지 두 과정으로 서로 전환할 수 있다. 예를 들어 리팩토링을 하다가 버그를 발견하면, 리팩토링을 멈추고 기능 구현으로 넘어갈 수 있는 것이다. 개발 과정이 두 가지로 나뉘어지는 이유는 개발자가 가져야 할 자세가 다르기 때문인데, 리팩토링은 기능 개발과 달리 다음의 특징들을 갖는다.

• 프로덕션 코드를 조금 수정하고 테스트를 실행해 기능의 이상 유/무를 확인함
• 이슈가 있다면 롤백하고 다시 돌아가서 작업 진행
• 리팩토링 시에는 기능을 변경하지 않아야 함
• 버그가 나와도 버그를 수정하는 것은 기능을 바꾸는 것이므로 리팩토링이 아님

 

리팩토링의 특징을 보면 명백히 기능 개발과 다른 프로세스임을 파악할 수 있다. 만약 리팩토링을 하다가 버그가 발견되면 "리팩토링 단계"에서 버그를 수정하는 것이 아니라, 리팩토링을 멈추고 "기능구현" 단계로 돌아가 고쳐야 한다.

그렇다면 언제 리팩토링을 해야 하는지 결정하는 것이 중요한데, 이에 대해서 알아보도록 하자.

 

 

 

 

 

2.  리팩토링 시점 혹은 절차

---

[ 리팩토링 시점 혹은 절차 ]

그렇다면 리팩토링을 언제 해야하는지 리팩토링의 시점을 캐치하는 것이 중요하다. 리팩토링의 시점 혹은 절차는 여러 가지로 나뉘어지는데, 참고로 TDD에서 수행하는 리팩토링은 TDD 리팩토링이라고 한다.

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

 

 

쓰레기 줍기 리팩토링

• 좋지 않은 혹은 이상한 코드를 발견하면 정리하는 것
• 코드를 이전처럼 깨끗한 상태로 만듬
• 아주 작은 변경사항일지라도 이전보다 더 나은 코드를 만들어야 함

코드가 잘 동작하더라도, 코드에 대한 비판적인 생각이 든다면 그것은 리팩토링의 신호이다. 좋지 않은 코드를 발견하면 리팩토링을 해야하는데, 어느 정도 진행할지 결정하는 것도 중요하다. 다만 핵심은 아주 조금이라도 이전보다 더 나은 코드를 만드는 것이다.

 

 

 

이해를 위한 리팩토링

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

이해를 위한 리팩토링은 이해가 어려운 코드를 이해하기 쉬운 코드로 리팩토링하는 것이다. 지금 이해한 코드는 나중에 다시 봐도 이해하기 어려우며, 이 코드를 보는 다른 사람들도 비슷하게 시간을 낭비하게 된다. 또한 이해하는 과정에서 추론에 의존하게 될 수도 있다. 이 코드를를 개선하면 다음에 코드를 보는 사람은 작업이 수월해지므로, 지금 이해한 로직을 코드로 녹여내야 한다.

이는 쓰레기 줍기 리팩토링과 유사한데, 쓰레기 줍기 리팩토링은 수정 대상이 이상한 코드인 반면에 이해를 위한 리팩토링은 이해하기 어려운 코드라는 점에서 차이가 있다.

 

 

 

준비를 위한 리팩토링

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

준비를 위한 리팩토링은 새로운 기능을 개발할 때 흔히 사용된다. 만약 새로운 코드를 적용했을 때 코드가 적절하지 않다는 생각이 들면, 리팩토링을 통해 기존의 코드를 정리하고 다시 신규 기능을 추가해야 한다.

리팩토링을 하느라 기능 구현할 시간을 뺏긴다고 생각할 수 있다. 하지만 실제로는 (모든 경우는 아닐지라도) 리팩토링을 하여 더 빠르게 개발 할 수 있다. 즉, 준비를 위한 리팩토링을 하면 더 빠르게 기능을 추가할 수 있는 것이다. 그러므로 새로운 코드가 기존 코드에 잘 녹아들지 않는다고 생각될 때는 신규 코드 작성을 멈추고 리팩토링을 한 후에 기능을 추가하는 것이 좋다.

 

 

 

계획된 리팩토링

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

계획된 리팩토링은 프로젝트 계획에 리팩토링을 넣어 해당 시점에 매번 코드를 정리하는 것이다. 이는 정해진 시점이 있으므로 언제 해야하는지 매우 명확하다. 하지만 리팩토링을 해야하는 이유 혹은 명분을 찾아야 하며 언제든지 쉽게 포기하고 타협할 수 있으므로 지양해야 한다.

역량이 좋은 팀은 알아서 수시로 리팩토링을 할 것이므로, 이는 리팩토링을 하지 않는 팀에게 필요하다. 리팩토링은 조금씩 꾸준히 항상 깨끗한 코드를 위해 진행하는게 맞지만, 물론 안하는 것보다는 이거라도 하는게 낫다. 즉, 필요악이므로 상황에 맞게 하도록 하자. 

 

 

 

장기적인 리팩토링

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

장기적인 리팩토링은 복잡한 의존성을 갖는 커다란 모듈을 수정해야 하는 경우이다. 이를 위해서는 코드를 어떻게 고쳐야 하는지 장기적인 비전과 명확한 목표가 있어야 하는데, 예를 들어 "리팩토링을 거치면 우리 코드는 이런식으로 바뀌어야 한다." 라는 구체적인 목표가 있어야 하는 것이다. 그리고 이를 향해 매주 작은 단위로 매주 매달 수정하면서 목표에 도달해야 한다.

장기적인 리팩토링은 앞서 설명했던 리팩토링 절차들을 반복적으로 수행해야 하는데, 계획된 리팩토링은 적용이 불가능하므로 제외이다. 리팩토링할 때 가장 좋은 방법은 최대한 작은 단위로 수행하는 것이다. 작은 단위로 코드의 수정을 반복하며 계속해서 목표에 도달해야 한다.

 

 

 

 

 

3. 리팩토링이 필요한 이유

---

[ 리팩토링이 필요한 이유 ]

우리는 리팩토링을 왜 해야하는가? 일반적으로 동작하는 코드를 변경하는 일은 한번 더 작업을 하는 것이므로 시간낭비라고 생각하기 쉽다. 하지만 Design Stamina Hypothesis(디자인-스테미너 가설)에 따르면, 시간이 지날수록 복잡한 코드와 씨름하느라 개발 생산성이 저하된다. 즉, 소프트웨어 설계에 신경쓰지 않으면 계속해서 개발 속도가 저하되는 것이다. 

 

 

반대로 설계에 신경을 쓰면 새로운 기능 개발이 쉬워지는데, 리팩토링은 코드를 항상 깔끔한 상태로 만들어서 좋은 아키텍처로 가도록 유도한다. 그래서 훨씬 더 많은 기능을 빠르게 구현할 수 있으며 이게 바로 리팩토링이 필요한 이유이다. 

일부는 좋은 품질(Quality) 혹은 클린 코드(Clean Code)를 위해 리팩토링이 필요하다고 얘기한다. 혹은 우리는 전문가(Professional)이므로 나쁜 코드가 아닌 올바른 방향(Right Things)을 추구해야 한다고도 한다. 하지만 이는 리팩토링이 필요한 본질적인 이유가 아니며, 리팩토링이 필요한 이유는 경제성(Economics)이다. 많은 기능을 빠르게 적용하기 위해 리팩토링이 필요한 것이다.

리팩토링의 범위를 다루고 진행 여부를 결정하는 것은 어려운데, 그 이유는 리팩토링이 코드 위에서 일어나기 때문이다. 즉, 오직 개발자만이 좋은 소프트웨어 설계를 가져갈 지 선택할 수 있다. 개발자들은 일반적으로 문제가 있을법한 코드를 얘기하기 원치 않는데, 개발자로써 전문성이 있다고 생각된다면 코드를 항상 깔끔하게 만들어야 한다. 만약 개발자가 코드를 깔끔하게 만들지 않는다면 도둑질하는 것이며, 회사에게 더 많은 돈과 시간을 쓰게 하는 것이다. 그러므로 개발자는 하는 일이 어떻게 경제적으로 영향을 미칠지를 기준으로 판단해야 한다.

 

 

 

위의 내용은 유튜브 영상의 내용을 기반으로 정리한 내용입니다. 시간이 되시는 분들은 영상을 직접 참고해보시는 것을 추천드립니다!

감사합니다:)