본문으로 바로가기

https://www.inflearn.com/course/리팩토링

 

코딩으로 학습하는 리팩토링 - 인프런 | 강의

리팩토링은 소프트웨어 엔지니어가 갖춰야 할 기본적인 소양 중 하나입니다. 이 강의는 인텔리J와 자바를 사용하여 보다 실용적인 방법으로 다양한 코드의 냄새와 리팩토링 기술을 설명하고 직

www.inflearn.com

 

데이터 클래스

냄새 22. 데이터 클래스
  • 데이터 클래스 : public 필드 또는 필드에 대한 게터와 세터만 있는 클래스.
    - 코드가 적절한 위치에 있지 않기 때문에 이러한 냄새가 생길 수 있다.
    - 예외적으로 "단계 쪼개기" 에서 중간 데이터를 표현하는데 사용할 레코드는 불변 객체로 데이터를 전달하는 용도로 사용할 수 있다.
  • public 필드를 가지고 있따면 레코드 캡슐화하기 를 사용해 게터나 세터를 통해서 접근하도록 고칠 수 있다.
  • 변경되지 않아야 할 필드에는 세터 제거하기 를 적용할 수 있다.
  • 게터와 세터가 사용되는 메소드를 찾아보고 함수 옮기기을 사용해서 데이터 클래스로 옮길 수 있다.
  • 메소드 전체가 아니라 일부 코드만 옮겨야 한다면 함수 추출하기 을 선행한뒤에 옮길 수 있다.
리팩토링 42. 레코드 캡슐화하기
  • 변하는 데이터를 다룰 때는 레코드 보다는 객체를 선호한다.
    - 여기서 레코드란 public 필드로 구성된 데이터 클래스를 말함 (자바에서는 불변객체)
    - 데이터를 메소드 뒤로 감추면 객체의 클라이언트는 어떤 데이터가 저장되어 있는지 신경쓸 필요가 없다.
    - 필드 이름을 변경할 때 점진적으로 변경할 수 있다.
    - 하지만 자바의 Record는 불변 객체라서 이런 리팩토링이 필요없다.
  • public 필드를 사용하는 코드를 private 필드와 세터를 사용하도록 제한한다.

 

상속 포기

냄새 23. 상속 포기
  • 서브클래스가 슈퍼클래스에 제공하는 메소드나 데이터를 잘 활용하지 않는다는 것은 해당 상속 구조에 문제가 있다는 뜻이다.
    - 기존의 서브클래스 또는 새로운 서브클래스를 만들고 슈퍼클래스에서 "메소드와 필드를 내려주면" 슈퍼클래스에 공동으로 사용하는 기능만 남길 수 있다.
  • 서브클래스가 슈퍼클래스의 기능을 재사용하고 싶지만 인터페이스를 따르고 싶지 않은 경우에는 "슈퍼클래스 또는 서브클래스를 위임으로 교체하기" 리팩토링을 적용할 수 있다.

 

주석

냄새 24. 주석
  • 주석을 남겨야 할 것 같다면 먼저 코드를 리팩토링하라. 불필요한 주석을 줄일 수 있다.
    - 모든 주석이 나쁘다는 것도 아니고, 주석을 쓰지 말자는 것도 아니다.
    - 주석은 좋은 냄새에 해당하기도 한다.
  • 관련 리팩토링
    - "함수 추출하기" 를 사용해 설명이 필요한 부분을 별도의 메소드로 빼낸다.
    - "함수 선언부 변경하기"를 사용해 함수 이름을 재정의 할 수 있다.
    - 시스템적으로 어떤 필요한 규칙이 있다면, "어서션 추가하기" 을 적용할 수 있다.
