6. 기본적인 리팩터링

[rkaehdaos]

Intro

• 가장 많이 사용: 함수 추출, 변수 추출
• 위의 반대도 자주 사용 : 함수인라인, 변수 인라인
• 추출은 결국 이름 짓기 : 함수 선언 바꾸기, 변수 이름 바꾸기-변수 캡슐화와 관련 깊음
• 자주 뭉쳐 다니는 인수들 : 매개변수 객체 만들기

저수준 -> 고수준

• 저수준 리팩터링 : 함수 구성, 이름 짓기
• 함수를 만들면 고수준 모듈로 묶어야 함
  1. 여러 함수를 클래스로 묶기 : 함수를 그룹으로 묶기
  2. 여러 함수를 변환함수로 묶기 : 읽기 전용 데이터 다룰 때 특히 좋다
  3. 한걸음 더 : 한데 묶은 모듈들의 작업 처리 과정을 명확한 단계(phase)로 구분 짓기 → 단계 쪼개기 적용

[rkaehdaos]

6.1 함수 추출하기 - Extract Function

이 함수의 표현은 객체지향의 메서드, 절차형의 프로시저/서브루틴과 매칭된다

배경

• 코드 조각을 찾아 무슨 일을 하는지 파악한 후 독립 함수로 추출하고 목적에 맞는 네이밍
• 언제 필요?
• 길이?? : 예를 들어 한 화면을 넘어가면 안되다는 규칙을 떠올릴 수 있음
• 재사용성?? : 2번 이상 사용될 코드?
• 책에서 말하는 가장 합리적인 기준? "목적과 구현을 분리"하는 방식
• 코드가 무슨 일을 하는지 파악하는데 한참 걸린다? → 해당 부분을 함수 추출 후 '무슨 일'에 걸맞는 네이밍 작업
• 나중에 읽을 때 목적이 한 눈에 들어오고. 함수 내부 본문 코드는 더 신경 쓸 필요가 없음
• 마틴 파울러 경험 이야기
• 경험상 대여섯줄 넘어가면 냄새가 난다. 단 한 줄 짜리 함수를 만드는 일도 적지 않다
• 켄트백의 극단적인 스몰토크 예
• helight()는 단순히 색상반전을 위한reserve()호출
• 메서드 이름이 구현 코드보다 길었음
• 코드의 목적(강조)와 구현(반전)사이의 차가 그만큼 컸으므로 문제가 되지 않는다
• 함수 호출 많아져 성능 느려짐?
• 요즘엔 그럴 일이 거의 없음
• 짧으면 더 캐싱이 쉽다 → 컴파일러가 최적화시 유리 성능 최적화 일반 원칙 : 첫번째 하지마라, 두 번째(전문가 한정), 아직 하지 마라 - M. A. Jackson

짧은 함수의 이점은 이름을 잘 지어야만 발휘된다

• 네이밍에 특별히 신경써야 한다
• 어느 정도 훈련이 필요하며 요령 터득하면 별도 문서 없이 코드 자체 만으로 내용을 충분히 설명되게 가능
• 코드 덩어리 첫머리에 주석이 달려있다면 해당 주석을 참고하면 네이밍에 도움이 될 수 있다

[rkaehdaos]

[rkaehdaos]

절차

1. 함수를 새로 만들고 목적을 잘 드러내는 네이밍
   • 단 한 줄 이더라도 함수로 목적과 의도가 더 잘 드러나는 네이밍이 가능하다면 추출
   • 위의 네이밍이 떠오르지 않는다면? → 함수로 추출하면 안된다는 신호
   • 처음부터 좋은 네이밍 안떠오를 수 있으니 일단 추출해서 사용해보고 효과가 미비하다면 원래 상태로 인라인화 한다. 그 과정중에 조금이라도 깨달음이 있으면 낭비가 아님
   • 중첩함수를 지원하는 언어를 사용한다면 원래 함수에 중첩 시킨다. 그러면 스코프나 변수 작업을 줄일 수 있다. 나중에 바깥으로 꺼내야 할때가 오면 언제든 함수 옮기기를 사용하면 된다.
2. 추출한 코드를 원본 함수에서 복사해서 새 함수에 붙여 넣는다
3. 추출한 코드 중 원본 함수의 지역변수 참조하거나, 스코프 벗어나는 변수가 있다면 매개변수로 전달한다
4. 변수를 다 처리했다면 컴파일 한다.
5. 원본 함수에서 추출한 코드 부분을 새로 만든 함수를 호출하는 문장으로 바꾼다(위임)
6. 테스트
7. 다른 코드에 방금 추출과 똑같거나 비슷한 코드가 있는지 살펴보고 있다면 방금 만든 새 함수를 호출하도록 바꿀지 검토한다

