리팩터링 1장

리팩터링 1단계

코드의 구조 보강하기

• 27.p

  설계가 나쁜 시스템은 수정하기 어렵고 수정 과정에서 버그가 생길 가능성이 높다.
  프로그램의 구조가 빈약하다면 대체로 구조부터 바로잡은 뒤에 기능을 수정하는 편이 좋다.

우선 "청구 내역" 코드에서 청구 내역을 HTML로 출력하는 기능이 필요.

• 30.p

  그 전에 statement 함수의 긴 문장을 중간에서 한번 자를 필요가 있다.
  한번의 공연에 대한 요금을 계산하는 switch 문을 별도로 빼본다.

  1. 우선 유효범위를 벗어나는 변수, 즉 새 함수에서는 곧바로 사용할 수 없는 변수가 있는지 확인한다.
  2. 함수 안에서 값이 변하는 변수는 조심히 다뤄야하고, 값이 일정한 변수는 매개변수에 담는다.
  3. 리팩토링을 할때엔 한번에 작은 단위를 변경하고 테스트를 꼭 해봐야한다. 피드백 주기를 짧게 가져가야 재앙을 피할 수 있다.

• 35.p

  play 변수는 for문에서 가져오는것이기 때문에 굳이 매개변수로 받지 않아도 된다. 이럴때 "임시 변수를 질의 함수로 바꾸기" 를 적용한다. 이렇게 하면 변수 선언을 인라인 함수로 변경할 수 있다. (1줄 삭제가 가능)
  ** 그런데 매 play마다 playFor(perf) 함수로 바꾸면 오히려 성능적으로 안좋은거 아닌가..? 함수 실행이 훨씬 많아지므로...?

• 39.p

  위에서 내가 생각한 성능의 문제를 설명해줌.
  성능은 거의 차이가 안날것이고 (너무 간단한 함수라), 지역 변수를 제거해서 얻는 가장 큰 장점은 추출 작업이 쉬워진다는 것이다. 유효범위를 신경써야 할 대상이 줄어들기 때문이다.
  ** 추출 작업이 뭐지?

• 42.p

  보조 함수의 return 값은 항상 result로 해주면 깔끔하다.

• 42.p

  임시 변수는 자신이 속한 루틴에서만 의미가 있어서 루틴이 길고 복잡해질 수 있다. const format을 제거해본다.

• 48.p

  ** 반복문을 쪼개서 성능이 느려진다는게 무슨 말이지?

리팩토링 2단계

원하는 기능 추가하기

• 우선 "청구 내역" 코드에서 청구 내역을 HTML로 출력하는 기능이 필요.

• 52.p

  기존의 statement 함수의 return을 텍스트와 HTML 두가지로 표현하고 싶다면?
  statement 함수의 내용을 담을 보조 함수를 만든다.
  이때 데이터 전체를 매개변수로 넘기기보다는 사용할 데이터에 대해서만 data라는 변수에 담아서 재가공해서 보내주면 좋다.
  기존에 사용하던 보조함수들을 이용해 data 변수에 다 담아준다.

• 60.p

  두 단계의 분리가 명확하게 됐다면 파일 단위로 분리해버린다.

리팩토링 3단계

다형성을 활용해 계산 코드 재구성

• 64.p

  "조건부 로직을 다형성으로 바꾸기"
  switch 문으로 play type을 나눴던것과 if 문으로 comedy일때 추가 적립금을 줬던 것을 다형성 클래스로 변경해본다.

• 70.p

  자바스크립트에서는 생성자가 서브클래스의 인스턴스를 반환할 수 없기 때문에 생성자를 팩토리 함수(값을 그대로 return 해주기만 하는 함수)로 적용해준다.

• 71.p

  팩토리 함수 내부에서 이제 switch 문을 활용하여 PerformanceCalculator class를 상속 받은 다양한 케이스의 class 들을 호출한다.

• 73.p

  대부분의 장르에서 공통으로 사용되는 로직은 super class에 두고 예외의 경우만 오버라이딩해서 쓴다.

• 75.p

  이제 새로운 장르에 따른 계산식이 추가된다면 서브클래스로 추가하기만 하면 된다.
  ** 그럼에도 불구하고 다형성 클래스로 리팩토링 한 의미가 와닿지 않는다...

• 76.p

  누군가에겐 적절한 이름의 작은 함수들로 나누는 리팩토링 방식에 반대할수도 있지만 (내가)
  취향을 넘어서는 관점 즉, "수정하기 쉬운 코드가 좋은 코드다" 라는 기준이 분명히 존재한다면 건강한 코드를 작성할 수 있다고 필자는 말한다.