9. 데이터 조직화

[rkaehdaos]

데이터 구조 → 프로그램에서 중요한 역할 수행 → 데이터 구조에 집중한 리팩터링의 묶음

• 하나의 값이 여러 목적으로 사용되면??

  • 혼란과 버그를 낳는다
  • 이런 코드를 발견하면 [변수 쪼개기]를 적용해 용도별로 분리한다

• 다른 프로그램 요소와 마찬가지로 변수 이름을 제대로 짓는 일은 까다로우면서도 중요하다

  • [변수 이름 바꾸기]와 반드시 친해지자
  • 때로는 [파생변수를 질의 함수로 바꾸기]를 활용하여 변수 자체를 완전히 없애는게 좋은 해법

• ref인지 value인지 햇갈려 문제가 되는 코드

  • [참조를 값으로 바꾸기]
  • [값을 참조로 바꾸기] 사용

• 코드에 의미를 알기 어려운 리터럴? 매직 리터럴 바꾸기로 명확하게!

차례

• [x] 변수 쪼개기
• [x] 필드 이름 바꾸기
• [x] 파생 변수를 질의 함수로 바꾸기
• [x] 참조를 값으로 바꾸기
• [x] 값을 참조로 바꾸기
• [x] 매직 리터럴 바꾸기

[rkaehdaos]

9.1 변수 쪼개기 - Split Variable

왼쪽에서 존재하던 가변 데이터가 사라짐

배경

변수의 용도 : 다양

• 변수에 값을 여러번 대입할 수밖에 없는 경우
  • 루프 변수(Loop Variable) : 반복문을 한 번 돌 때마다 값이 바뀐다
  • 수집 변수(Collecting variable) : 메서드가 동작하는 중간중간 값을 저장
• 긴 코드의 결과를 저장했다가 나중에 쉽게 참조하려는 목적
  • 이런 변수에는 단 한번만 값이 대입되어야 한다
  • 2번 이상의 대입? → 여러 가지 역할을 수행한다는 신호 → 쪼개야 한다(예외없이)
  • 역할 하나당 변수 하나
  • 여러 역할로 쓰인 변수는 독자에게 큰 혼란을 준다

변수 추출하기[6-3]와 비교 : → 목적이 다르다

• 유사점 : 중간 단계에 사용되는 변수를 추가
• 차이점:
  • 추출하기 : 표현식을 변수로 추출
  • 쪼개기 : 여러번 사용되는 한 변수를 여러 변수로 쪼갠 것 , 변수 하다당 역할 하나를 갖도록 강제화

재성님이 하셨던 문장슬라이드 8-6

const pricingPlan = retrievePricingPlan();
const order = retrieveOrder();
const baseCharge = pricingPlan.base;
let charge;
const chargePerUnit = pricingPlan.unit;
const units = order.units;
let discount;
charge = baseCharge + units * chargePerUnit; // charge 첫 대입
let discountTableUnits = Math.max(units - pricingPlan.discountThreshold, 0);
discount = discountTableUnits * pricingPlan.discountFactor;
if (order.isRepeat) discount += 20;
charge = charge - discount;  // charge 두 번째 대입 , 다른 의미, discountCharge등의 다른 변수로 쪼개기
chargeOrder(charge);

절차

1. 변수를 선언한 곳과 값을 처음 대입하는 곳에서 변수 이름을 바꾼다
   • 이후의 대입이 항상 i=i+<무언가>형태라면? → 수집변수 → 쪼개면 안된다
   • 수집 변수 : 총합 계산, 문자열 연결, 스트림에 쓰기, 컬렉션에 추가하기등의 용도로 흔히 쓰인다
2. 가능하면 불변으로 선언한다
3. 이 변수에 2번째로 값을 대입하는 모든 참조를 새로운 변수명으로 바꾼다
4. 2번째 대입시 변수를 원래 이름으로 다시 선언
5. 테스트
6. 반복

악취

• 3.6 가변 데이터 악취
• 책 : 하나의 변수에 용도가 다른 값들을 저장하느라 값을 갱신하는 경우라면 [변수 쪼개기 9.1]를 이용해서 용도별로 독립 변수에 저장하게 하여 값 갱신이 문제를 일으킬 여지를 없앤다

[rkaehdaos]

예시

