해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.
-> 해결방법
기이한 이름
-> 함수 선언, 변수 이름, 필드 이름 변경으로 리팩토링
-> 마땅한 이름이 떠오르지 않는 경우 설계에 근본적 원인이 있을 수 있다. (극공감 🙄)
중복 코드
-> 함수 추출
-> 문장 슬라이드
-> 메소드 올리기
긴 함수
-> 함수 추출
-> 임시 변수를 질의 함수로 변경
-> 다중 변수를 매개변수 객체, 객체 통체로 넘기기 로 이용
-> 조건문/반복문 분해
-> switch case 문을 함수로
-> switch 조건을 다형성으로 변경
긴 매개변수 목록
전역 데이터
가변 데이터
뒤엉킨 변경
: 단일 책임 원칙(SRP)이 제대로 이루어 지지 않을 때 발생
하나의 모듈이 서로 다른 이유로 인해 여러 방식으로 변경될 때
ex) DB 추가가 이루어질 때마다 함수를 여러개 변경해야하는 일
산탄총 수술
: 코드를 변경할 때마다 자잘하게 수정해야할 클래스가 많은 경우
뒤엉킨 변경 과 산탄총 수술을 헷갈리기 쉬운데
단순하게, 뒤엉킨 변경의 해결방법은 모듈을 맥락별로 잘 쪼개는 것
산탄총 수술은 모듈을 맥락별로 잘 모으는 것
으로 이해하면 된다.
기능 편애
데이터 뭉치
기본형 집착
반복되는 switch문
반복문
성의없는 요소
-> 함수/클라스 인라인
-> 상속 사용시 계층 합치기 적용
추측성 일반화
-> 죽은 코드 제거하기
임시 필드
-> 다른 곳으로 합치기
메시지 체인: 객체를 요청하는 작업이 연쇄적으로 이어지는 코드
-> 함수 추출
중개자
내부자 거래
-> 서브/슈퍼클래스 위임으로 변경
거대한 클래스
-> 클래스/슈퍼클래스 추출
-> 타입 코드 서브클래스로 변경
서로 다른 인터페이스의 대안 클래스들
데이터 클래스
-> 불변필드는 세터 제거하기
-> public 필드 레코드 캡슐화
상속 포기
-> 부모의 불필요한 메소드와 데이터는 받지 않기
주석
단계: 함수 추출하기 -> 함수 선언 바꾸기 -> assertion 추가
코드에서 지양되어야할 점들을 "악취"라고 표현한 것 같다.
'기이한 이름'의 경우 가장 큰 공감이 되는 것중 하나였다.
SRP참고: https://nesoy.github.io/articles/2017-12/SRP
assertion: https://developer.mozilla.org/ko/docs/Web/API/Console/assert