실용주의 프로그래머 - 33. 리팩터링

urangurang

2020-05-06

review, book

리팩터링

(책) 어떤 이유로든 ‘잘못’되었다고 생각될 때. 변경하는 일을 주저하면 안 된다. 지금이 최적기다.
- (나) 하지만 실제로 언제나 리팩터링을 하기란 쉽지 않다.
(책) 중복, 직교성이 좋지 않은 설계, 유효기간이 끝난 지식, 성능 등이 리팩터링의 원인이 되곤 한다.

(책) 리팩터링을 하지 않는 핑계로 자주 사용되는 이유가 일정의 압박이다. 하지만 설득력 있는 이유가 되지 못한다. 추후에 더 많은 시간을 투자하게 될테니
- (나) 그렇다고 해도 데드라인을 엄수해야할 때 리팩터링 및 테스팅 코드가 부족한 상태로 종종 릴리즈 되곤한다.
(책) 리팩터링해야 할 것들의 명단을 만들고 유지하라. 당장 리팩터링 하기 힘들다면, 일정에 그것을 리팩터링할 시간을 확실히 포함시켜 두도록 한다.
- (나) 관리자(매니저, 프로듀서)와 상의해야할 부분. 리팩터링은 종종 주요 업무로 인정되지 않기에 따로 시간을 떼어 두지 않으면 우선순위가 끝없이 뒤로 밀린다.
(책) 그 코드를 사용하는 사람들이 조만간 리팩터링될 것이라는 사실과 그 사실이 그들의 코드에 어떤 영향을 주게 될지 인지하도록 만들어야 한다.
- (나) 인터페이스의 변화를 일으키는 리팩터링. 자주 하고 싶지는 않다. 디플로이 절차가 복잡하기도 하고, 문제가 일어날 가능성 역시 크다. 가능하면 한 번 정해진 인터페이스는 그대로 유지하는 것을 선호함. 처음부터 바른 설계가 중요.

마틴 파울러의 리팩토링에 대한 몇가지 조언