Refactoring - 리팩터링 원칙(1)

본 내용은 마틴 파울러의 Refactoring 2판을 토대로 작성되었습니다.

 

리팩터링 원칙

리팩터링 정의

• 리팩터링[명사] : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
  • 함수 추출하기, 조건부 로직을 다형성으로 바꾸기 등
• 리팩터링(하다)[동사] : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 구성하다.
• 재구성(Restructuring) : 코드 베이스를 정리하거나 구조를 바꾸는 모든 작업
  • 리팩터링은 재구성 중 특수한 형태
  • 리팩터링은 큰 작업을 잘게 나누어 오히려 작업을 더 빨리 처리
  • 리팩터링은 단계들이 체계적으로 구성
  • 리팩터링은 디버깅하는 데 시간을 뺏기지 않음
• 겉보기 동작(Observavle Behavior) : 리팩터링 전과 후의 동작이 똑같이 동작해야 하는 것
  • 완전히 똑같다는 말은 아님
  • 함수 추출하기를 거치면 콜스택이 달라짐
  • 함수 선언 바꾸기나 함수 옮기기 같은 리팩터링을 하면 모듈의 인터페이스가 바뀔 때가 많음
  • 리팩터링 과정에서 발견된 버그는 리팩터링 후에도 그대로 남아 있어야 함
  • 단, 아무도 발견하지 못한 버그는 수정해도 괜찮음
• 리팩터링은 성능 최적화와 비슷
  • 둘 다 코드를 변경하지만 프로그램의 전반적인 기능은 그대로 유지
  • 리팩터링은 코드를 이해하고 수정하기 쉽게 만드는 것
  • 성능 최적화는 오로지 속도 개선에만 신경을 씀
  • 서로 상반되는 결과를 만들 수도 있음

 

두 개의 모자

• 소프트웨어를 개발할 때 목적이 기능추가냐, 리팩터링이냐를 명확히 구분하여 작업
• 기능을 추가할 때는 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 하기
  • 진척도는 테스트를 추가해서 통과하는 지 확인하는 방식으로 측정
• 리팩터링을 할 때는 기능 추가는 절대 하지 않기로 하고 오히려 재구성에만 전념
  • 앞 과정에서 놓친 테스트를 발견하지 않는 한, 테스트도 새로 만들지 않기
  • 인터페이스에를 변경할 때만 기존 테스트를 수정
• 소프트웨어를 개발하는 동안 두 모자를 바꿔쓰듯이 작업할 것
  • ex) 새 기능을 추가하다가 보면, 코드 구조를 바꿔야 작업하기 훨씬 쉬울 경우에는 리팩터링 모자 쓰기
  • 각 모자에 따른 미묘한 작업 방식의 차이를 분명하게 인식