리팩토링 2장 - 리팩토링의 원리

리팩토링(Refactoring)

• 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것

리팩토링 하다(Refactor)

• 일련의 리팩토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어의 구조를 바꾸다.

언제 리팩토링을 해야 하는 가?

• 별도의 시간을 내서 하지말고 틈틈이 계속
• 리팩토링 자체를 목적으로 하는 것이 아니라 다른 어떤 것을 하기 위해 리팩토링을 해야 한다
• 삼진 규칙
• • 처음 할 때는 그냥 한다.
  • 두 번째로 비슷한 것을 하게 되면 중복되게 한다.
  • 세 번째로 비슷한 것을 하게 되면, 그 때 리팩토링 한다.
• 기능 추가 할 때
• • 수정해야 할 코드에 대한 이해를 돕기 위해
  • 기능 추가가 쉽지 않은 디자인인 경우
• 버그를 수정해야 할 때
• • 버그 리포트를 받았으면 그것은 리팩토링이 필요하다는 신호
  • 왜냐면 버그가 있었다는 것을 몰랐을 정도로 코드가 명확하지 않았다는 뜻이기 때문
• 코드 검토(code review)를 할 때

= Kent Beck =

• 읽기 어려운 프로그램은 수정하기 어렵다.
• 중복된 로직을 가지고 있는 프로그램은 수정하기 어렵다.
• 실행중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램은 수정하기 어렵다.(?????????) 
• 복잡한 조건문이 포함된 프로그램은 수정하기 어렵다.

리팩토링을 할 때의 문제

• DB
• • DB 스키마가 application과 밀접한 관계이기 때문
  • data migration을 해야 하므로 시간도 오래 걸리고 위험도 큰 작업
• 인터페이스 변경

리팩토링을 하지 말아야 할 때

• 코드를 처음부터 다시 작성해야 할 때
• 마감일에 가까울 때 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