[rkaehdaos]

Clock Wrapper

• https://martinfowler.com/bliki/ClockWrapper.html
• Date.now를 테스트에서 직접 호출하지 않는다
• 오류상황 재현이 어려우므로

[rkaehdaos]

예시: 지역 변수의 값 변경

• 문제가 복잡해짐
  • 매개변수에 값을 대입하는 코드를 발견하면 곧바로 그 변수를 쪼개서 임시변수를 새로 하나 만들어 그 변수에 대입하게 해야 한다
  • 임시변수만을 취급하는 문제로 국한 시켜야 함

다음 고려점 : 임시 변수의 스코프

• 추출된 코드안에서만 사용되는 경우 → 초기화 시점과 사용되는 지점이 떨어져 있다면 문장 슬라이드하기를 활용해서 변수 조작을 모두 한 곳에서 처리하도록

  문장 슬라이드 :

  

• 변수가 추출된 함수 밖에서 사용될 경우 → 변수에 대입된 새 값을 반환해야 한다.

[rkaehdaos]

값을 반환할 변수가 여러개라면?

• 몇가지 방법 존재
• 마틴 파울러의 방법 : 추출할 코드를 다르게 재구성하는 방향으로 처리
  • 함수가 값 하나만 반환하는 방법을 선호
  • 각각을 반환하는 함수 여러 개로 만든다
  • 값들을 레코드로 묶어서 반환해도 되지만 임시 변수 추출 작업을 다른 방식으로 처리하는 것이 좋다
  • 임시 변수를 질의 함수로 바꾸기 : 이러면 함수 추출시 변수를 따로 전달할 필요가 없음
  • 변수를 쪼개기 :

추출함수를 최상위 수준 같은 다른 context로 이동하려면?

• 스텝을 작게 : 먼저 중첩함수로 추출하고 새로운 문맥으로 옮겨라
• 이렇게 작게 하면 변수 처리가 어려울 수 있음 : 실제로 문맥에 옮겨보기 전에는 알지 못함
• 따라서 중첩함수로 추출 가능하더라도 최소한 원본 함수와 같은 수준의 문맥으로 먼저 추출해보면 제대로 추출했는지 즉각 판별 가능

[rkaehdaos]

6-2 함수 인라인하기

배경

• 목적이 분명히 드러나는 네이밍의 짤막한 함수 권장 : 코드 명료, 이해 쉬움
• 때로는
  • 함수 본문이 이름만큼 명확한 경우
  • 함수 본문 코드가 이름만큼 깔끔하게 리팩터링이 된 경우
• 이때는 함수를 제거한다 : 간접 호출은 유용할 수 있으나 쓸데 없는 간접 호출은 거슬릴 뿐

또 다른 인라인 대상

• 리팩터링 과정에서 잘못 추출된 함수들
• 간접 호출을 과하게 쓰는 코드들(위임 함수들이 너무 많아서 위임 관계가 복잡할 경우)

절차

1. 다형 메서드인지 확인 (서브 클래스에서 오버라이드 하는 메서드는 x)
2. 인라인할 함수를 호출하는 곳을 모두 찾는다
3. 각 호출문을 함수 본문으로 교체
4. 하나씩 교체ㅐ할 떄마다 테스트
5. 함수 정의(원래 함수)를 삭제한다

   이 절차를 적용하기 어려울정도로 복잡하다면 인라인하기를 적용하면 안되는 케이스

예시

[rkaehdaos]

변수 추출하기

배경

지역변수 사용

• 표현식이 복잡해서 이해가 어려울 때 활용하면 관리 쉽게 만들 수 있음
• 복잡한 로직을 구성하는 단계마다 이름을 붙일 수 있음
• 디버깅에도 도움 : breakpoint, print가 가능

변수 추출 고려 → 표현식에 이름을 붙이고 싶다는 의미

• 이름을 붙이기로 했으면 이름이 들어갈 문맥도 살펴봐야 한다
  • 현재 함수 안에서만 의미가 있다 → 변수 추출이 좋다
  • 현재 함수 밖에서도 의미가 된다 → 더 넓은 범위에서 통용되는 이름 → 함수로 추출이 좋다
  • 이름 통용되는 문맥 넓힘 → 다른 코드에서 사용 가능 → 같은 표현식 중복 작성 줄어든다 → 중복이 적으면서 의도가 잘 드러나는 코드 작성 가능
  • 이름 통용되는 문맥 넓힘의 단점 : 할 일이 늘어난다
  • 많이 늘어날 것 같다? → 임시변수를 질의 함수로 바꾸기를 적용할 때까지 놔둔다
  • 간단히 처리 할 것 같다? → 즉시 넓혀서 다른 코드에서도 사용 가능하도록 예로 클래스 안의 코드를 다룰떄는 함수 추출하기를 아주 쉽게 적용 가능

