[리팩토링 1판] Chaptor 02. 리팩토링 개론

Chapter 02. 리팩토링 개론

리팩토링은 무엇인가

리팩토링: 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업

• 리팩토링의 목적은 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것이다.
• 리팩토링은 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않는다.

🔑 주의점

• 기능을 추가할 땐 코드를 수정하지 말고 기능만 추가해야 한다. 진행 상태를 파악하려면 테스트를 추가하고 그 테스트들이 잘 동작하는지 확인하면 된다.
• 리팩토링할 때는 코드를 추가하지 말고 코드 구조 개선만 해야 한다. 앞서 작성한 테스트는 전혀 추가하지 않고 오로지 코드 구조만 수정해야 한다.

리팩토링은 왜 해야 하나

리팩토링의 가치는 확실하며, 적어도 코드를 언제든 쉽게 이해할 수 있게 만드는 도구임엔 틀림없다.

소프트웨어 설계 개선

리팩토링을 진행하지 않으면 프로그램 설계는 점점 노후된다. 단기적인 목적 때문에 코드를 수정하거나 코드의 설계를 완벽히 이해하지 않고 코드를 수정하면, 코드 구조가 뒤죽박죽되어 그 코드를 보고 설계를 파악하기가 어려워진다. 리팩토링은 그렇게 구조가 산만해진 코드를 정리하는 작업이다.

설계를 개선하는 주요 비법 중 하나는 중복 코드를 없애는 것이다.

소프트웨어를 이해하기가 쉬워지니까

개발자는 다른 사람이 코드를 수정할 경우까지 고려하지 못하는 실수를 하기 쉬운데, 알고보면 이런 코드 이해 대상을 두루 고려하는 일이 제일 중요하다.

개발자가 프로그램을 제대로 실행되게 만드는 데만 집착한 나머지, 그 코드를 나중에 수정하게 될 다른 개발자에 대해 고려하지 않는 점이 문제의 원인이다.

리팩토링에 약간만 시간을 투자하면 코드가 본연의 목적에 더 충실히 실행된다. 그런 점에서 볼 때 프로그래밍에서 가장 중요한 것은 의도한 바를 정확히 전달하는 것이다.

또한 리팩토링을 하면 낯선 코드를 쉽게 이해할 수 있다. 새로운 회사에 가서 코드를 보고 주석이 없어도 "아, 대충 이러한 기능을 하는 메서드구나!" 하고 이해할 수 있게 된다.

최초 단계의 리팩토링은 '우선 창 밖이 보이게 뿌연 유리창부터 닦는 일'과 같다.

버그를 찾기가 쉬워지니까

코드를 파악하기 쉬우면 버그 발견도 쉬워진다. 코드 리팩토링을 하면 코드 기능을 근본적으로 이해할 수 있으며 그 새로운 깨달음을 즉시 코드에 반영한다. 프로그램 구조를 명확하게 만들어서 내가 특정한 전제들이 확실해지면 버그를 놓치는 것이 불가능할 정도가 된다.

프로그래밍 속도가 빨라지니까

이제까지 설명한 요점은 리팩토링이 코드를 신속하게 개발할 수 있게 만들어 준다는 것이다.

어떤 사람들은 리팩토링하는 시간이야말로 속도가 느려진다고 말하지만, 깔끔한 설계야말로 소프트웨어 개발 속도를 높이기 위한 핵심이라고 확신한다.

설계가 깔끔하지 않으면 개발 초기의 아주 잠시 동안엔 진행이 빠를지언정 얼마 못가서 개발 속도가 떨어진다.

리팩토링은 어떨 때 필요한가

리팩토링을 일부러 시간 내서 하진 말라고 답한다. 리팩토링은 따로 시간을 정해서 하면 안되고 일상적으로 틈틈이 해야한다.

같은 작업의 삼진 아웃 때

어떤 작업을 처음 할 땐 그냥 하고, 비슷한 작업을 두 번째 해야 할 땐 중복작업이라 좀 망설여져도 일단 그냥 하고, 세 번째 하게 되면 그때 리팩토링을 진행하는 것이다.

Tip. 같은 작업을 3번째 반복하게 됐을 때 리팩토링을 실시하자.

기능을 추가할 때

