1. 함수 옮기기

• 좋은 소프트웨어 설계의 핵심은 모듈화가 얼마나 잘 되어 있느냐를 뜻하는 모듈성이다.
• 모듈성이란 프로그램의 어딘가를 수정하려 할 때 해당 기능과 깊이 관련된 작은 일부만 이해해도 가능하게 해주는 능력이다.
• 모듈성을 높이려면 서로 연관된 요소들을 함께 묶고, 요소 사이의 연결 관계를 쉽게 찾고 이해할 수 있도록 해야한다.
• 객체 지향 프로그래밍의 핵심은 모듈화 컨텍스트는 클래스다.
• 중첩 함수를 사용하다보면 숨겨진 데이터끼리 상호 의존하기가 아주 쉬우니 중첩 함수는 되도록 만들지 말자.

절차

1. 선택한 함수가 현재 컨텍스트에서 사용 중인 모든 프로그램 요소를 살펴본다. 이 요소들 중에도 함께 옮겨야 할 게 있는지 고민해 본다.
2. 선택한 함수가 다형 메서드인지 확인한다.
3. 선택한 함수를 타깃 컨텍스트로 복사한다. 타깃 함수가 새로운 터전에 잘 자리 잡도록 다듬는다.
4. 정적 분석을 수행한다.
5. 소스 컨텍스트에서 타깃 함수를 참조할 방법을 찾아 반영한다.
6. 소스 함수를 타깃 함수의 위임 함수가 되도록 수정한다.
7. 테스트한다.
8. 소스 함수를 인라인할지 고민해본다.

2. 필드 옮기기

• 프로그램의 상당 부분이 동작을 구현하는 코드로 이뤄지지만 프로그램의 진짜 힘은 데이터 구조에서 나온다.
• 주어진 문제에 적합한 데이터 구조를 활용하면 동작 코드는 자연스럽게 단순하고 직관적으로 짜여진다.
• 반면 데이터 구조를 잘못 선택하면 아귀가 맞지 않는 데이터를 다루기 위한 코드로 범벅이 된다. 이해가 어려운 코드가 만들어지는 데서 끝나지 않고, 데이터 구조 자체도 그 프로그램이 어떤 일을 하는지 파악하기 어렵게 한다.
• 함수에 항상 함게 건네지는 데이터 조각들은 상호 관계가 명확하게 드러나도록 한 레코드에 담는 게 가장 좋다.

절차

1. 소스 필드가 캡슐화되어 있지 않다면 캡슐화한다.
2. 테스트한다.
3. 타깃 객체에 필드를 생성한다.
4. 정적 검사를 수행한다.
5. 소스 객체에서 타깃 객체를 참조할 수 있는지 확인한다.
6. 접근자들이 타깃 필드를 사용하도록 수정한다.
7. 테스트한다.
8. 소스 필드를 제거한다.
9. 테스트한다.

3. 문장을 함수로 옮기기

• 중복 제거는 코드를 건강하게 관리하는 가장 효과적인 방법 중 하나다.

절차

1. 반복 코드가 함수 호출 부분과 멀리 떨어져 있다면 문장 슬라이드하기를 적용해 근처로 옮긴다.
2. 타깃 함수를 호출하는 곳이 한 곳뿐이면, 단순히 소스 위치에서 해당 코드를 잘라내어 피호출 함수로 복사하고 테스트한다. 이 경우라면 나머지 단계는 무시한다.
3. 호출자가 둘 이상이면 호출자 중 하나에서 '타깃 함수 호출 부분과 그 함수로 옮기려는 문장들을 함께' 다른 함수로 추출한다. 추출한 함수에 기억하기 쉬운 임시 이름을 지어준다.
4. 다른 호출자 모두가 방금 추출한 함수를 사용하도록 수정한다. 하나씩 수정할 때마다 테스트한다.
5. 모든 호출자가 새로운 함수를 사용하게 되면 원래 함수를 새로운 함수 안으로 인라인한 후 원래함수를 제거한다.
6. 새로운 함수의 이름을 원래 함수의 이름으로 바꿔준다.

4. 문장을 호출한 곳으로 옮기기

• 코드베이스의 기능 범위가 달라지면 추상화의 경계도 움직이게 된다.
• 함수 관점에서 생각해보면, 초기에는 응집도 노폭 한 가지 일만 수행하던 함수가 어느새 둘 이상의 다른 일을 수행하게 바뀔 수 있다는 뜻이다.

절차

