리팩터링 Ch.3,4 코드에서나는 악취 & 테스트 구축

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

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

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

악취의 종류들

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

  • 중복코드

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

  • 긴 매개변수 목록

  • 전역 데이터

  • 가변 데이터

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

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

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

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

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

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

  • 추측성 일반화 (YAGNI)

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

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

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

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

  • 거대한 클래스

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

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

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

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

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

SRP: Single Responsibility Principle 단일 책임 원칙

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

profile
🇰🇷🇺🇸 #Back-End Engineer

0개의 댓글