• 해기스 의 전파된 거리를 구하는 코드

  haggis 양의 내장으로 만든 스코틀랜드 음식, 순대와 비슷

• 초기 : 발상지에서 초기 힘을 받아 일정 가속도

• 시간이 흐른후 2번쨰 힘을 받아 전파속도가 빨라진다고 가정

• 일반적인 물리 법칙을 적용

포인트

acc 변수에 값이 2번 대입된다

1. 첫번째 힘이 유발한 초기 가속도
2. 2번째 힘까지 반영된 후의 가속도를 저장하는 함수
3. 쪼개야 한다

함수나 파일에서 특정 심벌이 쓰인 위치를 시각적으로 강조해주는 코드 편집기를 사용하면 도움이 된다

[rkaehdaos]

변수쪼개기 예시2

function discount(inputValue, quantity) {
    if (inputValue > 50) inputValue = inputValue - 2;
    if (quantity > 100) inputValue = inputValue - 1;
    return inputValue;
}

• 함수에 데이터 전달하는 용도, 결과를 반환하는 용도로 쓰임
• 자바스크립트는 값에 의한 호출 방식이므로 호출자에 영향을 주지 않는다

[rkaehdaos]

9-2 필드 이름 바꾸기 - Rename Field

6-7 변수 이름 바꾸기와 유사하지만 클래스의 필드 변수에 한한 케이스라는 것이 차이점

악취

• 3.1 기이한 이름 악취

배경

이름은 중요하다, 레코드 구조체의 필드 이름은 특히 더 중요하다

• 데이터 구조는 프로그램 이해에 큰 도움
• 데이터 구조가 중요한 만큼 반드시 깔끔하게 관리해야 한다

개발을 진행하면서 깊어진 데이터 이해도를 프로그램에 반드시 반영해야 한다

• 그 과정에서 레코드 필드 이름 수정 필요
• getter/setter→클래스 사용자 입장에서는 필드와 마찬가지 → getter/setter이름 바꾸기도 똑같이 중요하다

절차

1. 레코드 유효범위 제한적?→ 필드 접근하는 모든 접근하는 모든 코드 수정 후 테스트 (종료)
2. 레코드 캡슐화가 되어있는지 확인 →되어있지 않다면 [레코드 캡슐화7.1]
3. 캡슐화된 객체 안의 private 필드명 변경, 그에 맞게 내부 메서드들 수정
4. 테스트
5. 생성자의 매개변수 중 필드와 이름이 겹치는 게 있다면? [함수 선언 바꾸기 6.5]로 변경
6. 접근자들 이름 바꿔준다[6.5]

예시

• const organization = {name: "애크미 구스베리", country: "GB"}
• 7-1 레코드 캡슐화 하기 나온 예시를 . 하나 바꾸지 않고 똑같은 예시를 들었다
• 아무래도 레코드 캡슐화 하기 포함한 모든 절차를 다 보여주기 위해서

[rkaehdaos]

예시에서

• name을 title로 바꾸고 싶음
• 이 객체는 코드 베이스 곳곳에서 사용되며 그중 이 제목을 변경하는 곳도 있음 :
• 즉 1번에는 맞지 않음
• 2번 적용 : 레코드 클래스 캡슐화[7.1]

[rkaehdaos]

레코드 캡슐하니 ??

이름 변경할 곳이 4곳

• getter
• setter
• 생성자
• 내부 데이터 구조
• 일을 더 키워버린건가? 아니다. 더쉬워짐
  • 이전에는 모든 변경을 한 번에 수행해야 함
  • 이제는 작은 단계로 나누어 독립적으로 수행 가능
  • 작은 단계 → 각 단계에서 잘못될 일이 적어짐 → 할일도 줄어들었다

입력데이터 구조를 내부 데이터 구조로 복제했으므로 둘을 구분해야 독립적으로 작업할 수 있다 → 별도 필드를 정의하고 생성자/접근자에서 둘을 구분해서 사용하도록 해야 한다

[rkaehdaos]

정리

• 위의 과정 : 널리 참조되는 데이터 구조일때 적용되는 가장 복잡한 형태 (모든 절차)
• 한 함수안에서만 쓰였다면? 캡슐화 할 필요없이 그저 원하는 속성들의 이름을 바꿔주는 것으로 종료
• 상황에 맞게 전체 과정 적용 여부 판단 필요
• 리팩터링 도중 테스트에 실패하면 더 작은 단계로 진행해야하는 신호

