[리팩터링] 3. 코드에서 나는 악취

코드에서 나는 악취에 대해 어떤 경우에 악취가 나는지 간단히 알아보자.

나중에 기법들을 배우며 다시 돌아볼 것.

1. 기이한 이름

2. 중복 코드

3. 긴 함수

4. 긴 매개변수 목록

5. 전역 데이터

전역 데이터 사용 주의하자

6. 가변 데이터

(const가 아닌 것. 주의하자.)

7. 뒤엉킨 변경

단일 책임 원칙이 제대로 지켜지지 않을 때, 즉 하나의 모듈이 서로 다른 이유들로 인해 여러가지 방식으로 변경되는 일이 많을 때.
예를 들어 지원해야 할 DB가 추가될 때마다 함수 세 개를 바꿔야 하고, 금융 상품이 추가될 때마다 또 다른 함수 네개를 바꿔야 하는 모듈이 있다면 뒤엉킨 변경이 발생한 것.

8. 산탄총 수술

코드를 변경할 떄마다 자잘하게 수정해야 하는 클래스가 많을 때 풍김.

9. 기능 편애

어떤 함수가 자기가 속한 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호작용 할 일이 더 많을 때 풍기는 냄새이다.

10. 데이터 뭉치

 데이터 항목 여러개가 항상 함께 뭉쳐다니는 모습을 흔히 볼 수 있다. 이렇게 몰려다니는 데이터는 뭉쳐야 한다.(저자는 간단한 레코드 구조가 아닌 '클래스'로 데이터 뭉치를 만드는 것을 권한다.)

11. 기본형 집착

자신에게 주어진 문제에 딱 맞는 기초 타입(화폐, 좌표, 구간 등)을 직접 정의하기를 몹시 꺼리는 사람이 많다. (전화번호를 단순히 문자 집합으로만 표현). 기본형을 객체로 바꾸기. 오브젝트화하면 좋을 것을 굳이 기본형으로 쓰지 말라.

12. 반복되는 switch문

옛날엔 선호되었지만, 그 후에는 또 꺼려졌고, 지금은 적당히 쓰자.

13. 반복문

파이프라인으로 수정

14. 성의 없는 요소

코드 한 두줄과 다를바 없는 함수
메서드가 하나뿐인 클래스

15. 추측성 일반화

아직 필요없는 것을 추측해서 하면, 오히려 유연성을 떨어뜨림.

16. 임시 필드

특정 상황에서만 값이 설정되는 필드

17. 메세지 체인

꼬리에 꼬리를 무는 게터

18. 중개자

클래스가 제공하는 메서드 중 절반이 다른 클래스에 구현을 위임하고 있다면.. 실제로 일을 하는 객체와 직접 소통하게 하자.

19. 내부자 거래

클래스의 위임과 결합도가 너무 높으면 문제.

20. 거대한 클래스

21. 서로 다른 인터페이스의 대안 클래스들

인터페이스: 상속 활용하느 것. 두 비슷한 클래스가 서로 다른 인터페이스를 구현해서 만들었으면 서로 상호호환이 안됨. 

22. 데이터 클래스

데이터 클래스: 데이터 필드와 게터/세터 메소드로만 구성된 클래스. 데이터 저장 용도. 다른 클래스가 너무 깊이까지 함부로 다룰때가 많다. 

23. 상속 포기

부모의 pubilc 요소를 사용할 게 아니라면 상속하지 않는 것이 낫다.
ex) JAVA의 Stack
자바의 스택은 리스트를 상속하고 있다고 한다. stack의 push/pull을 따로 구현해야하는 것인데, 이런 식이면 상속받아서 queue도 만들 수 있고 다 만들 수 있다. 잘못 만들어졌다. 차라리 리스트를 위임받아 구현하는 것이 낫다. 

24. 주석

주석은 향기를 뿜는다. 그러나 향수를 탈취제로 쓰면 안된다.