리팩토링 개론

리팩토링은 무엇인가?

---

• 리팩토링이란 두 가지로 정의할 수 있습니다. 
• 첫째, 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 쉽게 소프트웨어 내부를 수정하는 일
• 둘째, 리팩토링 기법을 연달아 적용해 겉으로 드러나는 기능은 그대로 둔 채, 소프트웨어 구조를 변경하는 일

 

💡 리팩토링의 목적

• 우리가 만든 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것, 즉 오늘의 기능은 정상적으로 수행하면서 내일의 변경에 유연하게 수용할 수 있도록 만들기 위함이라고 생각합니다.

켄트백의 모자 두 개 이야기

• 소프트웨어 개발 시 기능 추가 작업과 리팩토링 작업은 구분해야 하지만 우리는 기능 추가 모자와 리팩토링 모자를 번갈아 쓰게 됩니다. 처음 새 기능을 추가하다가, 지금까지 만든 기능의 구조를 변경하면 작업이 쉬워지겠다는 생각이 들면 잠시 리팩토링 작업으로 전환한 뒤 다시 새 기능 추가 작업으로 전환하고 이러한 과정을 반복하게 됩니다.

 

리팩토링을 해야하는 이유

---

1. 소프트웨어 설계가 개선된다.

• 리팩토링을 하지 않는다면 프로그램 설계는 노후됩니다. 빠른 시일 내에 기능을 추가할 때 코드 구조는 엉망이 될 수 있습니다. 이러한 구조는 시간이 지날수록 점점 엉망이 되며, 결국 유지보수가 힘들어지며 코드의 중복을 초래할 수 있습니다. 코드 중복은 팀원들의 신뢰를 깨버릴 수 있으며 이러한 이유로 리팩토링을 해야합니다.

2. 코드 파악이 쉬워집니다.

• 우리는 혼자서 일하는게 아닙니다. 다른 팀원들과 함게 프로그래밍을 하므로 나만 알아볼 수 있는 코드가 아닌 우리가 알아볼 수 있는 코드를 작성해야합니다. 

3. 버그를 찾기 쉬워집니다.

• 리팩토링을 진행할 때 코드의 기능을 근복적으로 이해할 수 있으며, 그 새로운 깨달음은 즉시 코드에 반영됩니다. 이러한 과정을 통해 버그를 찾기 쉬워질 수 있습니다.

4. 프로그래밍의 속도가 빨라집니다.

• 리팩토링을 진행하면 설계 개선, 가독성 향상, 버그 감소 등 코드의 질을 높일 수 있습니다. 다만 이러한 과정은 시간이 소모되며 이로 인해 개발 속도가 느려질 수 있다고 생각할 수 있습니다. 하지만 리팩토링을 진행하지 않는다면 개발 초기에는 진행 속도가 빠를지 몰라도 추후 새로운 기능을 추가하는 시점에는 속도가 현저히 떨어질 수 있습니다. 시스템 이해 -> 중복 코드 파악 -> 개선 이러한 과정을 거쳐야 합니다.

 

리팩토링은 어떨 때 해야할까?

---

1. 같은 작업이 3번 발생할 경우

• 어떤 작업을 처음할 땐 그냥하고, 비슷한 작업을 두 번째 해야할 땐 중복의 냄새가 나더라도 그냥 하고, 세번째 하게 된다면 그때 리팩토링을 실시합니다.

2. 기능을 추가할 때

• 기존 코드에 새로운 기능이 추가될 경우 OCP 원칙을 준수하지 않았다면 새로운 기능을 추가하고자 할 때 괴로울 수 있습니다. 이때 
  "코드를 이런식으로 했다면 더 쉬웠을텐데" 라는 생각이들 때 과거 잘못에 연연하지 않고 리팩토링을 진행해야 합니다.

3. 버그를 수정할 때

• 버그를 수정할 땐 주로 코드를 이해하기 쉽게 만들기 위해 리팩토링을 진행합니다. 코드의 기능을 파악하려다 이해하기 쉽게 만들려고 리팩토링을 실시합니다. 이렇게 적극적으로 리팩토링을 하다보면 버그를 찾기 쉬워집니다.

4.코드를 검수할 때

• 우리는 작업을 하고 PR을 통해 개발 팀원 모두가 코드를 파악하게 되며 보통 경험이 많은 개발자가 경험이 적은 개발자에게 지식을 전수하는 결과도 얻게 되며, 자신의 코드는 자신이 볼 때 쉬울지 몰라도 다른 사람이 볼 때 어려울 수 있습니다. 

 

리팩토링 관련 문제들

---

💡 인터페이스 변경

• 퍼블릭 인터페이스의 이름을 변경하는 기법은 그 자체가 인터페이스를 수정하는 작업입니다. 메서드를 사용하는 모든 코드에 접근할 수 있다면 큰 문제가 되지 않지만 접근을 못하게 된다면 인터페이스명을 변경한 경우 큰 문제가 발생할 수 있습니다. 이러한 문제의 해결 방법은 새로운 퍼블릭 인터페이스를 만든 후 해당 인터페이스가 기존 인터페이스를 호출하게 끔 만드는 것입니다.

💡 리팩토링을 하면 안되는 상황

• 처음부터 코드를 새로 작성해야 할 때 리팩토링을 하지 말아야합니다. 기존 코드가 지극히 지저분해서 리팩토링은 가능하지만 차라리 완전히 새로 작성하느게 더 쉬울때도 있습니다. 
• 프로젝트 마감일이 얼마 남지 않았을 경우 리팩토링을 삼가해야합니다. 

 

리팩토링과 설계

---

• 리팩토링은 설계를 보완하는 특수한 역할을 합니다. 기획자, PM 등이 설계를 완벽히 하더라도 코드를 작성하다보면 항상 빈틈이 있기 마련입니다. 이러한 빈틈은 리팩토링을 하면서 틈틈히 채워나가야 합니다.
• 리팩토링을 하지 않는다면 사전 설계는 완벽하게 해야하며 추후 설계를 수정하려면 큰 비용을 지불해야 합니다. 그렇기 때문에 사전 설계에 많은 투자를 해야합니다. 반면 리팩토링을 진행한다면 어느정도의 설계만 있으면 됩니다. 이 설계를 통해 만들어가면서 문제를 더 잘 이해하게 되며 최상의 솔루션은 처음 생각과는 다르다는 것을 인지하게 됩니다. 또한 이러한 과정을 통해 설계가 단순해질 수 있습니다.

 

리팩토링과 성능

---

• 리팩토링을 통해 프로그램을 잘 쪼개면 두 가지 측면에서 최적화 방식에 도움이 됩니다.
• 첫째, 성능 튜닝에 할애할 시간이 생깁니다. 코드가 잘 쪼개져 있어서 기능 추가도 신속히 이루어지며, 그로인해 더 만은 시간을 성능 튜닝에만 집중할 수 있습니다.
• 둘째, 프로그램을 잘 쪼개면 성능을 분석할 때 더 정밀한 분석이 가능해집니다. 프로파일러가 더 작은 코드 부분을 찾아주기 때문에 튜닝에 더 쉬워집니다.