데이터 구조를 불변으로 만들 수 있는 프로그래밍 언어 사용시

• 캡슐화 대신 데이터 구조의 값을 복제한 불변 데이터 구조를 만들고 새로운 이름으로 선언
• 사용하는 곳을 하나씩 새데이터를 사용하도록 수정
• 마지막으로 원래의 데이터 구조 제거
• 가변 데이터 구조 사용?→ 데이터 복제 행위가 재앙으로 이어질 수 있음 → 불변을 널리 쓰이게 되는 이유이기도 함

[rkaehdaos]

9.3 파생 변수를 질의 함수로 바꾸기 - Replace Derived Variable with Query

7-4 임시 변수를 질의 함수로 바꾸기와 유사(과정이), 목적은 다름

파생 변수

• 2 개(또는 그 이상)의 기본 변수에서 파생된 변수
• 백분율, 비율, 지수, 비율
• 기본 변수에 의존하므로 기본 변수중 하나 이상의 변경으로 파생 변수의 변경 발생 가능하지만 갱신이 안됨
• 문제를 일으킬 수 있음
• 질의함수 재정의 필요 : (값이 필요할 떄 다른 변수 값으로부터 계산하는)사용.

만약 discount setter가 없었으면 바꿀 필요가 없다

또다른 차이점 : 목적

• 임시변수 기법 : 스코프 확대 의도(함수 스코프에서 클래스 스코프로)
• 파생변수는 이미 클래스 스코프에 존재

배경

가변 데이터의 문제

• SW 문제 일으키는 가장 큰 골칫거리 중 하나

• 서로 다른 두 코드를 이상한 방식으로 결합할 수도

  • ex) 한쪽 코드 수정 값 → 연쇄 효과 →다른 쪽 코드에 (원인을 찾기 어려운) 문제 발생

• 가변 데이터를 완전히 배제하기? → 현실적으로 불가능

• 마틴 파울러의 목소리 : 가변 데이터의 유효 범위를 가능한 좁혀야 한다

  • 효과가 좋은 방법이다 → 값을 쉽게 계산 가능한 변수들을 모두 제거 가능
  • 계산 과정을 보여주는 코드 자체가 데이터 의미를 더 분명히 드러내는 경우도 자주 있다 (반대로 그렇지 않은 경우에는 해당 변수를 제거 하지 않아야)
  • 변경된 값을 깜빡하고 결과 변수에 반영하지 않는 실수를 막아준다

• 합당한 예외

  • 변형 연산(transformation operation) : 새로운 데이터 구조를 생성
    • 불변 사용 → 일정한 계산 결과 → 계산 결과도 불변으로 만들 수 있음
    • 계산 코드로 대체할 수 있더라도 그대로 두는 것도 좋다
    • 변형 연산의 종류 : 2가지
      1. 데이터 구조를 감싸며 그 데이터에 기초하여 계산한 결과를 속성으로 제공하는 객체
      2. 데이터 구조를 받아서 다른 데이터 구조로 변환해서 반환하는 함수 → 가변 소스 데이터, 파생 데이터 구조 수명 관리 필요 →객체 사용이 확실히 유리 → 불변 소스 데이터, 파생 데이터 임시 사용 → 어떤 방식도 무방

절차

1. 변수 값이 갱신 되는 지점을 모두 찾는다 → 필요 시 [변수 쪼개기 9.1]을 활용해서 각 갱신 지점에서 변수를 모두 분리
2. 해당 변수의 값을 계산해주는 함수를 만든다
3. 해당 변수가 사용되는 모든 곳에 어셔션 추가하여 함수 계산 결과가 변수의 값과 같은지 확인 → 필요하면 변수 캡슐화하기를 적용해서 어셔션이 들어갈 장소를 마련한다
4. 테스트
5. 변수를 읽는 코드를 모두 함수 호출로 대체한다
6. 테스트
7. 변수를 선언하고 갱신하는 코드를 [죽은 코드 제거하기 8.9]로 없앤다

악취

• 3.6 가변데이터 악취

예시

작지만 확실하고 보기 흉한 예

[rkaehdaos]

중복?

class ProductionPlan {
    constructor() {
        this._adjustments = [];
        this._production = 0;
    }

    get production() {return this._production;}

