ch10

⬅️ 9장 | 11장 ➡️

10장 조건부 로직 간소화

• 10.1 조건문 분해하기
• 10.2 조건식 통합하기
• 10.3 중첩 조건문을 보호 구문으로 바꾸기
• 10.4 조건부 로직을 다형성으로 바꾸기
• 10.5 특이 케이스 추가하기
• 10.6 어서션 추가하기
• 10.7 제어 플래그를 탈출문으로 바꾸기

Note

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

1. 왜 조건의 의도가 드러나야 하는가
2. 어떻게 하면 조건의 의도가 드러나는가
3. 무엇을 통해 복잡한 조건을 분리하고 구조화할 수 있는가

10.1 조건문 분해하기

p. 354

조건을 검사하고 그 결과에 따른 동작을 표현한 코드는 무슨 일이 일어나는지는 이야기해주지만 '왜' 일어나는지는 제대로 말해주지 않을 때가 많은 것이 문제다.

거대한 코드 블록이 주어지면 코드를 부위별로 분해한 다음 해체된 코드 덩어리들을 각 덩어리의 의도를 살린 이름의 함수 호출로 바꿔주자. 그러면 전체적인 의도가 더 확실히 드러난다.

p. 356

모두 끝났다면 취향에 따라 전체 조건문을 3항 연산자로 바꿔줄 수도 있다.

charge = summer() ? summerCharge() : regularCharge();

function summer() {
  return !aDate.isBefore(plan.summerStart) && !aDate.isAfter(plan.summerEnd);
}

function summerCharge() {
  return quantity * plan.summerRate;
}

function regularCharge() {
  return quantity * plan.regularRate + plan.regularServiceCharge;
}

💡 의견

• 3항 연산자에 함수를 사용하는 부분이 인상적이었고 함수도 하나의 값이었지 하고 다시 한번 깨달았습니다.

10.2 조건식 통합하기

p. 357

첫째, 여러 조각으로 나뉜 조건들을 하나로 통합함으로써 내가 하려는 일이 더 명확해진다.

두 번째 이유는 이 작업이 함수 추출하기까지 이어질 가능성이 높기 때문이다.

함수 추출하기는 '무엇'을 하는지를 기술하던 코드를 '왜' 하는지를 말해주는 코드로 바꿔주는 효과적인 도구임을 기억하자.

p. 358

다시 말해 진짜로 독립된 검사들이라고 판단되면 이 리팩터링을 해서는 안 된다.

💡 의견

• 클린 코드에 따르면 if문 조건식에는 긍정문으로 적는 게 좋다고 합니다. 뇌 구조상 이해하기 쉽다고 하네요.

10.3 중첩 조건문을 보호 구문으로 바꾸기

p. 360

function getPayAmount() {
  if (isDead) return deadAmount();
  if (isSeparated) return separatedAmount();
  if (isRetired) return retiredAmount();
  return normalPayAmount();
}

💡 의견

• 열 번 듣는 것보다 한 번 보는 것이 더 낫다고 하는데 이 코드는 직관적이라 기억하기 쉬울 것 같습니다.

p. 361

두 번째 검사 형태를 흔히 보호 구문^{guard clause}이라고 한다.

이와 달리, 보호 구문은 "이건 이 함수의 핵심이 아니다. 이 일이 일어나면 무언가 조치를 취한 후 함수에서 빠져나온다"라고 이야기한다.

함수의 진입점과 반환점이 하나여야 한다고 배운 프로그래머와 일하다 보면 이 리팩터링을 자주 사용하게 된다. 진입점이 하나라는 조건은 최신 프로그래밍 언어에서는 강제된다. 그런데 반환점이 하나여야 한다는 규칙은, 정말이지 유용하지 않다. 코드에서는 명확함이 핵심이다. 반환점이 하나일 때 함수의 로직이 더 명백하다면 그렇게 하자. 그렇지 않다면 하지 말자.

p. 363

예시: 조건 반대로 만들기

<리팩터링 전>

function adjustedCapital(anInstrument) {
  let result = 0;
  if (anInstrument.capital > 0) {
    if (anInstrument.interestRate > 0 && anInstrument.duration > 0) {
      result =
        (anInstrument.income / anInstrument.duration) *
        anInstrument.adjustmentFactor;
    }
  }
  return result;
}

