• 프로그래밍 '미학'의 체계적 정리
• 리팩터링 단계의 체계적 규정
• 리팩터링 '사전' 작성
  악취 -> 기법 -> 절차
  

악취 = 리팩터링이 필요한 코드

그럼 냄새를 어디까지 빼야하나
=> 숙련된 개발자의 직관...

악취의 종류들

• 기이한 이름
  만약에 이 함수의 이름이 바로 떠오르지 않는다면 설계에 문제가 있을 가능성

• 중복코드

• 긴 함수
  이름에 의도를 담은 여러 함수들로 쪼개기

• 긴 매개변수 목록

• 전역 데이터

• 가변 데이터

• 기능 편애
  나보다 다른 모듈과의 상호작용이 더 많을 때

• 데이터 뭉치
  언제? 값 하나를 삭제 해봤을 때 의미가 없어지면

• 기본형 집착
  오브젝트화 하면 좋을 것을 굳이 기본형으로 쓰지말라

• 반복되는 switch 문
  옛날엔 선호되었지만, 그후에는 또 꺼려졌고, 근데 지금 많이 진화되기도 했지만 그래도 적당히 쓰자

• 반복문
  파이프라인으로 수정: 우리가 2판을 읽어야 하는 이유

• 성의 없는 요소
  코드 한두줄과 다를 바 없는 함수,
  메서드가 하나뿐인 클래스

• 추측성 일반화 (YAGNI)

• 임시 필드
  특정 상황에만 값이 설정되는 필드 (예: 특이 케이스 추가)

• 메세지 체인
  꼬리에 꼬리를 무는 게터
  

• 중개자
  아래가 문제일 때: 클래스가 중개자로 전락한다면
  다시말해 getManagerXX() 가 Employee 구현의 대다수를 차지한다면

• 내부자 거래
  위에가 문제일때: (예: 클래스가 위임과 결합도가 너무 높다면
  왜 문제일까? Manager의 구조가 바뀌다면

• 거대한 클래스

• 서로 다른 인터페이스의 대안 클래스들
  두 비슷한 클래스, 그러나 다른 인터페이스를 구현

• 데이터 클래스
  게터와 세터만 존재하는 클래스
  문제: 다른 클래스가 너무 깊이까지 함부로 다룰 때가 많다.
  필요한 동작이 엉뚱한 데 정의돼 있다는 신호일 수 있음

• 상속 포기
  부모의 public 요소를 사용할 게 아니라면 상속하지 않는 게 낫다.
  e.g Java의 Stack

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

• 리팩토링의 핵심은 겉보기 동작의 유지
  "코드가 깨졌다면 그것은 리팩터링이 아니라 어설픈 Restructuring"
  그것을 보장해 주는 것이 테스트

SRP: Single Responsibility Principle 단일 책임 원칙

출처 - 제로베이스 강의베이스로 공부함