대규모 프로젝트의 리팩토링을 하는 방법에 대한 마틴 파울러의 이야기.

1. Refactoring
#12 Big Refactoring

2. INDEX
 개론
 Tease Apart Inheritance
 Convert Procedural Design to Objects
 Separate Domain from Presentation
 Extract Hierarchy

3. 개론
 대규모 리팩토링, 접근 방식을 달리하자
 무조건 한 번에 끝내야 한다는 생각은 버리자
 기능 개선과 같이 병행하는 것도 좋은 접근이다.
 Step by Step
 Your Changes of Today, Makes World Better!
 절대로 소홀히 해서는 안되는 대규모 프로젝트의 리팩토링
 작은 실수들이 쌓이면 결국 손쓸 수 없는 상황을 직면할 수도 있
다!

4. Tease Apart Inheritance
 여러 가지 변화(기능)를 혼란스러운 방법으로 결합한 것 같
이 엉켜있는 상속 구조를 다루는 방식.
 하나의 가지에서 계속된 상속을 통해 기능들을 처리해 나가는 경
우
 코드 가독성이 떨어져 유지보수에 어려움을 겪을 수 있다.
 상속을 잘라 떼어내고, 별도의 가지를 만들어 원래 가지에서 위
임(호출)을 통해 해결하는 방법.

5. Convert Procedural Design to Objects
 절차적인 코드가 많은 프로젝트에서 객체지향 스타일로 변
경하는 방법
 절차적인 코드 단락에서 데이터를 분류
 분류한 데이터를 각각의 성격에 맞는 객체로 승화
 처리 코드들을 승화시킨 객체에 성격에 맞게 녹여 넣기.

6. Separate Domain From Presentation
 고전적인 2 Tier(UI & DB) 접근 방식으로 되어 있는 프로젝
트에서 비즈니스 로직을 분리해 내는 방식
 만약 도메인 로직을 포함하고 있는 GUI 클래스를 만났다
면?
 도메인 로직을 최대한 분리하여 도메인 클래스를 만들어 UI와 분
리시킨다.
 도메인 로직 – UI – DB 구조로 변경됨 : 2 Tier  MVC

7. Extract Hierarchy
 지나치게 복잡한 클래스를 서브클래스의 그룹으로 바꾸어
단순화 시키는 방법
 하나의 클래스가 너무 많은 작업을 하는 경우
 부분적으로 라도 지나치게 많은 조건문 등으로 인해 로직이 긴
클래스
  로직을 세부적으로 분리하여 각각의 분류별로 Base 객체를 만들고
상속 구조를 만들어 각각의 서브 클래스가 특정 작업을 담당하도록 클래
스의 상속 구조를 만드는 방법.