[리팩토링 1판] 마지막 챕터

마무리 챕터

Chapter 13. 리팩토링, 재사용, 현실성

• 리팩토링은 프로그램 구조를 수정해서 설계를 더 이해하기 쉽게 만든다.
• 프레임워크를 개발하고 재사용 가능한 구성 요소를 뺴낸다.
• 프로그램 구조를 단순화한다.
• 나중에 손쉽게 기능을 추가할 수 있게 하는 방편이다.

이처럼 리팩토링을 실시하면 과거에 시간과 비용을 투자해 만든 코드를 활용하고, 중복 코드를 줄이며, 프로그램을 간소화할 수 있다.

리팩토링 왜 안할까?

위의 장점에도 불구하고 왜 리팩토링을 하지 않을까?

1. 리팩토링 방법을 몰라서
2. 리팩토링의 장점은 오랜 시간이 흘러야 가시화될테고, 그때가 되면 프로젝트 팀원도 아닐텐데 공연히 리팩토링에 힘 뺄 필요 없어서
3. 코드를 리팩토링하는 일을 추가적인 부담인데다, 월급은 새 기능을 추가하라고 주는거지 리팩토링하라고 주는건 아니라서
4. 리팩토링하다가 괜히 멀쩡한 프로그램을 망가뜨릴까 걱정되서

개인적인 느낌

사실 1번을 제외하고 2, 3, 4번에 모두 해당될 것 같다. 특히나 SI의 경우 일정이 굉장히 빡빡하고, 개발해주는 회사가 직접 유지보수를 하지 않는 경우에 신경써서 할 필요성을 못 느낄 것이다. 더군다나 신경써서 만든다고 일정이 늘어난다면 발주처에서는 이를 이해하지 못할 것이다.

스프링 프레임워크의 경우 정말 리팩토링의 리팩토링의 리팩토링을 거듭해서 만든 프레임워크임에 틀림없다. 객체의 역할과 구현을 철저하게 분리하여 개발자(클라이언트)들에게 확장 가능성 있는 개발을 하게 만들었다.

스프링 프레임워크도 처음부터 코드가 엄청 깔끔하진 않았을 것이다. 스프링도 거의 20년 세월이 흐르면서 여러 피드백을 통해 릴리스된 것이다. 그래서 우리는 이러한 스프링을 잘 활용한다면 어느정도 리팩토링의 수고를 덜할 수 있다.

하지만, 리팩토링의 기본적인 기법들을 인지하여 우리가 코드를 작성할 때 나중에 유지보수하기 좋은 코드인지 항상 생각하면서 코드를 작성하는 습관이 중요한 것 같다.

리팩토링을 습관처럼

여러 측면에서 리팩토링은 운동이나 적절한 식습관과도 같다. 운동을 꼭 해야하며 균형잡힌 식사를 해야한다는걸 모르는 사람은 없다.

결국 변명거리는 언제든 찾을 수 있지만, 계속해서 좋은 습관에 등돌리고 살면 결국 자기만 손해다.

대다수는 좋은 습관을 이따금이나마 실천하려 한다. 그러나 나머지 소수는 자신의 건강 상태가 최악으로 치달아 증상으로 나타날때까진 뭔가 해야겠다는 의지를 거의 느끼지 않는다.

리팩토링 안전하게

• 자신의 코딩 능력에 신념을 갖자.
• 자신이 놓친 에러는 컴파일러가 잡아서 처리하리란 믿음을 갖자.
• 컴파일러마저 놓친 에러는 테스트가 잡아 처리하리란 신뢰를 갖자.
• 테스트에서 놓친 에러는 코드 검수 단계에서 발견하리란 확신을 갖자.

개인적인 느낌

리팩토링을 운동이나 식습관도 같다라는 표현은 참 적절한 것 같다. 운동 같은 경우 단기적으로 빠르게 다이어트나 벌크업할 수 있지만, 이것이 과연 효과가 좋은걸까?

실제 보디빌더도 단기적으로 수행해내는 것은 좋지 않다고 말한다. 부작용이 있을 수 있거나 꾸준히 하기가 힘들어진다는 피드백이다. 공감한다.

