관리자 또는 상사가 리팩터링을 거부할 경우에는 어떻게 할 것인가?

 - 리팩토링 2판 중

 

내가 가장 많이 받는 질문 중 하나는 "관리자에게 리팩터링에 대해 어떻게 말해야 하나요?"이다.

관리자와 고객이 "리팩터링은 누적된 오류를 잡는 일이거나, 혹은 가치 있는 기능을 만들어내지 못하는 작업"이라고 오해하여 리팩터링이 금기어가 돼버린 조직도 있다.

 

리팩터링을 위한 일정을 몇 주씩 잡는 개발팀을 보면 오해는 더욱 커진다.

설상가상으로 실제로는 리팩터링이 아닌, 어설픈 재구성 작업을 하면서 코드베이스를 오히려 망가뜨리는 모습을 보면 또 불신이 증가한다.

 

관리자가 기술에 정통하고 설계 지구력 가설도 잘 이애하고 있다면, 리팩터링의 필요성을 쉽게 설득할 수 있다.

이런 관리자는 오히려 정기적인 리팩터링을 권장할 뿐만 아니라 팀이 리팩터링을 충분히 하고 있는지 살펴보기도 한다.

 

그러면 팀이 수행하는 리팩터링이 과도할 수는 있어도, 부족할 가능성은 거의 없다.

 

물론 기술을 모르는 상당수의 관리자와 고객은 코드베이스의 건강 상태가 생산성에 미치는 영향을 모른다.

이런 상황에 있는 이들에게는 "리팩터링한다고 말하지 말라"고 조언하겠다.

 

하극상일까? 그렇진 않다. 소프트웨어 개발자는 프로다.

프로 개발자의 역할은 효과적인 소프트웨어를 최대한 빨리 만드는 것이다.

내 경험상 리팩터링하면 소프트웨어를 빠르게 만드는데 아주 효과적이다.

 

새 함수를 추가하려는데 현재 설계가 적합하지 않다면 먼저 리팩터링하고 나서 함수를 추가하는 편이 빠르다.

버그를 수정하려면 현재 소프트웨어의 작동 방식을 이해해야 한다. 이때도 리팩터링부터 하는 편이 가장 빠르다.

 

일정을 최우선으로 여기는 관리자는 최대한 빨리 끝내는 방향으로 진행하기를 원한다.

그리고 구체적인 방버은 개발자가 판단해야 한다.

프로 개발자에게 주어진 업무는 새로운 기능을 빠르게 구현하는 것이고, 가장 빠른 방법은 리팩터링이다.

그래서 리팩터링을 해야한다.