절차

1. 추출하는 표현식에 부작용이 없는지 확인
2. 불변 변수를 하나 선언하고 이름을 붙일 표현식의 복제본 대입
3. 원본 표현식을 새로 만든 변수로 교체
4. 테스트
5. 표현식을 사용하는 각각을 새로 만든 변수로 교체(하나 교체시 테스트)

[rkaehdaos]

ex2: 추출하는 표현식이 메서드를 넘어 클래스 전체 영향

//ex2
class Order{
    constructor(aRecord) {
        this._data = aRecord;
    }
    get quantity() {return this._data.quantity;}
    get itemPrice() {return this._data.itemPrice;}
    get price() {
        return order.quantity * order.itemPrice -
            Math.max(0, order.quantity - 500) * order.itemPrice * 0.05 +
            Math.min(order.quantity * order.itemPrice * 0.1, 100);
    }
}

• 변수가 아닌 메서드로 추출하자

[rkaehdaos]

6-4 inline variable

배경

• 변수 : 함수 안에서 표현식을 가리키는 이름, 대체로 긍적적인 효과
• 하지만 다음의 경우에는 인라인화해서 변수를 없애 주는 것이 좋다
  • 그 이름이 원래 표현식과 다를 바 없을 때
  • 변수가 주변 코드를 리팩터링하는데 방해가 될 때

절차

1. 대입문 우변(표현식) 부작용 여부 체크
2. 변수가 불변이 아니라면 불변으로 바꾸고 테스트 (값이 단 한 번만 대입되는지 확인)
3. 이 변수를 가장 처음 사용하는 코드를 찾아서 우변의 표현식으로 바꾼다
4. 테스트
5. 변수를 사용하는 모두 교체할 때까지 반복
6. 변수 선언문과 대입문을 삭제
7. 테스트

[rkaehdaos]

6.5 함수 선언 바꾸기 Change Function Declaration

시그니처 바꾸기

• 함수 : 프로그램을 작은 부분으로 나누는 주된 수단
• 함수 선언 : 각 부분이 서로 맞물리는 방식을 표현, 컴포넌트를 조립하는 연결부 역할
• 건축과 마찬가지로 SW도 연결부에 상당히 의존적
• 잘 정의하면 새로운 부분 추가가 쉬워지고, 잘못 정의하면 지속적으로 어려움
• 다행히 SW는 soft해서 연결부를 수정 가능(하지만 주의해서!)

함수의 이름 : 연결부에서 가장 중요한 요소

• 좋은 네이밍 : 구현 코드를 보지 않고 호출부 이름만 보고도 좋은 일을 파악 가능
• 네이밍 고민은 어렵다 : 절대 그대로 놔두고 싶은 유혹에 빠지면 안된다.
• 그래야 나중에 "또" 고민하지 않게 된다

  효과적인 방법 : 주석을 이용해 함수 목적을 설명해보자, 그러면 주석이 멋진 네이밍으로 되돌아올 때가 있다

함수의 매개변수 : 외부 세계와 어우러지는 방식을 정의

• 매개변수는 함수를 사용하는 context를 정의한다.
  • 전화번호 포매팅 함수가 매개변수로 사람을 받는다면? → 회사 전화번호 포매팅 불가
  • 사람대신 전화번호 자체를 매개변수로 받도록 정의? → 함수의 활용 범위를 넓힐 수 있음
  • 이렇게 하면 다른 모듈과 커플링도 제거 가능(ex: 전화번호 포매팅 함수를 사람 관련정보를 전혀 모르는 모듈에 옮겨 놓을 수 있음)
  • 동작에 필요한 모듈 수가 적다 → 무언가 수정시 머리에 담아둬야 할 내용도 적어진다
• 매개변수 올바로 선택하는 방법 : 정답이 없다
  • 예) 대여후 30일이 지났는지를 기준으로 기한이 넘었는지 판단하는 함수
  • 함수의 매개변수는 ? 지불객체가 적절? 마감일이 적절?
  • 지불 객체로 정한다면??
  • 단점 : 지불 객체의 인터페이스와 결합되어버린다 : 커플링
  • 장점 : 지불이 제공하는 여러 속성 쉽게 접근 → 내부 복잡도가 올라가도 해당 함수를 호출하는 코드를 일일이 찾아 변경 필요 없음 → 실질적 함수 캡슐화 수준 상승