<리팩터링 후>

function adjustedCapital(anInstrument) {
  if (
    anInstrument.capital <= 0 ||
    anInstrument.interestRate <= 0 ||
    anInstrument.duration <= 0
  )
    return 0;
  return (
    (anInstrument.income / anInstrument.duration) *
    anInstrument.adjustmentFactor
  );
}

💡 의견

• 예시에서 AND 조건을 NOT으로 묶은 다음 다시 풀어서 통합하는 방식에 감탄했습니다.
• 실무에서 이런 중첩된 if문을 종종 만나는데 처리하는 과정이 인상 깊었습니다.

10.4 조건부 로직을 다형성으로 바꾸기

p. 367

타입을 여러 개 만들고 각 타입이 조건부 로직을 자신만의 방식으로 처리하도록 구성하는 방법이 있다.

기본 동작을 위한 case문과 그 변형 동작으로 구성된 로직을 떠올릴 수 있다.

다형성은 객체 지향 프로그래밍의 핵심이다. 하지만 (유용한 기능들이 늘 그렇듯) 남용하기 쉽다. 실제로 모든 조건부 로직을 다형성으로 대체해야 한다고 주장하는 사람도 만난 적이 있다. 나는 그 견해에는 동의하지 않는다. 조건부 로직 대부분은 기본 조건문인 if/else와 switch/case로 이뤄지기 때문이다. 하지만 앞서 이야기한 방법들로 개선할 수 있는 복잡한 조건부 로직을 발견하면 다형성이 막강한 도구임을 깨닫게 된다.

p. 375

예시: 변형 동작을 다형성으로 표현하기

💡 의견

• 이번 예시 코드는 실무에 가장 가까운 코드라 많은 도움이 된 것 같습니다.

p. 377

이 특수한 상황을 다루는 로직들을 기본 동작에서 분리하기 위해 상속과 다형성을 이용할 것이다. 다녀온 바 있는 중국으로의 항해 시 추가될 특별한 로직이 더 많았다면 이번 리팩터링의 효과가 더욱 컸겠지만, 지금 상황에서도 이 특수 상황을 검사하는 로직이 반복되어 기본 동작을 이해하는 데 방해가 되고 있다.

p. 379

그런 다음 적절한 변형 클래스를 반환해줄 팩터리 함수를 만든다.

💡 의견

• 팩터리 함수란 어떤 함수가 객체를 반환하는 함수를 뜻한다고 합니다. 이런 패턴도 있구나 하고 생각했습니다.

10.5 특이 케이스 추가하기

p. 388

이처럼 코드베이스에서 특정 값에 대해 똑같이 반응하는 코드가 여러 곳이라면 그 반응들을 한 데로 모으는 게 효율적이다.

특수한 경우의 공통 동작을 요소 하나에 모아서 사용하는 특이 케이스 패턴^{Special Case Pattern}이라는 것

특이 케이스는 여러 형태로 표현할 수 있다. 특이 케이스 객체에서 단순히 데이터를 읽기만 한다면 반환할 값들을 담은 리터럴 객체 형태로 준비하면 된다. 그 이상의 어떤 동작을 수행해야 한다면 필요한 메서드를 담은 객체를 생성하면 된다.

p. 389

이번 리팩터링의 대상이 될 속성을 담은 데이터 구조(혹은 클래스)에서 시작하자.

컨테이너를 사용하는 코드에서는 해당 속성이 특이한 값인지를 검사한다. 우리는 이 대상이 가질 수 있는 값 중 특별하게 다뤄야 할 값을 특이 케이스 클래스(혹은 데이터 구조)로 대체하고자 한다.

p. 391

UnknownCustomer를 Customer의 서브클래스로 만들지 않았음에 주목하자. 다른 언어, 특히 정적 타입 언어였다면 서브클래스로 만들었을 것이다. 하지만 자바스크립트의 서브클래스 규칙과 동적 타이핑 능력 덕분에 이 경우엔 지금 예처럼 만드는 편이 낫다.