    applyAdjustment(anAdjustment) {
        this._adjustments.push(anAdjustment)
        this._production += anAdjustment.amount
    }
}

일반적인 코드 중복이 아닌 데이터 중복

• 조정값 적용 메서드에서 직접 관련이 없는 누적값 production까지 갱신
• 이 누적값은 매번 갱신하지 않고도 계산할 수 있음

[rkaehdaos]

신중하게 어셔션을 추가해서 검증해보자

[rkaehdaos]

!!!!!!!!!!!!!! 처음부터

[rkaehdaos]

앞과 똑같은 어서션을 작성하면 초기값0이아니면 실패한다.

이 파생 데이터 대체할 방법 ? 간단

• 변수 쪼개기를 먼저 적용한다

[rkaehdaos]

책은 여기가 끝이지만 더 진행해보자

[rkaehdaos]

다만 이번에는 인라인하지 않고 속성으로 남겨두는게 좋다

• 그게 더 코드 이해도가 높기 때문

[rkaehdaos]

9-4 참조를 값으로 바꾸기 - Change Reference to Value

배경

• 중첩된 데이터 구조 : 내부 객체를 참조 혹은 값으로 취급할 수 있다
• 참조와 값의 차이 →내부 객체의 속성을 갱신하는 방식에서 가장 극명하게
  • 참조의 경우 : 내부 객체 유지한 채 그 객체의 속성을 갱신
  • 값으로 다루는 경우 : 새로운 속성을 담은 객체로 기존 내부 객체를 통째로 대체

VO

• 값 객체
• 필드를 값으로 다룬다면 내부 객체의 클래스를 수정하여 값 객체로 만들 수 있다
• 불변(immutable)
  • 자유롭게 활용하기 좋다
  • 프로그램 외부로 건네줘도 나중에 그 값이 나 몰래 바뀌어도 된다
  • 값을 복제해서 여러 곳에서 사용하더라도 서로의 참조 관리가 필요 없음
  • 분산 시스템, 동시성 시스템에서 특히 유용
• 이번 리팩터링 적용하면 안되는 상황 : 특정 객체를 여러 객체에서 공유하고자 할 때
  • VO의 위의 특성 때문
  • 공유 객체 값 변경 시 모든 관련 객체에게 알려줘야 한다면? 공유객체를 값 객체가 아닌 참조로 다뤄야

절차

1. 후보 클래스가 불변인지, 혹은 불변이 될 수 있는지 확인
2. 각각의 setter 하나씩 제거[11.7]
3. 이 값 객체 필드들을 사용하는 동치성 비교 메서드를 만든다
   • 대부분 언어는 이런 상황에 사용할 수 있도록 오버라이딩 가능한 동치성 비교 메서드 제공
   • 동치성 비교 메서드 오버라이드시 해시코드 생성 메서드도 함께 오버라이드 필요

     제 기억으로는 이펙티브 자바에도 아마 비슷한 내용이 있었던 것으로 기억

예시

• 사람 객체 : 생성 시점에는 전봐번호가 올바로 설정되지 않도록 짜여져있음

악취

• 3.6 가변 데이터

[rkaehdaos]

대부분의 OOP언어는 값 기반 동치성 비교를 위해 오버라이드 가능한 동치성 검사 수단 기본 제공

• Ruby : ==연산자 오버라이드
• Java : Object.equals() 오버라이드

동치성 검사 메서드(equals)를 오버라이드 할 때는 해시코드 생성 메서드도 함께 오버라이드