• 시간이 흐르면 해당 정답이 바뀌는 경우도 존재
• 함수 선언 바꾸기에서 "이름 바꾸기"의 비중이 높음 → 이름만 단순히 바꿀땐 함수 이름 바꾸기라고 표현

[rkaehdaos]

절차

• 다른 리팩터링은 절차를 한가지만 소개 - 대부분 상황에서 대체로 효과적
• 함수 선언 바꾸기는 간단한 절차로 충분할 떄도 있지만 더 세분화된 '마이크레이션 절차'가 훨씬 적합한 경우도 많다
• 변경 사항을 살펴보고 함수 선언과 호출문을 단번에 고칠 수 있는가?
• 가능 하면 간단한 절차를 따른다
• 그렇지 않으면 마이그레이션 절차 : 호출문들을 점진적으로 수정 가능

간단한 절차

1. 매개변수를 제거하려거든 먼저 함수 본문에서 제거 대상 매개변수를 참조하는 곳은 없는지 확인
2. 메서드 선언을 원하는 형태로 바꾼다 (선언부 교체)
3. 기존 메서드 선언을 참조하는 부분을 모두 찾아서 바뀐 형태로 수정 (호출부 교체)
4. 테스트

변경할게 둘 이상?

• 나눠서 각각을 독립적으로 처리하는 것이 낫다
• 문제가 생기면 rollback후 마이그레이션 절차로 가자

마이그레이션 절차

1. 이어지는 단계를 수월하게 만들어야 한다면 함수 본문을 적절히 리팩토링
2. 함수 본문을 새로운 함수로 추출 (새로 만들 함수 이름이 기존 함수와 이름이 같다면 일단 임시 이름을 붙이자)
3. 추출한 함수에 매개 변수 추가 필요? → 위의 '간단한 절차'를 따라 추가
4. 테스트
5. 기존 함수 인라인
6. 임시 이름이 있다면 함수 선언 바꾸기 한번 더 적용해서 원래 이름으로 되돌린다
7. 테스트

상속 구조 속의 클래스 메서드 변경할 시 : 다른 클래스들도 변경 반영되어야

• 상황이 복잡함 : 간접 호출의 방식으로의 우회(혹은 중간 단계로 활용)하는 방법도 쓰임
  • 먼저 원하는 형태의 메서드를 새로 만들어서 원래 함수를 호출하는 전달 메서드로 활용하는 방법임
  • 단일 상속 구조라면 전달 메서드를 슈퍼 클래스에 정의하면 해결
  • 슈퍼 클래스 연결 제공 안하는 언어라면 전달 메서드를 모든 구현 클래스 각각에 추가해야 한다

[rkaehdaos]

간단한 절차의 단점

→ 호출문과 선언문을(다형성 구현의 경우 여러 선언문 모두를) 한번에 수정해야 한다 → 많지 않거나 좋은 도구를 쓰면 그리 어렵지 않으나 아주 많다면 힘들어짐 → 또한 같은 이름의 메서드가 여러 클래스에 정의되어있을대가 문제 → 예컨데 changeAddress()가 사람 클래스와 계약 클래스 모두에 정의된 경우 → 하나만 바꾸고 싶을 때 난감함 →이럴 때 마이그레이션 절차대로 해본다

[rkaehdaos]

함수 선언 바꾸기만큼은 직접 고칠수 없는 부분을 리팩터링하기에 좋다

• 리팩터링 대상은 대부분 직접 수정 가능한 코드
• 함수 선언 바꾸기는 공개API처럼 직접 고칠수 없는 외부 코드가 사용하는 부분 리팩터링 하기에 좋다

예시

• circumference()를 만들고나서 잠시 리팩터링 멈춤
• 가능하다면 circum()에 deprecated를 표시
• 다음 circum()의 클라이언트들 모두가 circumference()를 사용하게 바뀔 때까지 기다린다
• 모든 클라이언트가 새 함수를 쓴다면 원래 함수 circum()을 삭제한다

[rkaehdaos]

6-6 변수 캡슐화 하기 - Encapsulate Variable

필드 캡슐화

배경

함수는 데이터보다 다루기 수월하다

• 함수 사용 = 호출한다 → 함수 이름 변경, 옮기기는 어렵지 않다.
• 여차하면 위임하는 forward 함수로 활용할 수도 있기 때문

데이터는 함수보다 다루기 어렵다 : 이런식으로 처리가 안되므로

