[refactoring] 2. 코드에서 나는 악취

1. 기이한 이름

이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 신경 써야 한다.

 

2. 중복 코드

똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하도록 한다.

 

3. 긴 함수

함수가 길어질수록 이해하기 어려워진다. 함수 이름을 잘 지어두기만 해도 본문 코드를 볼 이유가 사라진다.

그러니 적극적으로 함수를 쪼개도록 하자.

 

4. 긴 매개변수 목록

함수의 매개변수 목록이 길어지면 그 자체로 이해하기 어려워진다. 되도록 짧게 하는 게 좋고, 클래스가 그걸 도와줄 수 있다.

 

5. 전역 데이터

전역 데이터가 가변적이라면 다루기가 까다로워진다. 바뀌지 않는다고 보장하는 편이 낫다.

 

6. 가변 데이터

변수의 유효 범위가 짧으면 괜찮은데, 넓어진다면 그에 따른 위험도 커지게 된다. 코드들의 유효 범위를 제한하는 것도 좋다.

 

7. 뒤엉킨 변경

어떤 기능이나 변수가 추가될때마다 수많은 것들이 같이 변경되어야 한다면 그것 또한 좋지 않다.

 

8. 산탄총 수술

뒤엉킨 변경과 비슷하지만, 코드를 변경할 때마다 자잘하게 수정해야 하는 클래스가 많을 때 생긴다.

변경할 부분이 전반적으로 퍼져 있다면 찾기도 어렵고, 중요한 부분을 놓칠 수가 있다.

 

9. 기능 편애

프로그램을 모듈화 할 때 코드를 여러 영역으로 나눈 뒤 영역 안에서 이뤄지는 상호작용은 최대한 늘리고 영역 사이에서 이뤄지는 상호작용은 최소로 줄이는데 주력한다.

 

10. 데이터 뭉치

데이터 항목 3~4개가 같이 함께 뭉쳐 다닌다면, 클래스로 추출하는 게 낫다.

 

11. 기본형 집착

기본형을 자주 사용하게 된다면, 마찬가지로 뭉쳐서 객체로 바꿔도 좋다.

 

12. 반복되는 switch문

같은 switch문을 자주 사용한다면 함수 등으로 빼내는 게 낫다.

 

13. 반복문

반복문은 처음엔 인식이 좋지 않았으나, 불가피하다.

 

14. 성의 없는 요소

 

15. 추측성 일반화

'나중에 필요할 거야'라는 생각으로 짓지 않는 게 낫다.

 

16. 임시 필드

 

임시적인 필드들을 클래스로 몰아주거나, 유효하지 않을 때의 대안 클래스를 만들어 제거한다.

17. 메시지 체인

 

18. 중개자

 

19. 내부자 거래

 

20. 거대한 클래스.

한 클래스 필드가 너무 많아지면 중복 코드가 생기기 쉽다. 이럴 땐 클래스를 추출해서 일부 필드를 따로 묶는다.

클래스가 항시 모든 필드를 사용하지는 않을 수도 있기 때문이다. 중복 자체를 최대한 줄이면서 특정 기능 그룹만 살펴 추출하자.

 

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

클래스의 장점은 필요에 따라 언제든 다른 클래스들로 교체하는 것인데, 교체하려면 인터페이스가 같아야 한다. 

대안 클래스들 사이의 중복 코드가 생기면 슈퍼클래스를 추출하자.

22. 데이터 클래스

데이터 필드와 getter/setter 메서드로만 구성된 클래스를 말한다. 불변 데이터가 있다면 게터 필요 없이 public해도 된다.

 

23. 상속 포기

상속관계에서도 몇 개만 내려받는다면 굳이 상속해야 하지 않을 수도 있다

24. 주석

코드를 잘만 작성해도 주석은 필요 없을 수도 있다.