* bad smell :
코드를 보면 문제로 금방 보고 느껴지는 것
코드 이름은 1시간을 이야기해도 부족할 게 없음. 많은 개발자들이 생각나는대로 이름을 짓는다. 협업 시 코드 이름을 맞추는 거로 싸움이 되는 원인이 되기도 함.
* smel of rush(너무 서두름으로 생기는 smell) : Long Function/Method, Large Class, Long parameter List, data clumps, Primitive Obsessionn
* smell of OOP abusers : Switch Statements (Repeated Switches), Temporary Field, Alternative Classes with Different Interface, Refused Bequest
* smell of coupling : Divergent Change, Shotgun Surgency, Parallel Inheritance Hierarchies
* smell of confusion : Duplicated Code, Lazy Element/Class, Speculative Generality, Data Class, Comments
* smell of lack of cohesion : Feature Envy, Middle Man
1. mysterious name
- 변수, field, 함수, class 이름의 의도를 알 수 있게
- 사용할 동사, 명사를 사전(naming convention)으로 만드는 방법이 좋음.
- 중복되는 것은 좋지않다.
예) student.addCourse(Course) - Course가 중복됨. method의 이름에 type을 넣는 것은 좋지 않다.
2. Duplicated code
두개의 subclass나 class, if/else, switch/case 문 등에서 중복 코드가 자주 발견됨.
3. Long function/method
- 너무 길면 파악이 힘들다.
- One page rule(10줄, 20줄(화면), 60줄(종이) 등 기준은 주기나름)
4. Large class
- 객체의 이름에 system이 들어가는 경우. 모든 기능이 그 클래스로 다 들어가버린다.
5. Long parameter List
- 3,4개 이상의 parameter 개수
6. Global data
- functional language에서 주로 발생
- 어디서 access하는지를 알 수 없음.
- 오류 디버깅도 매우 어렵게 됨.
7. Divergent change
- 여러 가지 이유로 하나의 코드를 고쳐야 한다. SRP 위배. coupling이 많음.
8. shotgun surgery
- 하나의 이유로 여러 객체를 고쳐야 한다. cohesion 문제.
9. Feature envy
- 남의 모듈의 data, method를 자꾸 쓰는 것.
- Move method로 해결 가능.
10. Data clumps
- 동일한 데이터 그룹이 반복적으로 사용됨.
- 객체로 전달될 내용이 dataset으로 전달된 것임.
- long parameter list 문제와 같이 발생할 가능성 높음
- 새로운 class로 뽑아져야할 수 있음.
11. primitive obsession
- primitive 자료형을 너무 많이 사용 하는 것
12. Repeated switches ( Switch statements)
- switch문의 반복. 혹은 중첩 if문
- polymorphism 이용 권장. state 이용이나, strategy
13. Lazy element/class
- 유지보수하다가 필요 없어지는 코드들.
14. Speculative generality
- 이 코드가 왜 있는지 파악하는 것만큼 어려운게 없음.
- 사용하지 않는 코드는 지워라.
- "After all, tomorrow is another day "
15. Temporary field
- 임시 변수의 사용.
- 용도가 지정되지 않은 사용은 좋지 않다.
- method나 클래스로 만드는 것이 필요
16. message chains
- Hide delegation 기법으로 해결가능. middle man 을 발생시킬 수있으므로 조심해서 써야 함.
- 지식과 경험이 필요. 이문제 해결을 위한 자동화가 거의 없음.
17. middle man
- 하는 일은 없느데 요청만 하는 class.
- middle man을 제거함으로써 message chain이 사라질 수 있음
18. Insider trading(inappropraite intimacy)
- 두 객체가 너무 강하게 엮여 있는 것. 다른 클래스의 method와 field 사용
- 경험상 두 객체를 합쳐놓고 bad smell을 없애는 방법도 있음. (합친 것이 적당한 크기일 경우)
19. alternative classes with different interface
- interface 이름은 다른데 같은 method를 하는 두개의 클라스
- 하나를 다른 것에 통합하는 방법으로 해결
20. Data class
- operation이 없는 class
- 설계가 잘못되어있는 경우일 수 있음.
21. refused bequest
- 상속 관계를 잘못 만들었을 때
- 부모는 자식의 공통되는 부분을 가지는 것임. 너무 많은 것을 부모가 가져간 경우. 혹은 자식이 반대로 가져간 경우.
22. comments
- comment 출력만 하는 method
- code 수정하고나서 해당 method를 수정 안하는 경우 문제. 오히려 이해하기 힘들어짐.
- code의 나쁜 점을 보완하기 위한 방법을 comment를 쓰는 경우. 그 코드자체가 문제다.
- 너무많은 comment는 문제가 될 수 있다.