• 데이터는 참조하는 모든 부분을 한 번에 바꿔야 제대로 작동한다
• 짧은 함수의 임시변수처럼 스코프가 아주 작은 데이터는 문제가 안된다
• 스코프가 커질수록 다루기 어려워진다
• 전역 데이터가 골칫거리인 이유가 바로 여기에 있음

따라서 접근할수 있는 스코프가 넓은 데이터를 옮길때는?

• 먼저 그 데이터로의 접근을 독점하는 함수를 만드는 식으로 캡슐화 하는 것이 가장 좋은 방법일 때가 있다
• 데이터 재구성 이라는 어려운 작업 → 함수 재구성이란느 더 단순한 작업으로 변환한는 것

데이터 캡슐화의 다른 장점들

• 데이터 get/set 감시할 수 있는 확실한 통로 →변경 전 검증, 변경 후 추가 로직 쉽게 추가 가능
• 마틴 파울러 : 유효범위가 함수 하나보다 큰 가변 데이터는 모두 이런식으로 캡슐화해서 그 함수를 통해서만 접근하게 만든다
• 데이터 유효 범위가 넓을 수록 캡슐화 해야 한다
• 레거시 코드 → 이런 변수를 참조하는 코드를 추가/변경 할때마다 최대한 캡슐화
• 그래야 자주 사용하는 데이터에 대한 결합도가 높아지는 일을 막을 수 있다

객체 지향에서 객체의 데이터를 항상 private로 유지해야 한다는 이야기가 바로 여기!

• 클래스 내부에서도 접근자를 통하게 하는 자가 캡슐화는 지나치다(그정도로 클래스가 크다면 쪼개야한다.)

불변 데이터는 캡슐화 이유가 적다

• 변경될 일이 없음 : 갱싱 전 추가 로직등의 공간을 마련할 필요가 없음
• 옮길 필요가 없이 그냥 복제하면 됨
• 원본 참조 하는 코드 변경도 필요없고 데이터를 변형 시킬 수 있는 코드도 걱정없음

[rkaehdaos]

절차

1. 변수로의 접근, 갱신을 전담하는 캡슐화 함수들을 만든다
2. 정적 검사를 수행한다
3. 변수를 직접 참조하던 부분을 모두 적절한 캡슐화 함수 호출로 바꾼다 하나씩 바꿀 때마다 테스트한다
4. 변수의 접근 범위를 제한한다
5. 테스트한다
6. 변수 값이 레코드라면 레코드 캡슐화하기를 적용할지 고려

[rkaehdaos]

값 캡슐화하기

• 위의 [기본 캡슐화 기법]을 이용해 참조(getter)를 캡슐화하면 구조로의 접근이나 구조 자체를 다시 대입하는 행위 제어 가능
• 필드 값을 변경하는 일(Set)은 제어 불가
• 즉 기본 캡슐화 기법은 데이터 항목 참조 하는 부분만 캡슐화
• 보통은 이정도로 충분

변수 뿐 아니라 변수에 담긴 내용을 변경하는 행위도 제어할 수 있도록 캡슐화를 원한다면?

1. 그 값을 바꾸지 못하게 만든다

   • getter가 데이터의 복제본을 반환하도록 수정한다
   • export function defaultOwner() {return Object.assign({}m defaulutOwnerData);}
   • 특히 리스트에 이 기법 많이 적용
   • 만약 공유 데이터를 변경하기를 원하는 클라이언트가 있는 경우?
   • 문제가 되는 부분을 테스트로 찾는다

2. 아니면 아예 변경할 수 없도록 만든다 [레코드 캡슐화 하기]

   
   • 이렇게 하면 defaulutOwnerData의 속성을 다시 대입하는 연산을 모두 무시한다

3. setter에서도 복제본을 만드는 편이 좋은지도 살펴보자

[rkaehdaos]

6-7 변수 이름 바꾸기 Rename Variable

명확한 프로그래밍의 핵심은 이름 짓기

• 이름의 중요성은 사용범위에 영향을 많이 받는다
• 자바스크립트 같은 동적 타입 언어는 이름아펭 타입을 드러내는 문자를 붙이는 스타일 선호

함수 호출 한 번으로 끝나지 않고 갑싱 영속되는 필드라면 ? 아주 신중하게 네이밍!

절차

1. 폭 넓게 쓰이는 변수 ? 변수 캡슐화하기 고려
2. 이름을 바꿀 변수를 참조하는 곳을 모두 찾아서 하나씩 변경
   • 다른 코드 베이스에서 참조하는 변수→외부에 공개된 변수→ 적용 불가
   • 변수 값이 변하지 않는다면? 다른이름으로 하나씩 테스트하며 점진적 변경
3. 테스트

