리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
2.1 리팩터링 정의
•
두 개의 정의
◦
명사로써; 소프트웨어 겉보기 동작은 그대로 유치한 채, 코드를 이해하고 수정하기도 쉽도록 내부 구조를 변경하는 기법
◦
동사로써; 소프트웨어 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.
◦
기법으로써 말할 수 있는 리팩터링(명사)과 그 기법을 활용하는 행위 둘 다를 뜻한다.
•
“소프트웨어 겉보기 동작은 그대로 유지한 채,”
◦
리팩터링은 코드를 해치지 않는다. 그래야 한다.
◦
리팩터링 후 버그조차 그대로 남아 있어야 한다.
2.2 두 개의 모자
•
“기능 추가”와 “리팩터링”
1.
기능 추가
•
기존 코드를 절대 건드리지 않는다(=리팩터링을 절대 하지 않는다)
2.
리팩터링
•
기능 추가를 절대하지 않는다.
•
테스트 케이스도 새로 추가하지 않는다; 인터페이스를 변경한다면 기존 테스트는 수정한다.
•
두 개의 모자를 자주 바꿔 쓴다 → 기능 추가를 하면서도 리팩터링을 한다.
◦
코딩은 기능 추가가 전부가 아니다.
◦
리팩터링은 기능 추가를 가속한다.
◦
리팩터링을 항상 한다.
2.3 리팩터링 하는 이유
소프트웨어 설계가 좋아진다
•
빠르게 기능 구현을 위해 코드를 작성하면 아키텍처가 나빠진다.
•
코드가 길어진다 → 중복이 많아진다, 나쁜 구조.
소프트웨어를 이해하기 쉬워진다
•
컴퓨터가 할 일과 코드 표현의 차이를 줄이자.
•
(컴퓨터 뿐만 아니라) 팀(다른 사람)이 이해하기 쉽게.
•
(다른 사람 뿐만 아니라) (나중에) 내가 이해하기 쉽게.
•
이해(기억)를 잘하려 말고 이해하기 쉽도록 코드에 표현하자.
버그를 쉽게 찾을 수 있다
•
코드의 구조를 통해 동작을 명확하게 드러내자.
◦
“이럴 것이다” 라는 부분을 리팩터링으로써 확실하게 만들자.
프로그래밍 속도를 높일 수 있다
•
(수 많은 뛰어난 개발자들의 간증?하는) 지구력 가설을 바탕으로 점점 더 빠르게 수정할 수 있다.
2.4 언제 리팩터링 해야 할까?
3의 법칙
•
세번째의 중복, 비슷한 일을 반복할 때부터 리팩터링하자; 삼진 리팩터링
tl;dr - 항상, 자주하자
준비를 위한 리팩터링: 기능을 추가하기 쉽게 만들기
•
기능 추가 직전, 기능 추가를 쉽게하기 위해 한다.
•
버그 수정 직전, 같은 버그를 한 곳으로 모아 수정을 적게 한다.
이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기
•
조건부 로직 구조, 함수 이름 변경 등등
쓰레기 줍기 리팩터링
•
간단히 수정할 수 있는 것은 즉시 고친다.
•
오래 걸린다 하더라도 잘게 쪼갠다면 빨리 고칠 수 있다; 리팩터링은 코드를 해치지 않는다.
계획된 리팩터링과 수시로 하는 리팩터링
•
수시로 해야한다.
◦
단, 적절한 타협점은 있어야 한다. 좋은 코드와 나쁜 코드의 기준은 어제 오늘 사이에도 바뀐다.
•
리팩터링 커밋을 따로하는 것은 굳이 추천하지 않는다. 그럴 수 없는 경우(기능 커밋과 분리하기 어려운)도 많다.
오래 걸리는 리팩터링
•
팀 전체가 매달리지 말자
•
라이브러리 교체 시 추상화로 갈아타기; 
martinfowler.combliki: Branch By Abstraction
◦
종속 라이브러리에 대한 추상 레이어를 구현하고 코드를 조금씩 옮긴다.
◦
조금씩 할 수 있다
코드 리뷰에 리팩터링 활용하기
•
바로 수정해볼 수 있다.
•
PR 보단 짝프로그래밍으로 하자.
관리자에게는 뭐라고 말해야 할까?
•
리팩터링의 의의를 설득시킬게 아니라 그건 내가 알아서 하고 결과로써 증명한다.
리팩터링하지 말아야 할 때
•
내부 동작을 이해하는게 아니라면
◦
외부 API 호출하는 지저분한 코드
◦
처음부터 새로 만들 때
느낀점
•
리팩터링은 항상, 자주, 빠르게 하자; 오래 걸리고 큰 리팩터링이 없진 않지만 그마저도 작게 나누어 또는 전략적으로 할 수 있다.
•
이해를 위한 리팩터링: 코드를 “어렵게 어렵게” 이해했다면, 특히 그럴수록, 그걸 코드에 담아내자.
•
나는 분리된 리팩터링 커밋을 추천한다.
◦
리팩터링을 잘게 나누는 연습
◦
코드를 해치지 않는 연습
◦
특히나 squash merge 한다면 어차피 기능 커밋과 합쳐지니까
•
코드 리뷰에 리팩터링 활용하기
◦
MR base: 이해가 잘 가는지 평가 받기/하기
◦
짝 프로그래밍을 어떻게 하는게 좋을까?