[리팩터링 2판] 3. 코드에서 나는 악취

Ash·2021년 11월 14일
0

해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.

악취의 종류

-> 해결방법
  1. 기이한 이름
    -> 함수 선언, 변수 이름, 필드 이름 변경으로 리팩토링
    -> 마땅한 이름이 떠오르지 않는 경우 설계에 근본적 원인이 있을 수 있다. (극공감 🙄)

  2. 중복 코드
    -> 함수 추출
    -> 문장 슬라이드
    -> 메소드 올리기

  3. 긴 함수
    -> 함수 추출
    -> 임시 변수를 질의 함수로 변경
    -> 다중 변수를 매개변수 객체, 객체 통체로 넘기기 로 이용
    -> 조건문/반복문 분해
    -> switch case 문을 함수로
    -> switch 조건을 다형성으로 변경

  4. 긴 매개변수 목록

    • 매개 변수를 질의함수로 변경
    • 다중 변수를 매개변수 객체, 객체 통체로 넘기기
    • 플러그 인수 제거
    • 여러 함수를 클래스로 묶기
  5. 전역 데이터

  6. 가변 데이터

  7. 뒤엉킨 변경
    : 단일 책임 원칙(SRP)이 제대로 이루어 지지 않을 때 발생
    하나의 모듈이 서로 다른 이유로 인해 여러 방식으로 변경될 때
    ex) DB 추가가 이루어질 때마다 함수를 여러개 변경해야하는 일

  8. 산탄총 수술
    : 코드를 변경할 때마다 자잘하게 수정해야할 클래스가 많은 경우

뒤엉킨 변경산탄총 수술을 헷갈리기 쉬운데
단순하게, 뒤엉킨 변경의 해결방법은 모듈을 맥락별로 잘 쪼개는 것
산탄총 수술은 모듈을 맥락별로 잘 모으는 것
으로 이해하면 된다.

  1. 기능 편애

  2. 데이터 뭉치

  3. 기본형 집착

  4. 반복되는 switch문

  5. 반복문

  6. 성의없는 요소
    -> 함수/클라스 인라인
    -> 상속 사용시 계층 합치기 적용

  7. 추측성 일반화
    -> 죽은 코드 제거하기

  8. 임시 필드
    -> 다른 곳으로 합치기

  9. 메시지 체인: 객체를 요청하는 작업이 연쇄적으로 이어지는 코드
    -> 함수 추출

  10. 중개자

  11. 내부자 거래
    -> 서브/슈퍼클래스 위임으로 변경

  12. 거대한 클래스
    -> 클래스/슈퍼클래스 추출
    -> 타입 코드 서브클래스로 변경

  13. 서로 다른 인터페이스의 대안 클래스들

  14. 데이터 클래스
    -> 불변필드는 세터 제거하기
    -> public 필드 레코드 캡슐화

  15. 상속 포기
    -> 부모의 불필요한 메소드와 데이터는 받지 않기

  16. 주석
    단계: 함수 추출하기 -> 함수 선언 바꾸기 -> assertion 추가

코드에서 지양되어야할 점들을 "악취"라고 표현한 것 같다.
'기이한 이름'의 경우 가장 큰 공감이 되는 것중 하나였다.

참고문서

SRP참고: https://nesoy.github.io/articles/2017-12/SRP
assertion: https://developer.mozilla.org/ko/docs/Web/API/Console/assert

profile
기록남기기👩‍💻

0개의 댓글