예시

가장 간단한 예

• 임시변수, 인수 처럼 유효범위가 함수 하나로 국한된 변수
• 그냥 하나씩 바꾸고 테스트하면 된다 함수 밖에서 참조할수 있는 변수 : 조심하자
• 주로 변수 캡슐화하기로 처리
• → 캡슐화 후에는 이름을 바꿔도 된다
• 래핑 함수 인라인해서 모든 호출자가 변수 직접 접근 → 안좋은 방법 → 이름을 바꾸기 위해 캡슐화를 해야할 정도로 널리 사용되는 변수라면 함수안에 캡슐화 된채로 두는 편이 좋다

상수이름 바꾸기

• 상수 이름은 캡슐화하지 않아도 복제 방식으로 점진적으로 바꿀 수 있음
• 새로 만든 상수가 기존 상수 참조하도록 해서 만든다

[rkaehdaos]

6-8 매개변수 객체 만들기

배경

• 데이터 항목 여러 개가 이 함수에서 저 함수로 함께 몰려다니는 경우를 자주 보게 된다
• 데이터 구조 하나로 묶으면?
  • 데이터 사이의 관계가 명확해진다
  • 매개변수 수가 줄어든다
  • 같은 데이터 구조를 사용하는 모든 함수가 항상 똑같은 이름을 사용 → 일관성도 높여준다
• 진정한 힘 : 코드를 더 근본적으로 바꿔준다
  • 이런 데이터 구조를 새로 발견하면 이 데이터 구조를 활용하는 형태로 프로그램 동작을 재구성한다
  • 이 과정에서 새로 만든 데이터 구조가 문제 영역을 훨씬 더 간결하게 표현하는 새로운 추상 개념으로 격상된다 그러면서 코드의 개념 청사진을 다시 그릴 수도 있다 → 그러면 놀라운 강력한 효과
  • 첫 시작은 매개변수 객체 만들기 부터

범위 개념은 객체 하나로 묶어 표현하는게 나은 대표적인 예다

• 최저온도 , 최고 온도
• 시작일, 종료일

[rkaehdaos]

절차

1. 적당한 데이터 구조가 아직 마련되어 있지 않다면 새로 만든다
   • 클래스 선호 → 나중에 동작까지 함께 묶기 좋기 때문
   • 주로 데이터 구조를 마틴파울러는 VO로 만든다
2. 테스트한다
3. 함수선언 바꾸기로 새 데이터 구조를 매개변수로 추가한다
4. 테스트한다
5. 함수 호출시 새로운 데이터 구조 인스턴스를 리턴하도록 수정한다. 하나씩 수정할 때마다 테스트 한다
6. 기존 매개변수를 사용하던 코드를 새 데이터 구조의 원소를 사용하도록 바꾼다
7. 다 바꿨다면 기존 매개변수를 제거하고 테스트한다

[rkaehdaos]

호출코드

• operatingPlan은 범위의 시작과 끝을 readingsOutsideRange와 다르게 표현하고 있다

• 범위(Range)s는 객체 하나로 묶어서 표현하는 것이 나은 대표적인 예시

[rkaehdaos]

클래스 선언 이유

• 어쨰서 기본 JS객체가 아닌 클래스인가?
• 이 리팩터링은 새로 생성한 객체로 동작까지 옮기는 더 큰 작업의 첫단계로 수행될 떄가 많다
• 클래스가 적합
• VO 객체로 만들 가능성이 높다 → setter는 만들지 않는다

[rkaehdaos]

진정한 값 객체로 거듭나기

• 매개변수 그룹을 객체로 교체하는 일은 진짜 값진 작업의 준비 단계 일 뿐
• 클래스로 만들면 관련동작을 이 클래스로 옮길 수 있음

[rkaehdaos]

6-9 여러 함수를 클래스로 묶기 - Combine Functions into Class

배경

클래스

• 대다수의 최신 프로그래밍 언어가 제공하는 기본 빌딩 블록
• 데이터와 함수를 하나의 공유환경으로 묶고 일부를 외부에 제공

공동테이터(흔히 호출시 인수로 전달되는)를 중심으로 긴밀히 엮여 작동하는 함수무리는 클래스 하나로

• 이 함수드링 공유하는 공통환경을 더 명확히 표현 가능
• 이런 객체를 시스템의 다른 부분에 전달하기 위한 참조 제공
• 이미 만들어진 함수들 재구성할 때 좋음
• 새로 만든 클래스 관련하여 놓친 연산을 찾아 새 클래스 메서드로 뽑는데도 좋은 리팩터링

함수로 한데 묶는 다른 방법 존재

