리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
2.5 리팩터링 시 고려할 문제
새 기능 개발 속도 저하
•
리팩터링은 궁극적으로(eventually), 장기적으로 “경제적”인 관점에서 이득이 있기 때문에 하는 것이다.
◦
리팩터링을 코드를 “이쁘게” 만드는 작업으로 여기고 리소스 할애하는 것을 정당화 할 수 없다.
코드 소유권
•
소유권(ownership)은 “변경 사항을 관리” 하는데에 있다. 수정을 못하게 막거나 수정 권한을 독점하는 것이 아니다.
•
오픈 소스 개발 모델 권장
브랜치
•
단방향인 병합이 아니라, 양방향인 통합이 더 중요하다 → 지속 통합과 리팩터링은 궁합이 좋다(=익스트림 프로그래밍).
테스팅
•
리팩터링으로 인한 변경의 실수, 버그를 쉽게 찾을 수 있게 한다.
◦
즉 버그를 만들기 어렵게 만든다.
•
위의 관점에서 보면 CI에 통합시키는 것도 중요하다.###
•
테스트에 의존하지 않는 방법으로 리팩터링 하기
1.
자동 리팩터링 기능
2.
안전하다고 검증된 몇 가지 기법만 사용하기
e.g. cpp 컴파일러 이용하기; Safely extract a function in any C++ code
레거시 코드
•
(없겠지만) 테스트를 추가해야 한다.
데이터베이스
•
진화형 데이터베이스 설계 
martinfowler.comEvolutionary Database Design
•
데이터베이스 리팩터링 기법 Refactoring Databases
•
과정을 잘게 쪼개고 여러 단계로 나눠 릴리스한다
•
평행 수정(팽창-수축) martinfowler.combliki: Parallel Change
2.6 리팩터링, 아키텍처, YAGNI
•
아키텍처는 리팩터링을 통해 변경, 지속 개선될 수 있다.
•
yagni를 적용하여 현재까지의 요구사항까지만 아키텍처 설계한다
2.7 리팩터링과 소프트웨어 개발 프로세스
•
자가 테스트 코드 + 지속 통합 + 리팩터링 그리고 yagni까지
2.8 리팩터링과 성능
•
리팩터링으로 성능에 작은 저하가 있어도 괜찮다.
◦
설계가 더 중요하다.
◦
앞으로 더 빠른 하드웨어가 나올 것이다.
•
리팩터링을 하면 성능 튜닝하기엔 더 수월하다.
◦
아무것도 안 만드는 데도 시간이 걸린다: 성능 개선을 위해선 측정(프로파일링)을 바탕으로 해야 한다
◦
리팩터링은 프로파일링을 수월하게 해준다
▪
성능 문제는 전체 코드 중 극소수에서 대부분 발생하여 이걸 코드 전체적으로 작업하는건 비효율적이다.
▪
어디가 병목인지 찾아내는 프로파일링이 더 중요하다.
2.9 리팩터링 유래
•
그렇다고 한다. 마틴 파울러가 크게 전파하고 유명세를 얻었지만 그전에 관심을 가지고 연구하고 발전시킨 사람이 많다.
2.10 리팩터링 자동화
•
문자 기반 치환 등의 한계
•
구문 트리 해석과 도구가 있는 IDE를 활용하는걸 추천
•
IDE에 기능이 없다면 다시 에디터에서 매크로를 사용
•
LSP code action 활용
2.11 더 알고 싶다면
•
Amazon.comRefactoring Workbook : 리팩터링 연습•
product.kyobobook.co.kr : 리팩터링 + 소프트웨어 패턴
•
product.kyobobook.co.kr : 테스트 커버리지가 낮은 오래된 코드베이스 리팩터링하는 방법
느낀점
•
cpp 컴파일러로 리팩터링
◦
const 를 무조건 붙였다가 떼어서 컴파일 에러를 확인하는 모습이 방어적 프로그래밍 같아 인상적이었다
•
•
성능의 프로파일러처럼 리팩터링을 지표화, 시각화 할 수 없을까?
◦
e.g. DI 그래프에서 참조가 많을수록 뚱뚱하게?
•
통합의 양방향? 증분(diff)만이 아니라 병합 후 전체 코드에 대한 것을 말하는 건가?
•
리팩터링 카탈로그를 익히고 툴을 만들어 보자. 근데 코파일럿 리팩터링이 나올 때가 되지 않았나?