1. 정의

: 외부에서 본 프로그램의 동작은 변하지 않고 프로그램 내부의 구조를 개선하는 것입니다. 
리팩토링을 할때는 전후에 테스트를 실시합니다. 
- 리팩토링하기 전에 테스트를 합니다. 
- 리팩토링을 합니다. 
- 리팩토링한 후 다시 한번 테스트를 합니다.

2. 목적

• 버그를 찾아내기 쉽게 한다.
• 기능을 추가하기 쉽게 한다.
• 리뷰하는 것이 쉬워진다.

3. 리팩토링의 한계

• 프로그램이 아직 동작하지 않는 경우
• 시간이 얼마 남지 않았을 경우(마감일에 가까워 졌을 때)

4. 코드의 악취

: 리팩토링이 필요한 부분

• 코드가 여기저기 겹쳐 있다.
• 메소드가 너무 길다.
• 클래스의 파일이나 메소드가 너무 많다.
• 메소드에 전달하는 인수의 수가 너무 많다.
• 사양변경이 발생한 경우 수정할 곳이 여기저기 흩어져 있다.
• 어떤 클래스를 수정하면 다른 클래스도 수정하지 않으면 안 된다.
• 언제나 다른 클래스의 속성을 건드리고 있다.
• 정리해서 다룰 수 밖에 없는 여러 개의 데이터가 하나의 클래스에 정리되어 있지 않다.
• 클래스를 만드맂 않고 int같은 기본 데이터형만을 사용한다.
• switch 문이나 if문을 사용하여 동작을 분할하고 있다.
• 서브클래스를 만들면 클래스 계층에 따로 서브클래스를 만들어야 한다.
• 클래스가 별로 하는 일이 없다.
• 일시적으로 사용할 필드가 있다.
• 메소드가 호출하는 연쇄가 너무 많다.
• 위양(권리를 위임하고)자신이 하는 일은 없는 클래스가 있다.
• {부적절한 관계} 필요 없는 쌍방향 링크가 걸려 있거나 is-a 관계가 아니면서 상속을 사용한다.
• {클래스의 인터페이스 불일치} API 가 부적절하다.
• 기존의 클래스라이브러리가 사용하기 힘들다.
• {데이터클래스} 필드와 getter메소드와 setter 메소드만 가지고 있는 클래스가 있다.
• {상속거부} 상속하고 있는 메소드면서 그것을 호출하면 문제가 발생한다.

• {코멘트} 코드의 부족을 보충하기 위해 상세한 코멘트가 있다.

• [요약]

  • 겹쳐있다.
  • 너무길다
  • 너무 많다
  • 이름이 어울리지 않는다
  • 너무 공개했다
  • 객체지향적이지 않다.

  리펙토링은 Step by step!!!