3주차: 6장 기본적인 리팩터링

[choisohyun]

인상깊었던 책의 내용과 인상깊었던 이유
현업 등 코드에 반영할 수 있는 방법과 생각
관련 아티클이나 이해를 돕는 자료를 첨부
새롭게 알게된 점이나 이해가 어려웠던 점

[blan19]

p.180. 좋은 이름을 떠올리는데 효과적인 방법이 하나 있다. 바로 주석을 이용해 함수의 목적을 설명해보는 것이다. 그러다 보면 주석이 멋진 이름으로 바뀌어 되돌아올 때가 있다.

나름 팀에서 함수 명을 작성하는 컨벤션이 있는 대도 복잡한 함수인 경우 이름을 고심할 때가 참 많았는데요, 그 함수의 목적을 다른 사람에게 설명해본다는 생각으로 정리해본다면 그게 좋은 이름으로 돌아 올 수 있겠구나라고 생각이 들었어요!

그리고 6장 전반적인 내용에서 평소 코드를 어떻게하면 더 간결하고 보기 좋게 짤까에 대한 고민을 하며 나름대로 답을 도출 해왔던 행동들이 리팩토링 6장에서 드문 드문 보였던게 나름 뿌듯했했습니다 xD

p190. 마지막으로, 나는 게터 이름 앞에 get을 붙이는 것을 싫어해서 get을 빼도록 하겠다.

저는 데이터를 가져오는 게터 함수는 앞에 prefix로 get을 붙이는 걸 선호했는데, 캡슐화된 공개가되지 않은 데이터에 대한 접근도 get을 붙이는게 더 낫지 않을까 라는 생각이 드네요

[RAINBOWJYP]

마틴 파울러가 게터 이름 앞에 'get' 붙는게 싫다고 했으니 저도 'get'을 앞으로 안쓰겠습니다.

읽으면서 머리로는 이해가 가는데 막상 실습하려고 책을 덮으니 어려웠습니다. 6.11 단계 쪼개기 책에 있는 예제로 실습했는데, 단계를 어떻게 쪼개라는거지? 싶었고 applyShipping에 전달되는 매개변수를 하나씩 옮기는데 shippingMethod는 왜 그대로 냅두는지 모르겠습니다... 앞 단계에서 사용하지 않아서 그런거겠지요? 많은 리팩터링 연습이 필요할 것 같습니다.

그리고 변수나 함수 이름을 바꾸는건 vscode에서 참조하고 있는 것들 전부 포함해서 일괄로 변경해줘서 쉽게 바꿀 수 있어서 잘 써먹고 있습니다. 하지만 이런 기능이 없었을 때를 생각하면 먼저 함수 전체를 복사한 뒤에 마이그레이션 절차로 하나하나 변경해가면서 문제는 없는지 테스트해나가는 과정이 필요했음을 알게되었습니다. 정말 참조하는게 많았더라면 이름 바꾸는 일은 선뜻 나서기 힘들었을 것 같아요.

[suojae]

1. 함수 파라미터에 대한 종속성도 생각해봐야한다는 것을 깨달았다.

// 아래함수는 aCustomer 타입에 종속되어있음
function inNewEngland(aCustomer) {
  return ["MA", "CT", "ME", "VT", "NH", "RI"].includes(aCustomer.address.state);
}

// 종속성 제거해주기
function inNewEngland(stateCode: string) {
  return ["MA", "CT", "ME", "VT", "NH", "RI"].includes(stateCode);
}

2. 변수에 대한 캡슐화해주기

// salary 는 Employee를 알고 있으면 아무나 와서 사용가능
class Employee {
  public salary: number;
}

// private 처리후 getter, setter로 제한해주기
class Employee {
  private _salary: number;

  constructor(salary: number) {
    this._salary = salary;
  }

  get salary(): number {
    return this._salary;
  }

  set salary(value: number) {
    this._salary = value;
  }
}

3. 함수에 여러 개의 관련된 데이터가 자주 함께 전달될 때, 하나의 객체로 묶어서 전달해주기

// 고객의 시작 날짜와 종료 날짜를 받아 사용 기간을 계산하는 함수
function calculateUsage(startDate: Date, endDate: Date): number {
  return (endDate.getTime() - startDate.getTime()) / (1000 * 60 * 60 * 24);
}

// DateRange 라는 객체로 묶어서 함수에 전달하면 코드의 명확성과 유지보수성을 높일 수 있다.
class DateRange {
  constructor(public startDate: Date, public endDate: Date) {}
}

function calculateUsage(dateRange: DateRange): number {
  return (dateRange.endDate.getTime() - dateRange.startDate.getTime()) / (1000 * 60 * 60 * 24);
}
const dateRange = new DateRange(new Date('2024-01-01'), new Date('2024-02-01'));
const usage = calculateUsage(dateRange);

어디까지 인라이닝하고 함수를 분리할지 기준에 대한 시니어 개발자분 의견.. : https://youtu.be/rbWSTXBYNFA?si=xtYmE3HNFaoH_PFW&t=643

[BEMELON]

유튜브 내용이 좋네요 ㅎㅎ

[BEMELON]

책을 읽으면서 어떻게 하는 지는 알겠는데, 이걸 언제 추출/인라인화 해야 하지? 라는 부분이 자세히 설명된게 없어서 아쉬웠던 것 같습니다..!
그리고 분리하게 된다면 어디(서비스, 도메인, 유틸?)에 분리된 메소드들을 분리해야 하는지도 고민이 많이 되더라구요..

다시 한번 테스트의 중요성도 다시 깨달았구요 ㅎㅎ

[w00khyung]

책에서도 여러 번 언급되지만 '정답'이 없기 때문에 어렵고 모호한 부분들이 생기는 것 같아요.
그래서 나름의 기준을 가지고, 좋은 코드를 작성하려는 것보다 좋지 않은 코드를 지양하는 느낌.. 으로 다가가는 것이 좋을 것 같다는 생각이 들었네요.

[choisohyun]

볼 땐 쉬웠지만 막상 실제 현업 코드를 여니 어떤 부분을 해야 좋을지 막막했던 시간이었습니다.

처음 읽을 때 6.2 함수 인라인하기, 6.4 변수 인라인하기가 꼭 해야 하는 리팩토링인가에 대한 생각이 있었습니다.
실습을 하면서 무의미하게 추출해서 tempPrice 와 같이 느껴지는 변수/함수를 고쳐보자는 내용으로 이해를 하게 되었습니다.

함수 선언 바꾸기의 경우 바꾸다가 에러가 나는 경우가 있었는데.. zzPrice같이 이상한 이름의 같은 일을 하는 함수를 만들어두면 서서히 deprecated 시킬 수 있다는 점에서 좋은 것 같습니다.

6.9 여러 함수를 클래스로 묶기를 읽으면서 클래스를 좀 더 활용해 보면 좋을 것 같다는 생각을 했습니다.

[LastCow9000]

리팩터링의 기본과 핵심은 이름 잘 짓기 가 핵심인 것 같아요. 한 줄의 코드라도 함수로 빼내서 무엇을 하는 지 명확하게 표현할 수 있다면 추출하는 것이 좋다는 것을 배웠고, IDE에서 지원하는 리팩터링 기능들을 이용하면 책에서 제시하는 마이그레이션 방법보다 훨씬 용이하게 변경할 수 있어서 잘 이용하는 것이 좋은 것 같아요. (이름 변경, 추출)