In Third chapter, It says there are bad smells in code.
Yes, it means what are bad or worse ways and screw my code up.
I would try to show those ways.
-
Mysterious name(기이한 이름)
Name should clearly communicate what they(function, module, variable, class...) do and how to use them
함수, 모듈, 변수, 클래스 등 이것들이 무엇을 하는지 그리고 어떻게 사용되는지 명확히 알 수 있도록 이름을 지어야 한다. -
Duplicated code(중복 코드)
Same code structure in more than one place
똑같은 코드 구조가 여러 곳에 반복 되는것을 통합하기. -
Long function(긴 함수)
the longer a function is, the more difficult it is to understand
긴 함수는 이해하기가 더 어렵다. -
Long parameter list(긴 매개변수 목록)
Difficult to understand and easily introduce bug
긴 매개변수는 이해하기 어렵고 버그가 생길 확률이 높다. -
Global data(전역 데이터)
Global variable is difficult to track and debug
전역데이터는 코드 베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다. -
Mutable data(가변 데이터)
Changes to data can often lead to unexpected consequences and tricky bugs
데이터를 변경했더니 예상치 못한 결과나 골치아픈 버그가 생기는 경우가 생길 수 있다. -
Divergent change(뒤엉킨 변경)
One module is changed in different ways for different reasons
하나의 모듈이 서로 다른 이유들로 인해 여러가지 방식으로 변경되는 일이 많을때 발생한다. -
Shotgun surgery(산탄총 수술)
When every time you make a change, you have to make a lot of little edits to a lot of different classes
변경할 부분이 코드 전반에 퍼져 있다면 찾기도 어렵고 꼭 수정해야 할 곳을 지나치기 쉽다. -
Feature envy(기능 편애)
When a function in one module spends more time communicating with functions or data inside another module than it does within its own module
어떤 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호작용을 할일이 더 많을때 생기는 문제. -
Data clumps(데이터 뭉치)
Same three or four data items together in lots of places
데이터 항목 서너개가 여러 곳에서 함께 뭉쳐있는 경우.(클래스 추출, 매개변수 객체 만들기, 객체 통째로 넘기기 적용) -
Primittive Obsession(기본형 집착, 강박)
Use primitive types instead of custom fundamental types
특정 기본형을 사용하는데 너무 집착함.(String만 사용...) -
Repeated switches(반복되는 switch문)
Same conditional switching logic pops up in different places
똑같은 조건부 로직(혹은 길게 나열된)이 여러 곳에서 반복해 등장하는 코드. -
Loops(반복문)
Using loops instead of first-class functions such as filter or map
filter나 map같은 1급함수를 사용하는 대신 반복문을 사용. -
Lazy element(성의 없는 요소)
A class, struct or function that isn't doing enough to pay for itself should be eliminated.
함수, 클래스, 인터페이스 등 코드 구조를 잡는 데 활용되는 요소들이 필요 없는 경우. -
Speculative generality(추측성 일반화)
All sorts of hooks and special cases to handle things that aren’t required
나중에 필요할 것이라 생각하여 추가한 모든 종류의 후킹포인트, 특이케이스 처리 로직을 작성한 코드. -
Temporary field(임시 필드)
An instance variable that is set only in certain circumstances.
특정 상황에서만 값이 설정되는 필드를 가진 클래스들을 제거 -
Message chains(메시지 체인)
When a client asks one object for another object, which the client then asks for yet another object...
클라이언트가 한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 또 다른 객체를 요청하는 방식.(EX: aPerson.department.manager.name) -
Middle man(중개자)
When an object delegates much of its functionality.
외부로부터 세부사항을 숨겨주는 캡슐화 과정에서 위임할 시 너무 많은 메소드를 위임한 경우. -
Insider trading(내부자 거래)
Modules that whisper to each other by the coffee machine need to be separated by using Move Function and Move Field to reduce the need to chat.
모듈사이의 데이터 거래가 많으면 결합도가 높아지는 문제가 생김. 양을 최소로 줄이고 투명하게 처리해야 함. -
Large class(거대한 클래스)
A class is trying to do too much, it often shows up as too many fields
한 클래스가 너무 많은 일을 하려다 보면 필드 수가 상당히 늘어나고, 중복 코드가 생기기 쉬움. -
Alternative Classes with Different Interfaces(서로 다른 인터페이스의 대안 클래스들)
Classes with methods that look to similar.
대안 클래스들 사이에 중복코드가 생기는 경우. -
Data class(데이터 클래스)
Classes that have fields, getting and setting methods for the fields, and nothing else
데이터 필드와 게터,세터 메소드로만 구성된 클래스. 데이터 저장용도로만 쓰이다 보니 다른 클래스가 너무 깊이까지 함부로 다루게 됨. -
Refused Bequest(상속 포기)
Subclasses doesn't make uses of parents method
자식클래스에서 부모클래스의 메소드와 데이터를 원치 않는 경우 -
Comment(주석)
The comments are there because the code is bad
주석이 장황하게 달린 경우. 코드가 좋지 않아서 이를 설명하기 위해 많은 주석이 필요하게 됨.
