리팩터링 2판 2장 - 리팩터링 원칙 2탄

리팩터링 시 고려할 문제

 

새 기능 개발 속도 저하

리팩터링의 본집은 코드 베이스를 예쁘게 꾸미는데 있지 않다. 오로지 경제적인 이유로하는것이다. 

 

코드 소유권

코드의 소유권은 팀에 두는 것이다. 팀원이라면 누구나 팀이 소유한 코드를 수정할 수 있게 한다.

브랜치

지속적인 통합 (CI) 또는 트렁크 기반 개발 (TBD)를 따라 모든 팀원이 하루에 최소 한 번은 마스터와 통합한다.머지의 복잡도를 줄일 수 있을 뿐 아니라 리팩터링과의 궁합도 좋다. 기능별 브랜치가 가져오는 리팩터링 부담은 너무나 크다. CI를 적용하는 편이 소프트웨어를 배포하는 데 훨씬 효과적이라는 객관적 증거가 있다.

 

테스팅

리팩터링은 단계별 변경 폭이 작아서 도중에 발생한 오류의 원인이 될만한 코드 범위가 넓지 않다. 원인을 못찾더라도 버전 관리 시스템을 이용하여 가장 최근에 정상 작동하던 상태로 되돌리면 된다. 핵심은 오류를 빨리 잡는데 있다. 리팩터링을 하기 위해서는 자가 테스트 코드를 마련해야 한다.

 

테스트 코드는 리팩터링을 할 수 있게 해줄 뿐만 아니라 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다. 리팩터링 과정에서 버그가 생길 위험이 아주 크다는 불안감을 해소할수 있다. 테스트 코드는 꼭 필요해서라기보다는 갖춰두면 유용하다.

 

자가 테스트 코드는 통합과정에서 발생하는 의미 충돌을 잡는 메커니즘으로 활용할 수 있어서 자연스럽게 CI와도 밀접하게 연관된다. CI에 통합된 테스트는 지속적인 배포 (CD)의 핵심이다.

 

레거시 코드

테스트를 보강한다.