리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
1.6 계산 단계와 포맷팅 단계 분리하기
•
단계 쪼개기
◦
html 렌더 기능 추가를 쉽게하기 위해서 두 단계로 나눈다
1.
(무엇이든 렌더할 값) 계산 단계 → 다름 렌더 단계로 넘겨줌; 함수 값 반환
2.
포매팅 단계; plaintext 또는 html 렌더
◦
중첩 함수라는 점 때문에 우선 전체를 렌더 함수로(renderPlainText) 감싼다
◦
1번 함수에서 반환할 값을 빈 객체로 만들어 두기만한다
◦
렌더 함수의 중첩 함수에서 계산하는 함수들을 하나씩 밖으로 꺼내고 빈 객체에 할당 후 렌더 함수로 다시 넘겨준다
•
반복문을 파이프라인으로 바꾸기; for 를 map reduce 류로 바꾼다?
1.7 중간 점검: 두 파일(과 두 단계)로 분리됨
•
코드량이 늘어난 이유는 대부분 함수 스코프 중괄호 때문이다
•
clarity(??) over concise
•
중복 제거
•
리팩터링과 기능 추가 사이의 균형 맞추기
•
“항시 코드베이스를 작업하기 전보다 더 건강하게 고친다”
1.8 다형성을 활용해 계산 코드 재구성하기
•
조건부 로직을 다형성으로 바꾸기
◦
아래의 것들 먼저…
◦
타입 코드를 서브클래스로 바꾸기
◦
생성자를 팩터리 함수로 바꾸기
◦
에러를 “명시적”으로 던지자
•
클래스로 끌어 올리기
◦
함수 선언 바꾸기
◦
함수 옮기기
◦
함수 인라인; getter로 멤버처럼 접근(호출)
1.9 상태 점검: 다형성을 활용하여 데이터 생성하기
•
코드를 묶는다; 모듈화, 응집성
•
“결과로 나온 데이터 구조를 누가 사용하는가를 기준으로 결정한다”
1.10 마치며
1.
함수 추출하기(코드 쪼개기)
2.
단계 쪼개기
3.
조건부 로직을 다형성으로 바꾸기
•
“객관적”으로 좋은 코드 = 수정하기 쉬운 코드
•
리팩터링 리듬: 각 단계를 굉장히 잘게 나누고 매번 컴파일, 테스트
느낀점
•
(살짝 비약이지만) swap에 xoring을 하지 말라 같다
◦
실제로 리팩터링을 성능의 트레이드 오프를 이야기 하기도 했다
•
리팩터링 리듬은 애자일, 빠른 피드백 루프, 와도 궤를 같이 한다고 느껴진다
•
“결과로 나온 데이터 구조를 누가 사용하는가를 기준으로 결정한다” 를 잘 이해하지 못했다.
•
js엔 루비 같은 NotImplementedError 가 없는가?
◦
궁금해서 찾다보니 루비에서의 용도도 나 역시 잘못 이해하고 있었다. 
MediumRuby NotImplementedError — Don’t use it!
MediumRuby NotImplementedError — Don’t use it!◦
다시 js로 돌아오면 타입스크립트 interface 쓰면 될 일이긴 하다. 오히려 추상 클래스의 가상 메소드 구현에 가깝다; 루비는 강제하는 문법이 없었던 것 뿐이다