[리팩토링 2판] action point(ch3)

Ch3. 코드에서 나는 악취

리팩터링이 필요한, 때로는 아주 절실한 코드들에 일정한 패턴이 있다
1. 기이한 이름(Mysterious Name)
- 마땅한 이름이 떠오르지 않으면 설계에 더 근본적인 문제가 숨어있을 수 있다

2. 중복 코드(Duplicated Code)

3. 긴 함수(Long Function)
- 간접 호출의 효과, 코드를 이해하고, 공유하고, 선택하기 쉬워진다는 장점은 함수를 짧게 구성할 때 나온다
- 주석을 달아야 할 만한 부분은 무조건 함수로 만든다. 함수 이름은 동작 방식이 아닌 의도가 드러나게 짓는다
- 조건문이나 반복문도 추출 대상의 실마리를 제공한다

4. 긴 매개변수 목록(Long Parameter List)

5. 전역 데이터(Global Data)
- 전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다.
- 저자는 전역 데이터가 아주 조금만 있더라고 함수로 감싸 캡슐화하는 편이다.

6. 가변 데이터(Mutable Data)

7. 뒤엉킨 변경(Divergent Change)

- 뒤엉킨 변경은 단일 책임 원칙(SRP)이 제대로 지켜지지 않을 때 나타난다.

8. 산탄총 수술(Shotgun Surgery)
- 코드를 변경할 때마다 자잘하게 수정해야 하는 클래스가 많을 때 일어난다.
- 변경할 부분이 코드 전반에 퍼져 있다면 찾기도 어렵고 꼭 수정해야 할 곳을 지나치기 쉽다

9. 기능 편애(Feature Envy)
- 기능 편애는 흔히 어떤 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호작용 할 일이 더 많을 때 일어난다.

10. 데이터 뭉치(Data Clumps)
- 데이터 항목 서너 개가 여러 곳에서 항상 함께 뭉쳐 다닐때
- 데이터 뭉치인지 판별하기 위해 값 하나를 삭제해보라 -> 그랬을 때 나머지 데이터만으로는 의미가 없다면 객체로 환생하길 갈망하는 데이터 뭉치이다.

11. 기본형 집착(Primitive Obsession)
- 문자열을 다루는 코드에서 특히 흔하다.
-> (기본형을 객체로 바꾸기 7.3절 잘 읽어보자)

12. 반복되는 switch문(Repeated Switches)
- 반복되는 switch문이 문제가 되는 이유는 조건절 하나 추가할 때마다 다른 switch문들도 모두 찾아서 함께 수정해야 하기 때문

13. 반복문(Loops)
- 반복문보다 파이프라인으로 사용할 수 있다

14. 성의 없는 요소(Lazy Element)
- 프로그램 요소를 이용하는 것

15. 추측성 일반화(Speculative Generality)

- '나중에 필요할 거야'라는 생각으로 당장은 필요 없는 모든 종류의 후킹 포인트와 특이 케이스 처리 로직을 작성해둔 코드에서 추측성 일반화가 나타난다. -> 이해하거나 관리하기 어려워진 코드가 된다.

 

16. 임시 필드(Temporary Field)

- 특정 상황에서만 값이 설정되는 필드를 가진 클래스

 

17. 메시지 체인(Message Chains)

- 클라이언트가 한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 또 다른 객체를 요청하는 식으로, 다른 객체를 요청하는 작업이 연쇄적으로 이어지는 코드

- getSomething() 같은 게터가 꼬리에 꼬리를 물고 이어지거나 임시 변수들이 줄줄이 나열되는 코드

 

18. 중개자(Middle Man)

- 클래스가 제공하는 메서드 중 절반이 다른 클래스에 구현을 위임하고 있을 때

 

19. 내부자 거래(Insider Trading)

- 여러 모듈이 같은 관심사를 공유

- 상속 구조에서 부모 자식 사이에 결탁이 생길때

 

20. 거대한 클래스(Large Class)

- 한 클래스가 너무 많을 일을 하려다 보니 필드 수가 많아져 중복 코드가 생기게 되는 경우

- 코드량ㅇ이 너무 많은 클래스 역시 중복 코드와 혼동을 일으킬 여지가 크다.

 

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

- 클래스는 언제든 다른 클래스로 교체할 수 있지만 교체하려면 인터페이스가 같아야 한다. 이때 리펙터링이 필요하다.

 

22. 데이터 클래스(Data Class)

- 데이터 필드와 게터/세터 메서드로만 구성된 데이터 클래스에 public 필드가 있을 때 레코드 캡슐화하기로 숨겨야 한다.

- 다른 클래스에서 데이터 클래스의 게터나 세터를 사용하는 메서드를 찾아서 함수옮기기로 그 메서드를 데이터 클래스로 옮길 수 있는지 살펴봐야한다.

 

23. 상속 포기(Refused Bequest)

- 서브클래스가 부모의 동작은 필요로하지만 인터페이스는 따르고 싶지 않을 때

 

24. 주석(Comments)

- 주석을 달면 안되는 건 아니지만 주석이 장황하게 달린 원인이 코드를 잘못 했기 때문인 경우가 의외로 많다.

- 주석을 남겨야겠다는 생각이 들면, 가장 먼저 주석이 필요 없는 코드로 리팩터링 해봐야 한다.

 

- 뭘 할 지 모를 때, 확실하지 않은 부분, 코드를 지금처럼 작성한 이유를 설명하는 용도로 주석을 사용하는 것은 나중에 코드를 수정해야 하는 사람에게 좋다.