Refactoring

리팩터링 2판을 도서관에서 빌려와서 읽어보았다. 저자는 마틴 파울러. 프로그래밍 기초가 부족한 나에게 매우 유익한듯하다. 

 

리팩터링

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 

 

리팩터링은 대부분 코드가 하는 일을 파악하는데서 시작한다. 그래서 코드를 읽고, 개선점을 찾고, 리팩터링 작업을 통해 개선점을 코드에 반영하는 식으로 진행한다. 그 결과 코드가 명확해지고 이해하기 쉬워진다. 그러면 또 다른 개선점이 떠오르며 선순환이 형성된다. 

 

리팩터링을 효과적으로 하는 핵심은, 단계를 잘게 나눠야 더 빠르게 처리할 수 있고, 코드는 절대 깨지지 않으며, 이러한 작은 단계들이 모여서 상당히 큰 변화를 이룰 수 있다는 사실을 깨닫는 것이다. 

 

리팩터링으로 인하여 성능이 떨어질 수 도 있지만, 특별한 경우가 아니라면 일단 무시해라. 성능이 떨어진다면, 리팩터링을 마무리하고 나서 성능을 개선하면된다. 그리고 릭팩터링 덕분에 성능 개선을 더 효과적으로 수행할 수 도 있다. 

 

 

컴파일 → 테스트 → 커밋

 

어떤 부분을 리팩터링해야 하나? 임시 변수?

- 기이한 이름 (Mysterious Name)

- 중복 코드 (Duplicated Code)

- 긴 함수 (Long Function)

- 긴 매개변수 목록 (Long Parameter list)

- 전역 데이터 (Global Data)

- 가변 데이터 (Mutable Data)

- 뒤엉킨 변경 (Divergent Change)

- 산탄총 수술 (Shotgun Surgery)

- 기능 편애 (Feature Envy)

- 데이터 뭉치 (Data Clumps)

- 기본형 집착 (Primitive Obession)

- 반복되는 Switch문 (Repeated Switches)

- 반복문 (Loops)

- 성의 없는 요소 (Lazy Element)

- 추측성 일반화 (Speculative Generality)

- 임시 필드 (Temporary Field)

- 메시지 체인 (Message Chains)

- 중개자 (Middle Man)

- 내부자 거래 (Insider Trading)

- 거대한 클래스 (Large Class)

- 서로 다른 인터페이스의 대안 클래스들 (Alternative Classes with Different Interfaces)

- 데이터 클래스 (Data Class)

- 상속 포기(Refused Bequest)

- 주석 (Comments)

 

논리적 요소 파악이 쉽도록 코드 구조 보강

- 복잡하게 얽힌 덩어리 잘게 쪼개기

 

기본적인 리팩터링

수학으로치면 +. -, ×, ÷와 같은 것들이다. 이를 이해하고 나면 이것을 필요한 상황에서 활용할 수 있다. 조건부 로직을 간소화 하던가, API를 리팩터링 하던가, 데이터를 조직화 하기 처럼. 

1. 함수 추출하기  

2. 함수 인라인하기 

3. 변수 추출하기

4. 변수 인라인하기

5. 함수 선언 바꾸기

6. 변수 캡슐화하기

7. 변수 이름 바꾸기

8. 매개변수 객체 만들기

9. 여러함수 클래스로 묶기

10. 여러함수를 변환함수로 묶기

11. 단계 쪼개기