1. 호출자가 한두개 뿐이고 피호출 함수도 간단하고 단순한 상황이면, 피호출 함수의 처음줄을 잘라내어 호출자들로 복사해 넣는다. 테스트만 통과하면 이번 리팩터링은 여기서 끝이다.
2. 더 복잡한 상황에서는, 이동하지 않길 원하는 모든 문장을 함수로 추출한 다음 검색하기 쉬운 임시 이름을 지어준다.
3. 원래 함수를 인라인한다.
4. 추출된 함수의 이름을 원래 함수의 이름으로 변경한다.

5. 인라인 코드를 함수 호출로 바꾸기

• 함수의 이름이 코드의 동작 방식보다는 목적을 말해주기 대문에 함수를 활용하면 코드를 이해하기 쉬워진다.

절차

1. 인라인 코드를 함수 호출로 대체한다.
2. 테스트한다.

6. 문장 슬라이드하기

• 관련된 코드들이 가까이 모여 있다면 이해하기가 더 쉽다. 예컨대 하나의 데이터 구조를 이용하는 문장들은 한데 모여 있어야 좋다.
• 관련 코드끼리 모으는 작업은 다른 리팩터링의 준비 단계로 자주 행해진다.
• 관련 있는 코드들을 명확히 구분되는 함수로 추출하는 게 그저 문장들은 한데로 모으는 것보다 나은 분리법이다.
• 부수효과가 없는 코드끼리는 마음 가는 대로 재배치할 수 있다. 현명한 프로그래머들이 되도록 부수효과가 없는 코드들로 프로그래밍하는 이유 중 하나다.
• 코드 조각을 슬라이드할 때는 두 가지를 확인해야 한다. 무엇을 슬라이드할지와 슬라이드할 수 있는지 여부다. 무엇을 슬라이드할지 맥락과 관련 깊다.

절차

1. 코드 조각을 이동할 목표 위치를 찾는다. 코드 조각의 원래 위치와 목표 위치 사이의 코드를 훑어보면서, 조각을 모으고 나면 동작이 달라지는 코드가 있는지 살핀다. 다음과 같은 간섭이 있다면 이 리팩터링을 포기한다.

• 코드 조각에서 참조하는 요소를 선언하는 문장 아픙로는 이동할 수 없다.
• 코드 조각을 참조하는 요소의 뒤로는 이동할 수 없다.
• 코드 조각에서 참조하는 요소를 수정하는 문장을 건너뛰어 이동할 수 없다.
• 코드 조각이 수정하느 ㄴ요소를 참조하는 요소를 건너뛰어 이동할 수 없다.

2. 코드 조각을 원래 위치에서 잘라내어 목표 위치에 붙혀 넣는다.
3. 테스트한다.

7. 반복문 쪼개기

• 반복문 하나에 두가지일을 수행할 때, 반복문을 수정해야 한다면 두 가지 일 모두 잘 이해하고 진행해야 한다.
• 반대로 각각의 반복문으로 분리해두면 수정할 동작 하나만 이해하면 된다.
• 반복문을 분리하면 사용하기도 쉬워진다. 한 가지 값만 계산하는 반복문이라면 그 값만 곧바로 반환할 수 있다.

절차

1. 반복문을 복제해 두 개로 만든다.
2. 반복문이 중복되어 생기는 부수효과를 파악해서 제거한다.
3. 테스트한다.
4. 완료됐으면, 각 반복문을 함수로 추출할지 고민해본다.

8. 반복문을 파이프라인으로 바꾸기

• 논리를 파이프라인으로 표현하면 이해하기 훨씬 쉬워진다. 객체가 파이프라인을 따라 흐르며 어떻게 처리되는지를 읽을 수 있기 때문이다.

절차

1. 반복문에서 사용하는 컬렉션을 가리키는 변수를 하나 만든다.
2. 반복문의 첫 줄부터 시작해서, 각각의 단위 행위를 적절한 컬렉션 파이프라인 연산으로 대체한다. 이때 컬렉션 파이프라인 연산은 1.에서 만든 반복문 컬렉션 변수에서 시작하여, 이전 연산의 결과를 기초로 연쇄적으로 수행된다. 하나를 대체할 때마다 테스트한다.
3. 반복문의 모든 동작을 대체했다면 반복문 자체를 지운다.

9. 죽은 코드 제거하기

절차

1. 죽은 코드를 외부에서 참조할 수 있는 경우라면 혹시라도 호출하는 곳이 있는지 확인한다.
2. 없다면 죽은 코드를 제거한다.
3. 테스트한다.

출처
리팩터링 2판