• 다음에 설명할 [여러 함수를 변환함수로 묶기]도 있음
• 판단 : 프로그램 문맥을 넓게 살펴보고

클래스 묶을시 장점

• 클라이언트가 객체의 핵심 데이터 변경 가능
• 파생 객체들의 일관된 관리 가능

중첩함수로 묶기

• 위를 중첩함수로 묶는것도 가능하나 테스트가 까다로와질 수 있음
• 외부 공개할 함수가 여러개라면?
• 어차피 클래스 가는게 나음

클래스를 지원하지 않는 언어?

• 함수를 객체처럼 (Function As Object) 패턴 사용해서 구현하기

[rkaehdaos]

절차

1. 함수들이 공유하는 공통 데이터 레코드를 캡슐화
   • 공통 데이터가 레코드로 묶여 있지 않다면 먼저 매개변수 객체 만들기로 데이터를 하나로 묶는 레코드를 만든다
2. 공통 레코드를 사용하는 함수 각각을 새 클래스로 옮긴다
   • 공통 레코드 벰버는 함수 인출문 인수 목록에서 제거
3. 데이터를 조작하는 로직들은 함수로 추출해서 새 클래스로 옮긴다.

[rkaehdaos]

예시

[rkaehdaos]

6-10 여러 함수를 변환 함수로 묶기 - Combine Functions into Transform

도출 정보

• SW는 데이터를 입력받아 여러 정보를 도출한다
• 이 도출된 정보는 여러 곳에서 사용될 수 있으며 사용되는 곳마다 같은 로직이 반복되기도 한다
• 이를 모아두면 검색/갱신을 일관되게 처리 가능하며 중복도 막을 수 있다

변환함수

• 원본 데이터를 입력받아 필요 정보 도출 후 각각을 출력 데이터의 필드에 넣어 반환
• 나중에 도출 과정 검토시 변환 함수만 보면 된다
• 앞서 말했듯 앞에서 말한 클래스로 묶기로 처리해도 된다
• 마틴 : 대체로 SW에 이미 반영된 스타일을 따르는 편

클래스 묶기와 중요한 차이

• 원본 데이터가 코드 내에서 갱신될 떄 : 클래스로 묶는것이 낫다
• 변환함수는 가공한 데이터를 새로운 레코드에 저장, 일관성이 꺠질 수 있음

함수 추출하기로 같은 효과?

• 맞음
• 하지만 데이터 구조와 이를 사용하는 함수가 근처에 있어야 함수 추출할 부분 발견 가능
• 클래스나 변환함수로 묶다보면 추출할 함수들을 쉽게 발견 가능

[rkaehdaos]

절차

1. 변환할 레코드를 입력받아 값을 그대로 반환하는 변환함수를 만든다
   • 이 작업은 대체로 깊은 복사로 처리해야
   • 변환 함수가 레코드를 바꾸지 않는지 검사하는 테스트를 마련하면 도움
2. 묶을 함수 중 하나를 골라 본문 코드를 변환 함수로 옮기고 처리 결과를 레코드에 새필드로 기록한다. 그리고 클라이언트 코드가 이 필드를 사용하도록 수정한다
   • 복잡하면 함수 추출하기부터 한다
3. 테스트한다
4. 나머지 관련 함수도 위 과정에 따라 처리

[rkaehdaos]

6.11 단계 쪼개기

배경

• 서로 다른 두 대상 한꺼번에 다루는 코드 ▶ 별개로 split 가능한 방법
• 코드 수정시 두 대상을 동시에 생각할 필요가 없이 하나에만 집중하기 위해
• 분리가 잘되어 있다면 다른 모델 생각안해도 수정이 끝마쳐질 수 있다

분리의 가장 간편한 방법 : 한 스텝을 연이은 스텝 2개로 쪼개기

• 컴파일러
• 컴파일 작업이 여러 단계로 분리되면 좋다는 걸 사람들이 알았다
• 토큰화> 파싱> 쿠문트리 생성> 최적화> 구문 처리 등등등 >>>> 목적 코드 생성
• 각 단계는 자신만의 문제에 집중, 나머지에 대해 몰라도 이해 가능

SW 규모에 상관없이 여러 스텝으로 분리하면 좋을때마다 단계 쪼개기 해보자

[rkaehdaos]

절차

