개발 다이어리

개요

함수는 여러 동작을 하나로 묶어준다.

함수 이름은 코드 동작 방식보다 목적을 말해주기에 함수를 활용하면 코드 이해가 쉬워진다.

함수는 중복 제거에도 효과적이다.

라이브러리가 제공하는 함수로 대체할 수 있다면 좋다. 함수 본문을 작성할 필요조차 없기 때문이다.

따라서 라이브러리가 제공하는 API를 잘 파악할 수록 이 이팩터링 활용 빈도가 높아진다.

개요

함수는 추상화의 기본 빌딩 블록

추상화의 경계를 항상 올바르게 긋기는 쉽지 않다.

코드 베이스의 기능 범위가 달라지면 추상화의 경계도 움직인다.

초기에 응집도 높고 한 가지 일만 수행하던 함수가 둘 이상 다른 일을 수행하게 바뀔 수 있다는 뜻

예시

개요

중복 제거는 건강한 코드를 위해 필요하다.

중복되는 코드를 발견하면 반복 부분을 함수로 합치는 방법을 강구한다.

합쳐놓으면 변경이 발생 시 단 한곳만 수정하면 된다.

코드를 여러 변형으로 나눠야 하는 순간이 오면 문장을 호출한 곳으로 옮기기를 적용하면 된다.

예시

사진 관련 데이트럴 HTML로 내보내는 코드

개요

적합한 데이터 구조를 활용하면 동작 코드는 자연스럽게 단순하고 직관적으로 짜여진다.

데이터 구조를 잘못 선택하면 데이터를 다루기 위한 코드로 범벅이 된다. 결국 이해하기 힘든 코드가 된다.

현재 데이터 구조가 적절치 않으면 바로 수정해야 한다.

함수에 어떤 레코드를 넘길 때마다 다른 레코드의 필드도 함께 넘기고 있다면, 필드 옮기기가 필요하다.

한 레코드의 변경을 할 때마다 다른 레코드의 필드까지 변경해야 한다면, 필드 옮기기가 필요하다.

여러 레코드에 정의된 똑같은 필드가 있을 때 한 레코드의 그 필드가 갱신될 시 다른 레코드 필드도 갱신해야 한다면 필드 옮기기가 필요하다.

필드 옮기기는 대체로 더 큰 리펙터링을 위한 사전 작업인 경우가 많다.

레코드 뿐만 아니라 클래스도 똑같다. 데이터에 함수가 더 해진 레코드가 클래스이기 때문이다.

클래스는 접근자 메서드로 캡슐화가 되어 있어 비교적 이 리팩터링이 쉽다.

캡슐화되자 않은 날레코드는 훨씬 까다롭다.

예시

이 리팩터링은 객체를 활용할 때 수월하다.

캡슐화 덕분에 데이터 접근이 메서드로도 메끄럽다.

함수로는 더 까다롭다.

예시: 공유 객체로 이동하기

이자율을 계좌 별로 설정하는 예시

개요

좋은 소프트웨어 설계 핵심은 모듈화 수준이다.

모듈성이란 프로그램 어딘가를 수정 시 해당 기능과 관련된 극히 작은 부분만 이해 해도되는 능력이다.

모듈성이 높으려면 연관된 요소를 하나의 요소로 묶고, 요소 사이 연결 관계를 쉽게 이해할 수 있어야 한다.

객체 지향 프로그래밍의 핵심 모듈화 컨텍스트는 클래스다.

A 함수가 자신이 속한 모듈보다 다른 모듈을 더 참조한다면 옮겨야한다.

예시: 중첩 함수를 최상위로 옮기기

예시: 다른 클래스로 옮기기

개요

목적을 달성하는 방법은 여러 가지

기존 방식보다 더 쉬운 방법을 발견하면 변경한다.

예를들어 기존 기능을 똑같이 지원하는 라이브러리를 찾았다면 라이브러리를 쓰는 편이 좋을 것

이 작업을 위해선 메서드 기능을 가능한 잘게 나눠야 한다.

예시

개요

클라이언트가 서버의 위임 객체의 다른 기능을 사용하고 싶을 때 마다 위임 메서드를 추가해야한다. 과도하면 단순히 위임 메서드만 들어나 성가셔진다.

서버는 단순히 중개자 역할로 전락할 수 있어 이럴 바엔 그냥 클라이언트가 위임 객체를 직접 호출하는 게 나을 수 있다.

데메테르 법칙을 너무 지나치게 지킬 때 이런 상황이 발생한다.

내부 정보를 가능한 숨기고 밀접한 모듈과만 상호작용하여 결합도를 낮추자는 원칙

이 과정에서 래퍼 클래스나 위임 객체가 너무 늘어나는 부작용이 있다.

균형을 잡는 것이 중요하다.

그 균형점을 잡는 것은 너무 고민하지 않아도 된다. 리팩터링으로 다시 변경하기 쉽기 때문이다.

예시

Department 객체를 통해 manager를 찾는다.

중개 메서드는 균형이 중요하다. 반드시 하나를 정해서 다 적용하거나 다 적용하지 않거나 할 필요가 없다.

자신이 처한 상황에 따라 절적히 섞어쓰는 지혜가 필요하다.

개요

클래스 추출하기의 정반대 리팩터링

더 이상 제역할을 못하는 클래스를 인라인한다. 판단 기준은 더 이상 그 클래스 역할이 거의 없을 때이다. 옮기는 위치는 그 클래스를 자주 사용하는 곳

다른 케이스로 두 클래스의 기능을 지금과 다르게 배분하고 싶을 때도 일단 클래스를 인라인한다. 그리고 다시 클래스를 추출한다.

상황에 따라 컨텍스트 요소를 하나씩 옮기는 게 편할 수도, 아니면 일단 클래스를 인라인하고, 다시 클래스 추출하기가 편할 수도 있다.

예시