• Java : `Object.hashCode() 메서드

  jdk의 List 해시 코드 - 이펙티브 자바 : 매직넘버 31 HashMap : CLRS 나눗셈 방법 롬복 : 예전 277 사용, 현재 59 사용

[rkaehdaos]

9.5 값을 참조로 바꾸기 - Change Value to Reference

앞의 reverse, 앞의 것의 배경과 같이 연관해서 생각해보자

배경

• 역시 앞의 상황과 같은 상황 - 객체를 참조 혹은 값으로 취급할 수 있다
• 갱신하지 않고 읽기만 한다면 어떤 방식이든 상관 없음
• 복사본이 많은 경우 : 메모리가 가끔 부족할 수 있지만 다른 성능 이슈와 마찬가지로 드물다
• 복사본 사용 시 문제가 되는 상황 : 데이터 갱신 필요할 때
  • 모든 복제본을 찾아서 전부 갱신할 필요
  • 하나라도 빠지면 데이터 일관성 깨짐
  • 이런 상황이라면 복제된 데이터들을 모두 참조로 바꿔주는 게 좋다
  • 참조인 경우? 데이터가 하나 - 갱신된 내용이 호출되는 부분에 곧바로 반영되기 때문

값을 참조로 바꾸면 엔티티 하나당 객체도 단 하나만 존재

가변 데이터 악취

• 참조에는 반드시 가변 데이터 악취의 문제가 발생
• 특히 한 객체가 여러 장소에서 사용될 때
• 예) id 777인 Customer의 객체가 여러 곳에서 사용되기
• Value 객체인 경우엔 애초에 각자가 별개이므로 상관없음
• 그러면 이런 객체들을 한대 모아놓고 클라이언트들의 접근 관리해주는 일종의 저장소가 필요하다
• 저장소로 객체들을 캡슐화
• 저장소로만 객체들 접근

• 각 엔티티를 표현하는 객체를 한 번만 만들고 필요한 곳에서는 모두 이 저장소에서 얻어 쓰는 형태

최근에 말하는 엔티티 : 도메인 모델의 엔티티 : 따라서 도메인 모델의 Entity VS Value객체로 구분해서 생각 엔티티 : 실체, 객체라는 의미, 식별자를 가진다 DB의 엔티티 : 실제로 SQL, DB에 존재하는 것이 아닌 일종의 개념 DB에서 엔티티는 논리 모델에서 사용, 테이블은 물리 모델에서 사용, 테이블은 DB, SQL에 실제로 존재, 물리적 구조

DTO VS VO

• VO는 위에서 봤듯이 불변, read-only 특징, 값 자체를 의미→따라서 같은 객체 보장을 위해 equals, hashcode를 재정의해줘야 한다
• DTO : 레이어간 데이터 전소응ㄹ 위해 정의된 객체 : 주로 json 직렬화등 직렬화에 사용되는 객체
• DTO는 원래 DAO 패턴에서 유래 : DAO에서 DB 처리 로직을 숨기고 DTO값을 내보내는 용도로 활용
• 현재는 거의 DTO는 엔티티를 프레젠테이션 단까지 내보내지 않기 위해 쓰이는 , 다 내보낼 필요도 없고
• DTO : getter/setter만을 가지고 비지니스 포함X
• 둘의 차이 개념상의 차이 : 값 자체에 의미가 있는 VO, 전달된 데이터보존의DTO
• VO는 setter가 없음 : 불변, readonly가 보장되어야 존재 자체의 신뢰성 확보

[rkaehdaos]

절차

1. 같은 부류에 속하는 객체들을 보관할 저장소를 만든다 (이미 있다면 생략)
2. 생성자에서 이 부류의 객체들 중 특정 객체를 정확히 찾아내는 방법이 있는지 확인
3. 호스트 객체의 생성자들 수정해서 필요한 객체를 이 저장소에서 찾도록 한다.

[rkaehdaos]

예시

주문 클래스

• 주문 데이터를 생성자에서 JSON입력받아 필드를 채운다
• 그 과정 중에 주문 데이터에 포함된 고객 ID를 사용해 고객 객체 생성

[rkaehdaos]

현재 고객이 값 객체

• 따라서 수정하더라도 바뀌지 않는다
• 이 경우 나머지 객체 모두를 같은 값 갱신 필요

엔티티 표현 객체가 여러개 만들면 혼란

• 불변이 아니라면? 일관성 깨질 수 있음 - 더 까다로움

[rkaehdaos]

step 1 - 저장소 객체

• 항상 물리적으로 똑같은 고객 객체 사용 원한다면? 유일한 객체를 저장해야 할 곳이 있어야 한다
• 객체를 어디에 저장해야하는가는 어플리케이션에 따라 다르다
• 마틴파울러 : 간단한 상황이라면 저장소 객체(repository object) 사용하는 편

리포지토리 패턴

• P of EAA [2002] : https://www.martinfowler.com/eaaCatalog/repository.html
• 
• 
• - 2015 재출간

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. - Edward Hieatt and Rob Mee 도메인 객체에 접근하는 컬렉션과 비슷한 인터페이스를 사용해 도메인과 데이터 매핑 계층 사이를 중재한다 - 에드워드 하얏트, 롭 미 리포지토리에 의해 캡슐화되는 매핑 코드가 적절한 작업을 내부적으로 처리 데이터 저장소에 저장된 객체의 집합과 이를 대상으로 수행하는 작업을 개념상으로 캡슐화해 지속적 계층에 대한 좀 더 객체 지향적 관점을 제공한다

• 데이터 출처에 상관없이 돌일 인터페이스로 데이터에 엑세스 가능 - DataSource캡슐화
• 책에서는 이 앞에서 데이터 매퍼 패턴(도메인 객체를 DB 접근 상세로부터 격리하기 위해)을 소개 했는데 복잡한 도메인 모델의 경우 쿼리 구성 코드가 집중되는 매핑 계층을 기반으로 다른 추상 계층을 만듬 - 레포지토리 계층
• 도메인은 하위에 상관없이 레포지토리만 바라봄
• 레포지토리 교체로 단위테스트를 통한 검증 가능

[rkaehdaos]

step2 : 주문의 생성자에서 올바른 고객 객체를 얻어오는 방법 : 여기서는 고객ID가 입력 데이터 스트림으로 전달 되서 해결

[rkaehdaos]

이제 특정 주문과 관련된 고객 정보를 갱신하면 같은 고객을 공유하는 주문 모두에서 갱신된 데이터 사용

예시 문제점

• 생성자 본문이 전역 저장소와 결합
• 저장소를 생성자 주입으로 DI받아 사용하도록 수정하자

[rkaehdaos]

9.6 매직 리터럴 바꾸기 - Replace Magic Literal

배경

• magic literal : 소스 코드에 (보통 여러 곳에)등장하는 일반적인 리터럴 값

  상수 와 리터럴

  • 둘 다 변하지 않는 값
  • 상수 : 변하지 않는 변수 → 메모리 위치
  • 리터럴 : 데이터 그 자체, 변수나 상수에 넣는 변하지 않는 데이터 → 메모리 위치 안의 값
  • 불변 클래스의 경운(immutable, VO) : 리터럴이라고 할 수 있고 객체 리터럴이라고 따로 칭하기도 한다

매직넘버, 매직리터럴

• 프로그래밍에서 비지니스적 의미를 가진 숫자,문자를 그대로 표현한 것

• int maxStudents = numClassrooms * 30; → 매직 리터럴 30 → 교실 당 최대 학생 수를 의미한다는 것을 유추해야 한다

• 굉장히 나쁜 습관 → 무엇에 사용되는 지에 대한 컨텍스트가 없으며 나중에 값을 수정 시에도 문제가 된다

  예를 들어서 30→ 35로 바꿔야 하는데 이미 30이라는 다른 숫자들이 존재함.. replace를 할 수 없음

• 원주율(π) : 3.14159...

• 표준 중력, 중력가속도(g) : 9.80665 m/s2

• 독자가 리터럴 값의 의미를 모른다면? → 숫자 자체로는 의미를 명확히 알려주지 못함 → 매직리터럴

매직 리터럴은 대체로 숫자가 많지만 다른 타입의 리터럴도 특별한 의미를 지닐 수 있다

• 1월 1일 : 새로운 해의 시작
• M : 남성
• 서울 : 본사

솔루션 : 해당 값이 쓰이는 모든 곳을 적절한 이름의 상수로 바꿔주는 방법이 가장 좋다

• 그 상수가 특별한 비교 로직에 사용한다면? 함수 호출로 바꾸는 게 좋을 수도 있음
• 마틴 예시) aValue === "M" → aValue === MALE_GENDER <<<< jisMale(aValue)

상수를 과용하는 것을 자제하자

• ex) const ONE = 1 : 의미 없는 상수 선언 → 의미 전달 면에서 리터럴을 바로 쓰는 것보다 나을게 없다
• 리터럴이 함수 하나에서만 쓰이고 그 함수가 맥락 정보를 충분히 제공하여 헷갈릴 일이 없는 경우 → 상수로 바꿔 얻는 이득 감소

방법

1. 상수를 선언하고 매직 리터럴을 대입한다
2. 해당 리터럴이 사용되는 모든 곳을 모두 찾는다
3. 찾는 곳 각각에서 리터럴이 새 상수와 같은 의미로 쓰였는지 확인하여, 같은 의미라면 상수로 대체 후 테스트한다.