리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
초판의 추천사
•
코드는 처음부터 완벽하지 않고 경험이 쌓여가며 개선된다
•
코드를 작성하는 횟수 << 읽고 수정하는 횟수
◦
읽고 수정하는 것 자체가 리팩터링이고
◦
읽고 수정하는 것을 쉽게 해주는 것도 리팩터링이다
•
리팩터링을 “잘” 해야 한다 → 코드의 ‘수정’은 미묘한 버그를 만들 수 있다
•
6 ~ 12장은 리팩터링 기법을 모아 놓은 카탈로드이고 책의 핵심이다
•
각 기법의 절차를 이해하고 체계적으로 절제된 리팩터링을 해야 한다 → “한 번에 한 단계씩 수정”해야 한다
들어가며
•
리팩터링 하지 않으면 코드가 너무 복잡해 디버깅도 불가하고 프로젝트가 망했다
•
꾸준히 리팩터링으로 코드를 정리한 프로젝트는 성공했다
리팩터링
•
겉으로 드러나는 코드의 기능(겉보기 동작)은 바꾸지 않으면서 내부 구조를 개선
•
버그가 생길 가능성을 최소로 줄이면서 코드를 정리하는 정제된 방법
•
코드를 작성하고 난 뒤에 개선하는 일
◦
설계 → 코딩을 거꾸로 한다
◦
각 리팩터링 단계는 아주 단순하다
◦
지속 설계
한국어판 독자를 위한 안내
•
Refactoring 한국어판에 대해 위 원서의 업데이트를 공지하는 곳•
자바스크립트 중첩 함수
•
자바, C# 기준 자동 리팩터링 도구, IDE 모음:
01 리팩터링: 첫번째 예시
•
예시 코드가 거대한 프로그램에서 발췌한 것이라고 상상하며 읽자
◦
실제 예시는 책에 담기엔 너무 길지만
◦
너무 짧은 예시는 리팩터링의 필요성이 안느껴지기 때문
1.1 자, 시작해보자!
리팩터링 없는? 상태에서 코드 읽고 해석
1.2 예시 프로그램을 본 소감
•
작동 방식을 더 파악하기 쉽게 구조를 바꾼다
•
리팩터링 → 기능 추가
1.3 리팩티링의 첫 단계
•
언제나 테스트 작성
◦
수정(리팩터링)이라는 사람의 실수를 줄여준다
1.4 statement() 함수 쪼개기
•
함수 추출하기
◦
함수 이름을 짓고 코드를 그대로 옮긴다
◦
값이 바뀌지 않는 변수는 매개변수로 전달
◦
함수에서 값이 바뀐다면 반환
•
명확한 표현으로 바꾸기
◦
함수 반환 변수명을 항상 result
◦
perf → aPerformance ; 동적 타입 언어에서 타입이 드러나게 작성하는 법, 역할이 뚜렷하지 않을 때 관사를 붙인다
•
(임시/지역 변수) play 변수 제거하기
◦
추출 작업이 쉬워진다
◦
임시 변수를 질의 함수로 바꾸기
◦
함수 인라인
◦
함수 선언 바꾸기
•
format → usd
•
volumeCredits
◦
반복문 쪼개기; 단순 순회가 아니라 변수 상태를 바꾸는(값을 누적하는) 경우에
◦
문장 슬라이드; 누적 값에 대한 변수를 쪼갠 반복문과 가까운 곳으로 이동
◦
함수 추출
◦
변수 인라인
•
vs. 성능 ?
◦
성능 저하를 개의치 말고 일단 리팩터링하자
◦
성능 저하가 없진 않지만 대부분 영향이 미미하다
◦
만약 저하가 있다면 리팩터링 후에 성능을 개선하자
•
split commit
◦
테스트가 실패하면 그 시점에서 리팩터링 단계를 더 잘게 나눈다
•
totalAmount
◦
같은 이름의 지역 변수를 추출할 함수 이름으로 예정하고
◦
일단 아무 이름의 함수로 추출한 다음에(appleSauce)
◦
변수 인라인에서 원래의 이름으로 바꾼다
1.5 중간 점검: 난무하는 중첩 함수
•
중첩 함수가 많다. 나쁜가?
느낀점
•
(먼저하는) 설계보다 개선이 중요하다. 우선 작성하고 개선하는 것은 지속 설계이다. 개선하는 루프를 짧게 만들자
•
개선 주기를 짧게 하려면
◦
수정을 작게 나누어 한다.
◦
수정마다 자가 테스트를 한다.
•
생각해보니 루비판을 읽었다
◦
기억나는건 pull up method랑 inline method 뿐이다 ㅎ
•
함수 이름을 아무렇게나 짓고 “변수 인라인” 할 원래 변수명으로 대체하는 것은 신기하다.
•
자바스크립트에서 리팩토링 도구