Refactoring

Refactoring

-마틴 파울러-

1일차

추후 수정할 부분?

1.      Refactoring 할 코드 부분에 대한 신뢰도 높은 각종 테스트 작성.

- 이 테스트 들은 반드시 자체 검사 되게 작성

2.      임시변수 최대한 없애기

3.      상속구조 만들기

Refactoring 개론

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

- Refactoring 기법을 연달아 적용해서 겉으로 드러나는 기능은 그대로 둔 채 소프트웨어 구조를 변경한다

해야하는 이유?

- 소프트웨어 설계 개선

- 좀 더 쉽게 소프트웨어 이해하기 위해

- 버그를 좀 더 쉽게 찾기 위해

- 생산성 향상

Refactoring이 필요할 때?

- 같은 작업의 삼진 아웃(3번 반복) 때

- 기능 추가

- 버그 수정

- 코드 검수

Refactoring 관련 문제

- 데이터베이스

- 인터페이스 변경

- 설계를 수정하는 일

- 처음 코딩 작성시

- 납기 임박 시점

코드의 구린내

- 중복 코드 ( Duplicated Code )

- 장환한 메서드 ( Long Method )

- 방대한 클래스 ( Large Class )

- 과다한 매개변수 ( Long Paremeter List )

- 수정의 산발 ( Divergent Change )

- 기능의 산재 ( Shotgun Surgery )

- 잘못된 소속 ( Feature Envy )

- 데이터 뭉치 ( Data Clumps )

- 강박적 기본 타입 사용 ( Primitive Obsession )

- switch 문

- 평행 상속 계층 ( Parallel Inheritance Hierarchies )

- 직무 유기 클래스 ( Laze Class )

- 막연한 범용 코드 ( Speculative Generality )

- 임시 필드 ( Temporary Feild )

- 메시지 체인 ( Message Chains )

- 과잉 중개 메서드 ( Middle Man )

- 지나친 관여 ( Inappropriate Intimacy )

- 인터페이스가 다른 대용 클래스 ( Alternative Classes with Different Interfaces )

- 미흡한 라이브러리 클래스 ( Incomplete Library Class )

- 데이터 클래스 ( Data Class )

- 방치된 상속물 (Refused Bequest )

- 불필요한 주석 ( Comments )

테스트 작성

- Refactoring 실시 하기 위한 필요 전제 조건

- 자가 테스트 코드의 가치

- JUnit 테스트 프레임워크

- 테스트 추가