ch09

⬅️ 8장 | 10장 ➡️

9장 데이터 조직화

• 9.1 변수 쪼개기
• 9.2 필드 이름 비꾸기
• 9.3 파생 변수를 질의 함수로 바꾸기
• 9.4 참조를 값으로 바꾸기
• 9.5 값을 참조로 바꾸기
• 9.6 매직 리터럴 바꾸기

Note

'데이터 조직화' 챕터는 다음 질문을 중심으로 읽어나가시면 좋습니다.

1. 어떤 경우에 데이터를 쪼개야 하는가
2. 가변 데이터의 유효 범위를 어떻게 줄일 수 있는가
3. 데이터를 참조로 다뤄야 하는가 값으로 다뤄야 하는가

p.329

데이터 구조에 집중한 리팩터링

하나의 값이 여러 목적으로 사용된다면 혼란과 버그를 낳는다. 그러니 이런 코드를 발견하면 변수 쪼개기를 적용해 용도별로 분리하자.

참조^reference인지 값^value인지가 헷갈려 문제가 되는 코드도 자주 볼 수 있는데, 둘 사이를 전환할 때는 참조를 값으로 바꾸기와 값을 참조로 바꾸기를 사용한다.

9.1 변수 쪼개기

p.330

대입이 두 번 이상 이뤄진다면 여러 가지 역할을 수행한다는 신호다. 역할이 둘 이상인 변수가 있다면 쪼개야 한다.

역할 하나당 변수 하나다.

p.331

acc 변수에 값이 두 번 대입된다는 점이다.

function distanceTravelled(scenario, time) {
  let result;
- let acc = scenario.primaryForce / scenario.mass; // 가속도(a) = 힘(F) / 질량(m)
  let primaryTime = Math.min(time, scenario.delay);
  result = 0.5 * acc * primaryTime * primaryTime; // 전파된 거리
  let secondaryTime = time - scenario.delay;
  // 두 번째 힘을 반영해 다시 계산
  if (secondaryTime > 0) {
    let primaryVelocity = acc * scenario.delay;
-   acc = (scenario.primaryForce + scenario.secondaryForce) / scenario.mass;
    result +=
      primaryVelocity * secondaryTime +
      0.5 * acc * secondaryTime * secondaryTime;
  }
  return result;
}

1. 변수에 새로운 이름을 지어주고
2. 선언 시 const를 붙여 불변으로 만든다.
3. 그런 다음 두 번째 대입 전까지의 모든 참조를 새로운 이름으로 바꾼다.
4. 그리고 두 번째로 대입할 때 변수를 다시 선언한다.

p.333

사실 어떤 변수를 써도 똑같이 동작하지만, 이 코드가 입력 값에 기초하여 결과값을 누적해 계산한다는 사실을 더 명확히 드러낸 것이다. (코드)

9.2 필드 이름 비꾸기

p.334

프로그램 곳곳에서 쓰이는 레코드 구조체의 필드 이름들은 특히 더 중요하다. 데이터 구조는 프로그램을 이해하는 데 큰 역할을 한다.

다른 요소와 마찬가지로 개발을 진행할수록 데이터를 더 잘 이해하게 된다. 따라서 그 깊어진 이해를 프로그램에 반드시 반영해야 한다.

9.3 파생 변수를 질의 함수로 바꾸기

p.338

그렇다고 가변 데이터를 완전히 배제하기란 현실적으로 불가능할 때가 많지만, 가변 데이터의 유효 범위를 가능한 한 좁혀야 한다고 힘주어 주장해본다.

계산 과정을 보여주는 코드 자체가 데이터의 의미를 더 분명히 드러내는 경우도 자주 있으며 변경된 값을 깜빡하고 결과 변수에 반영하지 않는 실수를 막아준다.

여기에는 합당한 예외가 있다. 피연산자 데이터가 불변이라면 계산 결과도 일정하므로 역시 불변으로 만들 수 있다. 그래서 새로운 데이터 구조를 생성하는 변형 연산^{transformation operation}이라면 비록 계산 코드로 대체할 수 있더라도 그대로 두는 것도 좋다.

9.4 참조를 값으로 바꾸기

p.343

필드를 값으로 다룬다면 내부 객체의 클래스를 수정하여 값 객체^{Value Object}로 만들 수 있다. 값 객체는 대체로 자유롭게 활용하기 좋은데, 특히 불변이기 때문이다.

p.344

그래서 값 객체는 분산 시스템과 동시성 시스템에서 특히 유용하다.

p.346

이 테스트의 핵심은 독립된 객체를 두 개 생성하여 동치성 검사를 수행했다는 점이다.

💡 의견

참조를 복사해야 하는 일이 있었는데, JSON.stringify와 JSON.parse를 순차적으로 실행해서 참조를 값으로 바꿨다.

9.5 값을 참조로 바꾸기

p.347

논리적으로 같은 데이터를 물리적으로 복제해 사용할 때 가장 크게 문제가 되는 상황은 그 데이터를 갱신해야 할 때다. 모든 복제본을 찾아서 빠짐없이 갱신해야 하며, 하나라도 놓치면 데이터 일관성이 깨져버린다. 이런 상황이라면 복제된 데이터들을 모두 참조로 바꿔주는 게 좋다.

p.348

값을 참조로 바꾸면 엔티티^entity 하나당 객체도 단 하나만 존재하게 되는데, 그러면 보통 이런 객체들은 한데 모아놓고 클라이언트들의 접근을 관리해주는 일종의 저장소가 필요해진다.

p.349

객체를 어디에 저장해야 할지는 애플리케이션에 따라 다르겠지만, 간단한 상황이라면 나는 저장소 객체^{repository object}를 사용하는 편이다.

💡 의견

저장소 객체라는 것이 전역 store와 비슷하게 느껴졌다.

9.6 매직 리터럴 바꾸기

p.351

하지만 코드를 읽는 사람이 이 값의 의미를 모른다면 숫자 자체로는 의미를 명확히 알려주지 못하므로 매직 리터럴이라 할 수 있다. 의미를 알고 있다고 해도 결국 각자의 머리에서 해석해낸 것일 뿐이라서, 이보다는 코드 자체가 뜻을 분명하게 드러내는 게 좋다. 상수를 정의하고 숫자 대신 상수를 사용하도록 바꾸면 될 것이다.

일반적으로 해당 값이 쓰이는 모든 곳을 적절한 이름의 상수로 바꿔주는 방법이 가장 좋다.

예컨데 나는 aValue === "M"을 aValue === MALE_GENDER로 바꾸기보다 isMale(aValue)라는 함수 호출로 바꾸는 쪽을 선호한다.

p.352

방법

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

⬅️ 8장 | ⬆️ 위로 | 10장 ➡️