Merge pull request #1321 from JoYouMe/master

youMe/2024-02-02-Ch03_Bad_Smells_in_code.md

@@ -0,0 +1,145 @@
+# Chapter 03 코드에서 나는 악취
+
+> 냄새 나면 당장 갈아라. 켄트벡 활머니의 육아 원칙
+
+리팩터링은 '적용-방법'을 알고 있는 것과 '제때 적용할 줄 아는 것'은 다르다. 리팩터링을 시작하고 멈출 때를 판단하는 것은 리팩터링의 작동원리를 이해하는 것과 중요하다. 리팩터링할 시점을 판단하는 데 '냄새'라는 표현을 사용할 수 있다. 리팩터링을 멈추는 기준은 정확한 기준이 아니라 문제의 징후를 제시하고, 경험을 통해 감을 키워야 한다. 리팩터링 기법을 적용할 때는 냄새를 찾고, 이 책의 내용과 부록 B를 참고하여 올바른 방향으로 나아갈 수 있다.
+
+---
+
+#### 1. 기이한 이름 (Mysterious Name)
+
+코드의 가독성을 높이기 위해 이름을 명료하고 신중하게 지어야 한다. 이름 바꾸기는 리팩터링의 일환으로, 함수, 변수, 필드의 이름을 바꾸는 것이 중요하다. 이름을 잘 지으면 코드의 이해와 유지보수가 용이해진다.
+
+#### 2. 중복 코드 (Duplicated Code)
+
+코드 중복을 피하기 위해 리팩토링을 사용하여 중복 코드를 통합하고 개선할 수 있다. 중복된 코드를 수정할 때는 함수 추출하기와 문장 슬라이드하기를 사용하여 코드를 모아서 적용할 수 있다. 또한, 부모 클래스에서 파생된 서브클래스의 중복 코드는 메서드 올리기를 사용하여 부모로 옮길 수 있다.
+
+#### 3. 긴 함수 (Long Function)
+
+프로그램의 유지보수성을 높이기 위해 짧은 함수로 구성된 코드베이스를 만들고, 함수 이름을 잘 지어서 코드를 이해하기 쉽게 만들어야 한다. 함수 추출하기를 통해 코드 덩어리를 찾아내고, 매개변수와 임시 변수를 줄이기 위해 리팩터링 기법을 적용할 수 있다. 주석이나 조건문, 반복문도 추출 대상을 찾는 데 도움이 된다.
+
+#### 4. 긴 매개변수 목록 (Long Parameter List)
+
+함수에 필요한 매개변수를 전달하는 방식은 매개변수 목록이 길어지면 이해하기 어려워지므로, 매개변수를 질의 함수로 바꾸거나 객체 통째로 넘기기를 사용하여 매개변수를 줄일 수 있다. 매개변수 객체 만들기로 함께 전달되는 매개변수들을 묶고, 플래그 인수 제거하기로 플래그 역할의 매개변수를 없앨 수 있다. 클래스를 사용하여 매개변수 목록을 줄이고, 함수들이 공통으로 사용하는 값을 클래스의 필드로 정의할 수 있다.
+
+#### 5. 전역 데이터 (Global Data)
+
+전역 데이터 사용은 주의해야 하며, 변수 캡슐화하기 리팩터링을 통해 데이터 오염을 방지하고 접근을 통제할 수 있다. 전역 데이터가 가변일 경우 다루기 어렵지만, 적은 양의 전역 데이터라도 캡슐화하는 것이 좋다.
+
+#### 6. 가변 데이터 (Mutable Data)
+
+데이터 변경으로 인한 예상치 못한 결과와 버그를 피하기 위해 함수형 프로그래밍에서는 데이터를 변경하지 않고 복사본을 반환하는 개념을 사용한다. 변수 값을 변경할 수 있는 언어에서도 불변성의 장점을 활용할 수 있다. 변수 캡슐화, 변수 쪼개기, 문장 슬라이드, 함수 추출하기, 질의 함수와 변경 함수 분리하기, 세터 제거하기, 파생 변수를 질의 함수로 바꾸기, 클래스로 묶기, 변환 함수로 묶기, 참조를 값으로 바꾸기 등의 방법을 사용하여 데이터 수정에 따른 위험을 줄일 수 있다.
+
+#### 7. 뒤엉킨 변경 (Divergent Change)
+
+소프트웨어의 구조를 변경하기 쉬운 형태로 조직하고, 단일 책임 원칙을 지키며 뒤엉킨 변경을 피하는 것이 중요하다. 맥락별로 코드를 분리하고, 함수를 옮기고, 클래스를 추출하여 맥락을 명확히 구분하는 것이 좋다.
+
+#### 8. 산탄총 수술 (Shotgun Surgery)
+
+산탄총 수술은 코드 변경 시 자잘한 수정이 필요한 클래스가 많을 때 발생하며, 함께 변경되는 대상들을 함수나 필드로 묶거나 인라인 리팩터링으로 하나로 합치는 것이 좋다. 작은 함수와 클래스에 집중하되, 코드 재구성 중에는 큰 덩어리로 묶여도 괜찮다.
+
+#### 9. 기능 편애 (Feature Envy)
+
+프로그램을 모듈화할 때는 상호작용을 영역 내에서 최대화하고 영역 간 상호작용을 최소화하는 것이 중요하다. 기능 편애는 다른 모듈과의 상호작용이 많을 때 발생하며, 이를 해결하기 위해 함수를 옮기거나 추출하는 방법을 사용할 수 있다. 또한, 복잡한 패턴과 디자인 패턴을 활용하여 변경 냄새를 없앨 수 있다.
+
+#### 10. 데이터 뭉치 (Data Clumps)
+
+데이터 항목들을 함께 묶어서 클래스로 추출하고, 매개변수 객체 만들기나 객체 통째로 넘기기를 통해 데이터 뭉치를 처리하는 방법을 소개하고 있다. 데이터 뭉치를 클래스로 만들면 중복을 없애고 개발을 가속할 수 있다.
+
+#### 11. 기본형 집착 (Primitive Obsession)
+
+기본형을 객체로 대체하여 의미 있는 자료형을 사용함으로써 코드를 더 명확하게 만들 수 있다. 기본형으로만 표현된 코드를 객체 지향적으로 리팩터링하고, 기본형을 객체로 대체함으로써 조건부 동작을 다형성으로 바꾸기를 적용할 수 있다. 자주 함께 사용되는 기본형 그룹도 클래스 추출하기와 매개변수 객체 만들기를 활용하여 개선할 수 있다.
+
+#### 12. 반복되는 switch문 (Repeated Switches)
+
+중복된 switch문은 코드의 유지보수를 어렵게 만들며, 새로운 조건이 추가될 때마다 여러 switch문을 함께 수정해야 하는 문제가 있다. 다형성을 활용하여 반복된 switch문을 제거하고, 코드를 더 현대적인 스타일로 변환할 수 있다.
+
+#### 13. 반복문(Loops)
+
+반복문은 함수형 프로그래밍의 개념을 활용하여 파이프라인으로 대체할 수 있다. 일급 함수를 지원하는 언어에서는 필터나 맵과 같은 파이프라인 연산을 사용하여 코드를 더 명확하게 만들 수 있다.
+
+#### 14. 성의 없는 요소 (Lazy Element)
+
+불필요한 함수나 클래스는 제거하고, 인라인하기를 통해 코드를 단순화할 필요가 있다. 상속을 사용한 클래스의 역할이 줄어들었을 때는 계층 합치기를 적용하여 정리할 수 있다.
+
+#### 15. 추측성 일반화 (Speculative Generality)
+
+미래에 필요할 것으로 예상하며 작성한 코드는 현재에는 불필요한 낭비일 수 있다. 불필요한 추상 클래스나 더 이상 사용되지 않는 코드는 삭제하고, 간단하게 유지보수 가능한 코드로 정리한다.
+
+#### 16. 임시 필드 (Temporary Field)
+
+특정 상황에서만 값이 설정되는 필드는 클래스 추출하기를 통해 적절한 클래스로 이동시키고, 필요한 경우 케이스 추가하기로 대안 클래스를 만들어 유효성을 검사한 후에 제거할 수 있다.
+
+#### 17. 메시지 체인 (Message Chains)
+
+메시지 체인은 클라이언트가 한 객체를 통해 다른 객체를 얻은 뒤 계속해서 다른 객체에 메시지를 전달하는 코드를 의미한다. 이는 내비게이션 구조에 종속되어 있어서 중간 객체를 수정하면 클라이언트 코드도 수정해야 하는 문제가 있다. 이를 해결하기 위해 위임 숨기기를 활용한다.
+
+- 리팩터링 방법:
+
+  1. **위임 숨기기(Hide Delegate):** 중간 객체의 메시지 체인을 숨기기 위해 최종 결과를 반환하는 메서드를 중간 객체에 추가한다. 클라이언트 코드는 이 메서드만 호출하면 되며, 중간 객체의 내비게이션 구조는 감춰진다.
+  2. **함수 추출하기(Extract Function):** 메시지 체인의 결과 객체를 사용하는 코드를 따로 함수로 추출하고, 이를 통해 중간 객체의 내비게이션을 간결하게 만든다.
+  3. **함수 옮기기(Move Function):** 메시지 체인을 숨기기 위해 추출한 함수를 적절한 위치로 이동시킨다.
+
+메시지 체인이 필요한 경우, 중간 객체의 내비게이션 구조를 감추는 것이 중요하다. 클라이언트 코드가 중간 객체의 내부 구조에 의존하지 않도록 리팩터링하여 유연하고 유지보수가 쉬운 코드를 유지할 수 있다.
+
+```typescript
+// 옮긴이 앞의 문단은 7.7 위임 숨기기을 읽고 온 후라도 한 번에 이해하기 어려울 것 같아서
+// 예시들 준비했다. 우선 다음 코드가 메시지 체인의 전형적인 예다.
+
+managerName = aPerson.department.manager.name;
+
+// '체인을 구성하는모든 객체에 위임 숨기기를 적용할 수 있다'고 함은 부서장 이름을 바로 반환하는
+// 메서드를 사람 클래스에 추기할 수도 있고 부서 클래스에 추가할 수도 있다는 뜻이다. 혹은
+// 부서장을 얻는 메서드를 사람 클래스에 추가할 수도 있다.
+
+managerName = aPerson.department.managerName; // 관리자(manager)의 존재를 숨김
+managerNane = aPerson.manager.name; // 부서 객체 (department)의 존재를 숨김
+managerName = aPerson.managerName; // 부서 객체와 관리자 객체 모두의 존재를 숨김
+
+// 이 체인의 최종 결과 객체는 name이 반환하는 부서장의 이름이다.
+// 이 객체가 다음처럼 쓰인다고 해보자.
+
+managerName = aPerson.department.manager.name;
+report = "${managerName}께 ${aPerson.name} 님의 작업 로그...";
+console.log(report);
+
+// 여기서 보고서 생성 로직을 함수로 추출한 다음 적당한 모듈로 옮기면 체인의 존재가 감춰진다.
+
+console.log(reportAutoGenerator.report(aPerson));
+
+// 마지막으로 체인의 중간인 부서 정보를 얻어 사용하는 다수의 클라이언트가 부서장 이름도 함께
+// 사용한다면 부서 클래스에 managername() 메서드를 추가하여 체인을 단축할 수 있다.
+```
+
+#### 18. 중개자 (Middle Man)
+
+객체의 캡슐화는 외부로부터 세부사항을 숨기는 기능으로, 위임이 자주 사용된다. 중개자 제거하기를 활용하여 위임 메서드를 제거하고, 호출하는 쪽으로 인라인하자.
+
+#### 19. 내부자 거래 (Insider Trading)
+
+소프트웨어 개발자는 모듈 사이의 결합도를 낮추기 위해 함수 옮기기, 필드 옮기기, 위임 숨기기를 활용해야 한다. 또한, 상속 구조에서는 서브클래스를 위임으로 바꾸기나 슈퍼클래스를 위임으로 바꾸기를 사용하여 결합도를 최소화해야 한다.
+
+#### 20. 거대한 클래스 (Large Class)
+
+클래스가 너무 많은 일을 하거나 필드가 너무 많을 때는 클래스 추출하기를 사용하여 필드를 분리하고 중복 코드를 방지할 수 있다. 또한, 코드량이 많은 클래스에서는 중복을 제거하기 위해 작은 메서드로 분리하는 것이 좋다. 클라이언트가 거대 클래스의 특정 기능 그룹만 사용하는 경우, 해당 기능 그룹을 개별 클래스로 추출할 수 있다.
+
+#### 21. 서로 다른 인터페이스의 대안 클래스들 (Alternative Classes with Different Interfaces)
+
+클래스를 사용할 때의 큰 장점은 필요에 따라 언제든 다른 클래스로 교체할 수 있다는 것이다. 단, 교체하려면 인터페이스가 같아야 한다. 따라서 함수 선언 바꾸기로 메서드 시그니처를 일치시킨다. 때로는 이것만으로 부족한데, 이럴 때는 함수 옮기기를 이용하여 인터페이스가 같아질 때까지 필요한 동작들을 클래스 안으로 밀어 넣는다. 그리다 대안 클래스들 사이에 중복 코드가 생기면 슈퍼클래스 추출하기를 적용할지 고려해본다.
+
+#### 22. 데이터 클래스 (Data Class)
+
+데이터 클래스는 데이터 필드와 게터/세터 메서드로만 구성된 클래스를 말하며, public 필드가 있을 경우 레코드 캡슐화를 고려해야 한다. 다른 클래스에서 데이터 클래스의 게터나 세터를 사용하는 메서드를 찾아서 함수 옮기기를 고려하고, 필요한 동작이 엉뚱한 곳에 정의되어 있다면 클라이언트 코드를 데이터 클래스로 옮기는 것이 개선에 도움이 된다.
+
+#### 23. 상속포기 (Refused Bequest)
+
+서브클래스가 부모의 일부 동작은 필요하지만 인터페이스는 따르지 않을 때, 상속을 포기하고 위임으로 바꾸는 것이 좋다. 이를 통해 필요한 동작을 재활용하면서 상속 메커니즘에서 벗어날 수 있다.
+
+#### 24. 주석 (Comments)
+
+특정 코드 블록이 하는 일에 주석을 남기고 싶다면 함수 추출하기를 적용해본다. 이미 추출되어 있는 함수임에도 여전히 설명이 필요하다면 함수 선언 바꾸기로 함수 이름을 바꿔본다. 시스템이 동작하기 위한 선행조건을 명시하고 싶다면 어서션 추가하기가 대기하고 있다.
+
+> 주석을 남겨야겠다는 생각이 들면, 가장 면저 주석이 필요 없는 코드로 리팩터링해본다.
+
+
+뭘 할지 모를 때라면 주석을 달아두면 좋다. 현재 진행 상항뿐만 아니라 확실하지 않은 부분에 주석에 남긴다. 코드를 지금처럼 작성한 이유를 설명하는 용도로 달 수도 있다. 이런 정보는 나중에 코드를 수정해야 할 프로그래머에게. 특히 건망증이 심한 프로그래머에게 도움될 것이다.