📕 리팩터링 2판 리뷰: Intro, 1장

 

📕 리팩터링 2판 : 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기 리뷰

 

리팩터링 2판의 Intro와 1장을 읽고 왔습니다. 예시 코드가 많아서 그냥 훑어봐서는 금방 이해가 되지 않아 하나하나 타이핑하며 읽어봤더니 어느정도 이해가 되는 것 같습니다. 덕분에 읽는 시간은 조금 오래 걸렸습니다. 😅

나중에 제가 다시 찾아보기 쉽게끔 정리해봐야겠다 싶어 보기 쉽게 정리하며 공부중입니다. 그리고 원래는 책을 읽으면서 개인 토이 프로젝트의 리팩터링도 병행하려고 했는데, 시간이 조금 걸리겠지만 책을 끝까지 정독하고 진행하기로 마음을 돌렸습니다.

그럼 이제 각설하고, 리팩터링 2판의 Intro와 1장의 리뷰를 시작해보겠습니다. 

---

⭐️ Intro

Intro에서는 필자(마틴 파울러)가 컨설턴트로서 프로젝트 팀장에게 리팩터링을 권했으나 팀장이 이를 간과한 결과, 6개월 후 해당 프로젝트가 완전히 망했던 일화를 소개합니다. 리팩터링의 의의와 중요성에 대해 간단히 알아보는 챕터였습니다. 실무에서 리팩터링이 얼마나 중요한지 실제 사례를 통해 알 수 있었습니다.

 

⭐️ 1장 리팩터링: 첫번째 예시

1장에서는 아래의 예시 코드를 필자의 스타일로 리팩터링하는 것을 보며 리팩터링을 어떻게 수행하는지 감을 잡아보는 시간을 가집니다.

 

function statement(invoice, plays) {
  let totalAmount = 0;
  let volumeCredits = 0;
  let result = `청구 내역 (고객명: ${invoice.customer})\n`;
  const format = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD',
    minimumFractionDigits: 2,
  }).format;

  for (let perf of invoice.performances) {
    const play = plays[perf.playID];
    let thisAmount = 0;

    switch (play.type) {
      case 'tragedy': // 비극
        thisAmount = 40000;
        if (perf.audience > 30) {
          thisAmount += 1000 * (perf.audience - 30);
        }
        break;
      case 'comedy': // 희극
        thisAmount = 30000;
        if (perf.audience > 20) {
          thisAmount += 10000 + 500 * (perf.audience - 20);
        }
        thisAmount += 300 * perf.audience;
        break;
      default:
        throw new Error(`알 수 없는 장르: ${play.type}`);
    }

    // 포인트를 적립한다.
    volumeCredits += Math.max(perf.audience - 30, 0);

    // 희극 관객 5명마다 추가 포인트를 제공한다.
    if (play.type === 'comedy') volumeCredits += Math.floor(perf.audience / 5);

    // 청구 내역을 출력한다.
    result += `  ${play.name}: ${format(thisAmount / 100)} (${
      perf.audience
    }석)\n`;
    totalAmount += thisAmount;
  }
  result += `총액: ${format(totalAmount / 100)}\n`;
  result += `적립 포인트: ${volumeCredits}점\n`;
  return result;
}

 

 

초보자인 제가 예시 코드를 봤을 때 느낀 생각은 'statement() 함수가 너무 많은 기능을 수행하고 있는 것 같은데? 여기서 기능별로 쪼갤 수 있는 부분들만 쪼개주면 좋겠다.' 정도였습니다.

허나 필자는 위의 짧은 코드를 다양한 리팩터링 기법을 통해 전체적으로 보면 꽤 길어졌지만 매우 잘게 나뉜, 수정하기 쉬운 코드로 만들어냅니다. 생각보다 더 잘게 잘게 나눕니다. 중간에 나오는 얘기이지만 프로그래밍에서만큼은 간결함보다 명료함이 진화할 수 있는 소프트웨어의 정수라고 합니다. 리팩터링 과정을 따라가다보니 절로 고개가 끄덕여졌습니다. 

리팩터링을 진행하며 필자가 끝없이 강조한 것은 테스트였습니다. 테스트 코드를 작성하는 데는 시간이 좀 걸리지만, 신경 써서 만들어두면 디버깅 시간이 줄어 전체 작업 시간은 오히려 단축된다는 것입니다.

