Refactoring - 3장 코드에서 나는 악취

본 내용은 한달한권의 리팩터링 강의를 토대로 작성되었습니다.

 

0. 이 책의 포인트

• 프로그래밍 '미학'의 체계적 정리
• 리팩터링 단계의 체계적 규정
• 리팩터링 '사전' 작성
  • 악취 -> 기법 -> 절차
  • 악취 : 더러운 코드, 리팩터링이 필요한 코드
• 어디까지 리팩터링 해야 하나?
  • 숙련된 개발자의 직관

 

1. 악취의 종류들

• 기이한 이름
  • 이름은 각각 변수, 함수 모듈이 무엇을 하는지 잘 드러내야 함
  • 이름이 마땅히 떠오르지 않는다면, 설계에 문제
• 중복코드
• 긴 함수
  • 이름에 의도를 담은 여러 함수들로 쪼개기
  • 저자의 함수형 언어 백그라운드 : 다층의 함수 추구(짧은 함수 지향)
  • 함수는 다섯 줄이 넘지 않아야 한다? 저자의 스타일
• 긴 매개변수 목록
  • 많은 매개변수, 옵셔널 매개변수…
  • 함수 호출이 복잡해짐
• 전역 데이터
• 가변 데이터
  • 참조형 변수의 문제
• SRP(single responsibility Principle, 단일 책임 원칙)
  • 뒤엉킨 변경 : 한 코드에 여럿이 섞여 들어감
  • 산탄총 수술 : 여러 코드에 흩뿌려짐'
• 기능 편애
  • 클래스 내부의 데이터보다 다른 클래스의 데이터와 상호작용이 많을 때
  • 클래스 설계 자체의 문제
• 데이터 뭉치
  • 몰려 다니는 데이터는 뭉쳐야 함 -> 데이터 클래스
  • 값중에 하나를 삭제 했을 때 의미가 없어지면
• 기본형 집착
  • 오브젝트화 하면 좋을 것을 기본형으로 쓰지 말것
  • ex) 화폐
• 반복되는 switch 문
  • 지금은 적당히 쓰기
• 반복문
  • 파이프라인으로 수정
• 성의 없는 요소
  • 코드 한두줄과 다를 바 없는 함수
  • 메서드가 하나뿐인 클래스
• 추측성 일반화
  • YAGNI
• 임시 필드
  • 특정 상황에만 값이 설정되는 필드
  • ex) 특이 케이스 추가
• 메시지 체인
  • 꼬리를 무는 게터
  • 위임 호출
• 중개자
  • 클래스가 중개자로 전락
• 내부자 거래
  • 클래스가 위임과 결합도가 너무 높을 때
• 거대한 클래스
• 서로 다른 인터페이스의 대안 클래스들
  • 두 비슷한 클래스, 다른 인터페이스 구현
• 데이터 클래스
  • 게터와 세터만 존재하는 클래스
  • 다른 클래스가 너무 깊이까지 함부로 다룰 수 있음
  • 필요한 동작이 다른 곳에 정의되어 있을 수도 있음
• 상속 포기
  • 부모의 public 요소를 사용할 것이 아니면, 상속하지 않는 게 나음
• 주석