1. 2개로 쪼갠 스텝에서 뒷단계에 해당하는 코드를 독립함수로 추출한다
2. 테스트한다
3. 중간 데이터 구조를 만들어서 앞에서 추출한 함수의 인수로 추가한다
4. 테스트한다
5. 추출한 2번째 단계 함수의 매개변수를 하나씩 검토해서 첫번째 단계에사용되는것은 중 중간 데이터 구조로 옮긴다. 하나씩 옮길때마다 테스트한다
   • 간혹 2번째 단계에서 사용하면 안되는 매개변수가 존재한다. 이럴때는
   • 각 매개변수를 사용한 결과를 준간 데이터 구조의 필드로 추출하고
   • 이 필드의 값을 설정하는 문장을 호출하는 곳으로 옮긴다
6. 첫번째 단계 코드를 함수로 추출하면서 중간 데이터 구조를 반환하도록 한다
   • 이때 첫번째 단계를 변환함수 객체로 추출해도 좋다

[rkaehdaos]

위 코드는 두단계로 이뤄지고 있음

• 앞은 상품 정보를 이용해서 상품 가격 계산
• 뒤는 배송정보를 이용해 결제 금액중 배송비를 계산
• 두 단계로 나눠놓으면 나중에 비교적 서로 독립적으로 처리 가능하다.

[rkaehdaos]

shippingMethod 1 step에서 사용하지 않으므로 그대로 둔다

quantity

• 1step에서 사용하나 거기서 생성된 것은 아니다
• 따라서 매개변수로 놔둬도 된다
• 마틴파울러는 최대한 중간 데이터 구조에 담는 걸 선호
• 이 매개변수도 옮긴다

discount

• 1step에서 생성됨
• 중간데이터로 옮긴다

[rkaehdaos]

현재 코드의 2가지 일

1. 주문목록을 읽어서 카운팅
2. 명령줄 인수를 담은 배열을 읽어서 프로그램 동작 결정 → 리팩터링 대상으로 적합 → 분리하면 프로그램에서 지정할 수 있는 옵션/스위치가 늘어나도 수정 원할

[rkaehdaos]

단계 쪼개기와 상관없는 작업

• 자바 명령줄 프로그램은 테스트가 어렵다
• 매번 JVM 구동 → 느리고 복잡
• 일반적인 JUnit 호출로 자바 프로세스 하나에서 테스트 할 수 있는 상태로 만들어야

first

• 핵심 작업을 수행하는 코드 전부를 함수로 추출한다

[rkaehdaos]

run() 은 기본 package 접근 범위 → 테스트 코드에서 쉽게 호출 위해

결과를 받으려면 표준 출력으로 보내는 방식을 수정해야 한다

System.out문장을 호출한 곳으로 옮겨[8.4] 해결한다

[rkaehdaos]

위 단계 작업은 리팩터링시 중요하다

• 테스트가 느리거나 불편? → 리팩터링 속도가 느려지고 오류 발생 확율 커짐
• 테스트를 쉽게 수행할 수 있도록 수정 후 리팩터링 하는게 좋다
• 이 원칙을 흔히 험블 객체 패턴(Humble Object Pattern) 이라고 한다

  https://martinfowler.com/books/meszaros.html

이제 제대로 된 단계 쪼개기 준비 끝

[rkaehdaos]

args

• 1step에서 사용
• 2step에 노출하는 것이 적절치 않음
• 지금 단계 쪼개기 하는 목적이 args를 사용하는 부분을 모두 1step으로 하는 부분

args 추출을 위해 가장 먼저 할일

• 이 값을 사용하는 부분을 찾아 그 결과를 추출하는 것
• 2step에서는 한번, ready 주문 셀때만 사용
• 그러면 이 조건식을 변수로 추출한다

[rkaehdaos]

이 조건식 추출 값을 중간 데이터 구조로 옮긴다

[rkaehdaos]

다른 방법

• 중간 데이터 구조 대신

• 명령어 인수를 담은 문자열 배열을 2step에 적합한 인터페이스로 바꿔주는 변환기(transformer)객체를 만들어도 된다

  private static class CommandLine {
      String[] args;
  
      public CommandLine(String[] args) {
          this.args = args;
          if (args.length == 0) throw new RuntimeException("파일명을 입력하세요");
      }
      String filename(){
          return args[args.length - 1];
      }
      boolean onlyCountReady(){
          return Stream.of(args).anyMatch(arg -> "-r".equals(arg));
      }
  }
  }

[rkaehdaos]

둘중에 어떤거?

• 마틴파울러 이런 단순한 객체는 사용꺼리는 편
• 이 예시처럼 숮차적으로 실행되는 두 함수 사이의 단순 통신용으로 사용?
• 이렇게 제한된 문맥에서만 사용한다면 개의치 않는다
• 두 방식 모두 장단점
• 핵심은 어디까지나 단계를 명확히 분리하는데 있음

[rkaehdaos]