또한 하나의 리팩터링을 끝낼 때마다 커밋해야 중간에 문제가 생기더라도 이전의 정상 상태로 돌아갈 수 있다는 것을 얘기했습니다. 어느 정도 의미 있는 단위로 뭉쳐지면 공유저장소로 푸시한다고 합니다. 필자는 하나의 리팩터링이 끝날때마다 꼭 컴파일-테스트-커밋 의 과정을 반복합니다. 이 과정이 귀찮아서 소홀해지면 나중에 실수할 때 정신이 번쩍 든다고 합니다.

그 외에도 변수의 이름을 명확하게 하는 법, 모듈화하여 중복코드를 쓰지 않는 법 등등 실제 리팩터링 과정을 따라가보며 리팩터링이 어떤 것인지 감을 잡을 수 있는 좋은 시간이었습니다.

필자는 함수의 반환 값에는 항상 result라는 이름을 씁니다. 그러면 그 변수의 역할을 쉽게 알 수 있기 때문입니다.
인수인 perf는 aPerformance라고 바꿔주는 등 명확하게 바꿔줍니다. 필자는 매개변수 이름에 접두어로 타입이름을 적는데, 매개변수의 역할이 뚜렷하지 않을 때는 부정 관사(a/an)을 붙입니다.

 

---

 

🤔 느낀 점

리팩터링 과정을 보면서, 정말 강박적으로 프로그래밍한다면 이렇게까지 할 수 있구나 싶었습니다. 😳
물론 나쁜 의미가 아니라 좋은 의미입니다. 앞으로 개발할 때 단순히 기능만 잘 돌아가게 뚝딱뚝딱 만드는 것이 아니라, 미래의 유지보수비용을 줄이기 위해 현재의 시간을 리팩터링과 테스트에 꼭 투자해야 한다는 걸 몸소 느끼게 되었습니다. 의미는 다르지만 마치 어른들이 나중에 고생 안하려면 공부 열심히 하라는 말을 왜 하시는지 다 커서 알게 된 것과 비슷한 느낌이었네요..

당장 코드를 정리하는 것은 시간이 조금 걸렸지만, 완성된 코드를 보면 확실히 코드를 처음 볼 다른 팀원들이 볼 때도 수정하기 쉽게 바뀌었습니다. 필자의 말대로 처음부터 리팩터링의 개념만 알려준다면 리팩터링이 어떤 것이고, 왜 필요한지 느낌이 오지 않았을텐데 예시를 보면서 따라가다보니 명확해졌습니다.

다만 책을 보면서 조금 어려웠던 점은 필자의 리팩터링 기법을 자신만의 단어로 설명하는데, 나중에 나오는 내용들이라 단어만 보고서는 어떤 의미인지 이해하기 쉽지 않았네요. 그리고 테스트가 중요하다고 강조하는데 테스트 코드는 따로 나오지 않아 아쉬웠습니다. 매우 중요하여 4장에서 크게 다룬다고 하니 그 때 제대로 배워야겠습니다.

아무튼 2장에서는 리팩터링 전반에 적용되는 원칙들을 알아본다고 하는데 벌써부터 기대가 됩니다. 얼른 다 읽고 저 또한 좋은 코드를 작성할 수 있게 되면 좋겠네요.

끝으로 필자가 강조하면서도 제게 인상 깊었던 구문 몇가지를 공유하며 글을 마치겠습니다.

긴 글 읽어주셔서 감사합니다.

 

컴퓨터가 이해하는 코드는 바보도 작성할 수 있다.
사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다.

 

캠핑자들에게는 "도착했을 때보다 깔끔하게 정돈하고 떠난다"는 규칙이 있다.
프로그래밍도 마찬가지다. 항시 코드베이스를 작업 시작 전보다
건강하게(healthy) 만들어놓고 떠나야 한다.

좋은 코드를 가늠하는 확실한 방법은 '얼마나 수정하기 쉬운가' 다.

 

건강한 코드베이스는 생산성을 극대화하고,
고객에게 필요한 기능을 더 빠르고 저렴한 비용으로 제공하도록 해준다.

 

 

728x90