• 리팩토링이 필요한 첫 번째 이유: 소프트웨어에 새 기능을 추가해야 할 때다. 이 시점에 해야 하는 이유는 코드를 이해하기 쉽게 만들기 위해서다.
• 리팩토링이 필요한 두 번째 이유: 설계가 지저분해서 어떤 기능을 추가하기 힘들 때다.

버그를 수정할 때

버그를 수정할 땐 주로 코드를 이해하기 쉽게 만들려고 리팩토링한다.

코드를 검수할 때

코드를 정기 검수하는 것만큼 효과적인 일도 없다. 코드 검수를 통해 개발 팀원 모두가 코드를 파악하게 되며, 선임 개발자가 경험이 적은 개발자에게 지식을 전수하는 결과도 얻게 된다.

위에서 말한 코드 검수는 흔히 코드 리뷰라고 부르는 것 같다.

자신의 코드는 자기가 볼 땐 쉬울지 몰라도 다른 팀원은 알아보기 힘들 수 있다. 혼자서는 일주일에 아무리 많은 아이디어를 떠올려도 생각에 그치게 되지만, 다른 이들의 도움을 얻으면 모든 일이 훨씬 쉬워지니 코드 검수를 자주 하는 것이 좋다.

프로그램은 다음 4가지 상황일 때 수정하기 힘들어진다.

• 코드를 알아보기 힘들 때
• 중복된 로직이 들어 있을 때
• 추가 기능을 넣어야 해서 실행중인 코드를 변경해야할 때
• 조건문 구조가 복잡할 때

리팩토링은 실행중인 프로그램이 기능을 바꾸는 작업이 아니고, 신속한 개발 공정을 가능하게 하는 이런 성질을 가중하면서 가치를 높이는 일이다.

주의점. 프로젝트 일정이 코앞일 경우 리팩토링을 삼가야 한다. 그리고 언제나 시간에 쫓긴다면 그건 리팩토링해야 한다는 신호이다.

성능

리팩토링을 수행한 후 소프트웨어를 깔끔하게 설계하면 최적화에 도움이 된다.

• 성능 튜닝에 할애할 시간이 생긴다.
• 코드가 잘 쪼개져 있어서 기능 추가도 더 신속히 이뤄진다.
• 그로인해 더 많은 시간을 성능에만 집중할 수 있다.
• 프로그램을 잘 쪼개면 성능을 분석할 때 더 정밀한 분석이 가능해진다.
• 코드가 더 깔끔해지니 튜닝을 더 확실히 이해할 수 있고, 어느 튜닝이 더 효과적인지 판단할 수 있다.

느낀 점

리팩토링은 필수적으로 해야한다는 점과 리팩토링을 진행하면 여러 이점이 있다는 것에도 100% 동의한다.

특히 소프트웨어 설계 개선 부분과 프로그래밍 속도가 빨라지니까 부분이다.

실제로 전 회사에서 2년 4개월 동안 있으면서 기능들이 끊임없이 들어왔다. 그 과정속에서 기능이 계속 추가되고, 코드의 품질이나 설계는 고려하지 않고 개발하다보니 코드가 굉장히 난잡해졌다.

유일하게 개발팀은 사수와 나 둘이 있었는데, 여기서 난잡해진 코드를 점점 유지보수하기가 어려워져 회의때 잠시 턴을 두고, 개선하자는 의견이 나왔다. 하지만 개선이라는 단어가 무색하게 그런건 신경쓰지 않고 기능만 계속 만들라고 지시하게 된다.

일정은 계속 촉박하니, 사수와 나는 결국 지쳐서 사수가 먼저 퇴사하게 되었다. 난잡해진 코드에 더 난잡해지니 정말 감당하기가 어려울정도로 되었고, 수정하기도 굉장히 빡셌다.

리팩토링은 틈틈이 진행하지 않으면, 집에 부채가 쌓이는 것처럼 코드라는 부채가 점점 쌓이게 된다. 부채가 감당되지 못할 만큼 쌓이게 된다면 결국 파산하고 말 것이다.

따라서 리팩토링을 한다는 것은 설계가 깔끔해지고, 개발 속도도 현저히 빨라지는 것이다.

만약 회사에서 리팩토링할 시간을 주지 않는다면, 일정을 잡을 때 원래 기능의 2배의 기간을 달라고 한다. 그리고 기능을 먼저 끝내고, 리팩토링을 진행하면 부채 쌓이는 것을 막을 수 있다고 생각한다.

References

• 리팩토링 1판