WHY
1편에서 리팩터링의 전반적인 지식에 대해 다뤘다면 2편은 원칙에 대해 배웁니다. 우선 왜 해야하는지에 대해 설명해줍니다.
- 리팩터링하면 설계가 좋아진다.
- 소프트웨어 이해가 좋아진다.
- 버그를 쉽게 찾을 수 있다.
- 프로그래밍 속도를 높일 수 있다.
여기서 4번은 읽으면서도 이해가 잘 안됐습니다. 리팩터링은 추가로 시간을 투자해서 코드의 품질을 높이는 단계라 이해했습니다만, 기능을 개선 및 추가하는 유지 보수 단계에서 더 시간을 단축할 수 있다는 점을 알게 되었습니다.
프로젝트 중 스마트팜 기기 추가 기능을 추가하는 과정에서 4번을 다시 한 번 깨달을 수 있었습니다. 기기가 추가됨에 따라 컴포넌트에 다 따로 추가해주었었지만 Machine이라는 클래스를 따로 만들어 reference 파일에 기기 클래스만 추가해주면 전체 컴포넌트에 자동으로 추가되었습니다.
WHEN
저자는 한 시간 간격으로 리팩터링을 진행한다고 합니다.
-
준비를 위한 리팩터링
리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전입니다. -
이해를 위한 리팩터링
코드가 하는 일을 파악하기 위해 그 코드의 의도가 더 명확하게 드러나도록 리팩터링할 여지가 없는지 확인합니다. 리팩터링하면서 코드가 깔끔해지고 보이지 않던 설계가 눈에 들어오기 시작합니다. -
쓰레기 줍기 리팩터링
코드를 파악하던 중에 일을 비효율적으로 처리하는 모습을 발견할 때가 있습니다. 바로 고치기엔 너무 많은 시간을 빼앗길 것 같은 경우 짧게 메모만 남기고 하던 일을 마치고 리팩터링을 진행합니다.
리팩터링과 성능
저자는 실제로 소프트웨어를 이해하기 쉽게 만들기 위해 속도가 느려지는 방향으로 수정하는 경우가 많다고 합니다. 성능을 무시하는 이유는 설계의 순수성을 우선시하거나 조만간 더 빠른 하드웨어가 나오리라 믿기 때문입니다. 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것입니다.