💡 의견

• 덕 타이핑이라는 개념이 매력적으로 느껴졌습니다.
• 덕 타이핑이란 동적 타이핑의 한 종류이고 객체의 변수와 메소드의 집합이 객체의 타입을 결정하는 것이라고 합니다. "만약 어떤 새가 오리처럼 걷고, 헤엄치고, 꽥꽥거리는 소리를 낸다면 오리가 아닐 리 없다" 이런 비유를 들었습니다.
• 타입스크립트를 사용하는데 덕 타이핑 방식을 사용하지 않고 상속받을 때도 명시해서 표현하고 있습니다.

p. 398

예시: 변환 함수 이용하기

앞의 두 예는 모두 클래스와 관련 있지만, 변환 단계를 추가하면 같은 아이디어를 레코드에도 적용할 수 있다.

💡 의견

• 이전 예시와 다르게 함수로 리팩터링하는 과정을 보여주고 있는데 일부 프로퍼티만 반환하는 방식을 인상 깊게 봤습니다.

10.6 어서션 추가하기

p. 404

어서션은 항상 참이라고 가정하는 조건부 문장

어서션 실패는 시스템의 다른 부분에서는 절대 검사하지 않아야 하며, 어서션이 있고 없고가 프로그램 기능의 정상 동작에 아무런 영향을 주지 않도록 작성돼야 한다. 그래서 어서션을 컴파일타임에 켜고 끌 수 있는 스위치를 제공하는 프로그래밍 언어도 있다.

단위 테스트를 꾸준히 추가하여 사각을 좁히면 어서션보다 나을 때가 많다. 하지만 소통 측면에서는 어서션이 여전히 매력적이다.

p. 406

한편 어서션을 남발하는 것 역시 위험하다. 나는 참이라고 생각하는 가정 모두에 어서션을 달지는 않는다. '반드시 참이어야만 하는' 것만 검사한다.

💡 의견

• 실무에서 어서션을 많이 사용하는지 궁금한데요. 책을 보면 사용 시 주의사항이 덕지덕지 붙어있는 것 같고 실무 코드에서 어서션을 봤다는 분도 없는 것 같아서 최근에는 테스트 코드로 많이 대체되고 있나 싶기도 합니다.

10.7 제어 플래그를 탈출문으로 바꾸기

p. 407

제어 플래그란 코드의 동작을 변경하는 데 사용되는 변수를 말하며, 어딘가에서 값을 계산해 제어 플래그에 설정한 후 다른 어딘가의 조건문에서 검사하는 형태로 쓰인다.

함수에서 할 일을 다 마쳤다면 그 사실을 return문으로 명확히 알리는 편이 낫지 않을까?

p. 410

그리고 이 코드를 보고 있자니, 자바스크립트도 어서 다음과 같은 근사한 집합 연산을 지원해줬으면 하는 마음이 간절해진다.

['조커', '사루만'].isDisjointWith(people);

💡 의견

• 원래 코드보다 집합 연산을 쓴 위 코드가 참 깔끔한데요. 이런 함수가 있었으면 좋겠다고 생각했습니다.
• 자바스크립트 쓰면서 다른 언어에 있는 기능이 있으면 좋겠다고 생각한 적 있으신가요? 예를 들어, 자바스크립트에서는 입출력이 쉽지 않았던 경험이 있습니다.
• a[:3]처럼 슬라이스 문법이 있으면 좋겠다고 생각했어요.
• a[-1] 같은 문법도 있으면 좋겠어요. a.at(-1)을 쓰면 가능하다고 하는데 최신 문법이라 사용하지 못하는 경우도 있어요.
• 문자열을 배열처럼 다룰 수 있는 건 편해요. Java는 문자열을 다루기 어려워서 코딩 테스트 볼 때 문자열 관련 문제는 Java 말고 다른 언어로 푼다고 하시는 분도 있더라고요.
• 자바스크립트에서는 Array.length = 3과 같은 방식으로 배열에서 요소를 제거할 수도 있는데 다른 언어에서는 말도 안 되는 일인 경우도 있습니다.

⬅️ 9장 | ⬆️ 위로 | 11장 ➡️