운동은 건강,힘,체력,근육 등 본인을 위해 좋은 습관이다. 하지만 이를 3개월만에 다 이루겠다는 것은 마치 네카라쿠배에 6개월만에 취업하겠다는 소리와 마찬가지이다.

길게 봐야 한다. 만약 지금 개발이 재미없고 힘들기만 한다면 조금 쉬면서 취미 생활을 해주는 것도 중요하다. 중요한 것은 개발을 포기하지 않는 것이다. 만약 백엔드가 지겹다면 다른 IT 분야에도 도전해봐라. 꼭 그 분야에 최고가 될 필요가 없다. 다른 시니어 개발자들도 번아웃이 와서 기획자로 일하다가 다시 개발자로 돌아가는 경우도 있다.

그러니 인생 목표를 너무 한 곳만 바라보지 말고, 현재 주어진 상황에서 최선을 다하되, 열린 마음으로 다른 길들도 가보았으면 좋겠다.

Chapter 14. 리팩토링 도구

intellij를 사용한다면 좋은 리팩토링 도구를 제공해준다. 이를 활용하면 손쉽게 리팩토링을 할 수 있다.

• 메서드 추출
• 상수 분리
• 등등..

이러한 좋은 도구들을 잘 활용하는 것이 개발자의 몫이다. 하지만 이러한 도구의 도움을 받는다면 반드시 테스트를 해봐야 한다.

도구를 제작하는 목적은 사람이 할 특수한 작업을 보조하기 위해서다. 사람은 누구나 자신의 작업 방식에 맞지 않는 도구는 사용하지 않는다. 도구는 리팩토링 절차를 다른 도구와 연동해야 한다는 점이 가장 필수적인 요건이다.

요즘은 VCS인 Git을 주로 사용하는데, 리팩토링용 브랜치를 하나 만들어서 리팩토링을 진행하면 된다. 만약 리팩토링이 내 생각만큼 잘 안된다면 다시 되돌리거나 해당 브랜치를 그대로 삭제하면 되기 때문이다.

따라서 Git을 사용하지 않는다면 그냥 백업해두는 것도 괜찮고, Git을 사용한다면 브랜치를 만들어서 리팩토링 해보자.

Chapter 15. 조각 맞추기

마무리 챕터이다. 리팩토링을 알게되었고, 카탈로그도 공부했으며, 주요사항도 전부 알았다.

리팩토링 기법에 대해 알게 되었으니 이제 실무에 적용하는 것이 시작이다. 시작은 성공의 반이기에 조금씩이라도 리팩토링의 습관을 가진다면 그것이 곧 성공에 가까워진다.

리팩토링을 어렵게 생각할 필요없다. 내가 보기 불편하다면 다른 사람도 보기 불편한 법이다. 그러니 작은 것부터 적용해보면 어떨까?

그렇다면 어떻게 학습하고, 적용해나가면 좋을까?

• 습관적으로 목표를 정하자.
  • 자신이 담당하는 코드의 어느 부분에선가 구린내가 풍기면, 그 구린내를 없애겠다는 결의를 다진 후 그 목표를 향해 나아가자.
• 확신이 없으면 중단하자.
  • 목표를 향해 전진할 때, 현재 실시하는 작업이 프로그램의 목적을 보전하리란 사실을 자신이나 남에게 확실히 입증할 수 없는 순간이 닥칠 수도 있다. 이때는 중단해야 한다.
• 되돌아가자.
  • 대부분의 개발자는 문제를 벗어나려고 디버깅만 시도할 수도 있다. 그렇지만 테스트를 반드시 작성해야 한다. 테스트 코드를 통해 확인해야 한다.
  • 만약 리팩토링 후 계속 에러를 만난다면 이전 버전으로 되돌리자. 그런 다음 다시 작은 단위부터 하나하나씩 수정해가면서 테스트를 진행하자.
• 작업은 둘이서 하자.
  • 반드시 다른 사람과 2인조로 리팩토링하자. (페어 프로그래밍)
  • 리팩토링은 조심스럽게 체계적으로 작업해야 한다.
  • 리팩토링할 땐 코드가 리팩토링 하기 전의 기능을 그대로 유지하게 하는 것이 목표다. 기능이 늘거나 줄면 안된다.

References

• 리팩토링 1판