리팩토링 43. 어서션 추가하기
  • 종종 코드로 표현하지 않았지만 기본적으로 가정하고 있는 조건들이 있다. 그런 조건을 알고리듬을 파악하거나 주석을 읽으면서 확인할 수 있다.
  • 그러한 조건을 Assertion을 사용해서 보다 명시적으로 나타낼 수 있다.
  • Assertion은 if나 switch 문과 달리 "항상" true이길 기대한느 조건을 표현할 때 사용한다.
    - 프로그램이 Assertion에서 실패한다면 프로그래머의 실수로 생각할 수 있다.
    - Assertion이 없어도 프로그램이 동작해야 한다. (자바에서는 컴파일 옵션으로 assert 문을 사용하지 않도록 설정할 수도 있다.)
  • 특정 부분에서 특정한 상태를 가정하고 있다는 것을 명시적으로 나타냄으로써, 의사소통적인 가치를 지니고 있다.
  • -ea (enable assertion) 옵션을 주지 않으면 runtime에는 체크하지않고 사라진다. (컴파일에서 체크함, 테스트코드에서는 동작)
    -> 가정 상황에 대해 주석보다는 의사소통을 위한 표현으로 사용됨

 

리팩토링 카탈로그

카탈로그 1. 기본 기술
  • 함수 추출하기
  • 함수 인라인하기
  • 변수 추출하기
  • 변수 인라인하기
  • 함수 선언 변경하기
  • 변수 캡슐화하기
  • 변수 이름 바꾸기
  • 매개 변수 객체 만들기
  • 여러 함수를 클래스로 묶기
  • 여러 함수를 변환 함수로 묶기
  • 단계 쪼개기
카탈로그 2. 캡슐화
  • 모듈에서 외부 시스템으로 공개하지 않아도 되는 데이터를 숨기는 기술
  • 레코드 캡슐화하기
  • 컬렉션 캡슐화하기
  • 기본형을 객체로 바꾸기
  • 임시 변수를 질의 함수로 바꾸기
  • 클래스 추출하기
  • 클래스 인라인하기
  • 위임 숨기기
  • 중재자 제거하기
  • 알고리듬 교체하기
카탈로그 3.기능 옮기기
  • 함수나 필드 또는 문장을 적절한 위치로 옮기는 기술
  • 함수 옮기기
  • 필드 옮기기
  • 문장을 함수로 옮기기
  • 문장을 호출한 곳으로 옮기기
  • 인라인 코드를 함수 호출로 바꾸기
  • 문장 슬라이드하기
  • 반복문 쪼개기
  • 반복문을 파이프라인으로 바꾸기
  • 죽은 코드 제거하기
카탈로그 4. 데이터 조직화
  • 데이터 구조를 다루는 기술
  • 변수 쪼개기
  • 필드 이름 바꾸기
  • 파생 변수를 질의 함수로 바꾸기
  • 참조를 값으로 바꾸기
  • 값을 참조로 바꾸기
카탈로그 5. 조건부 로직 간소화
  • 복잡한 조건문을 다루는 기술
  • 조건문 분해하기
  • 조건식 통합하기
  • 중첩 조건문을 보호 구문으로 바꾸기
    -> return 을 바로하여, else를 사용하지 않고 if만 사용한다.
  • 조건부 로직을 다형성으로 바꾸기
  • 특이 케이스 추가하기
  • 어서션 추가하기
카탈로그 6. API 리팩토링
  • 쉽고 이해하고 사용할 수 있는 API 만드는 기술
  • 질의 함수와 변경 함수 분리하기
  • 함수 매개변수화하기
  • 플래그 인수 제거하기
  • 객체 통째로 넘기기
  • 매개변수를 질의 함수로 바꾸기
  • 질의 함수를 매개변수로 바꾸기
  • 세터 제거하기
  • 생성자를 팩토리 함수로 바꾸기
  • 함수를 명령으로 바꾸기
  • 명령을 함수로 바꾸기
카탈로그 7. 상속 다루기
  • 상속을 제대로 사용하는 기술
  • 메소드 올리기
  • 필드 올리기
  • 생성자 본문 올리기
  • 메서드 내리기
  • 필드 내리기
  • 타입 코드를 서브클래스로 바꾸기
  • 서브클래스 제거하기
  • 슈퍼클래스 추출하기
  • 계층 합치기
  • 서브클래스를 위임으로 바꾸기
  • 슈퍼클래스를 위임으로 바꾸기