리팩터링 2판 리뷰 - 2장

리팩터링 2판(마틴 파울러 저)을 읽고 작성한 리뷰입니다.

1장에선 리팩토링에 대한 예시를 간단히 알아봤다면,

2장에선 리팩토링의 전반적인 원칙에 대해 설명하고 있고, 리팩터링이 왜 필요한지에 대해 알려주고 있다.

리팩터링을 하는 이유

리팩터링을 진행하지 않으면 구조가 썩는다. 그때그때 요구(단기목표)에 맞게만 수정 된 코드는 전체적인 설계에 부정적인 영향을 미치고 이러한 코드들이 많아 질 수록 더욱 설계는 빠르게 썩는다. 그래서 주기적으로 이해하기 쉽고 수정하기 쉽게 만들기 위해서 리팩터링을 진행해야 한다.

비지니스를 이해하기 쉬워진다.

프로그래밍은 사람이 컴퓨터에게 어떠한 일(비지니스 로직)을 시킬 지 코드로 알려주는 일이다. 그리고 이 코드를 수정하거나 추가하는 사람은 사람이다. 여기서 리팩토링이 왜 "이해하기 쉽게"를 지향하는지 알 수 있다. 바로 사람이 어떠한 일을 컴퓨터에게 시키는 지 코드를 보면 쉽게 알 수 있어야 한다. 비지니스 로직을 이해하기 힘든 코드들로만 이루어진 설계는 분석하는데 엄청난 시간이 들 것이다. 심지어 이 코드를 읽는 사람은 코드를 작성한 사람이 아닌 다른 사람이 될 수 있다. 하지만 코드가 어떠한 동작을 하는 지 읽기 쉽다면 수정하기 쉬워지는 것은 물론 비지니스 로직를 이해하는 것에 있어 더욱 쉬울 것 이다.

생산성이 높아진다.

프로젝트를 진행 할 때 리팩터링을 진행하게 되면 오히려 시간을 구조 개선에 할애하기 때문에 프로그래밍 속도가 느려질 것이라고 생각 할 것이다. 하지만 프로젝트가 커질 수록 생산성이 더욱 떨어지는 경우를 자주 목격 할 수 있다.

시간이 지날 수록 코드의 양은 늘어나는데 왜 생산성이 떨어질까? 바로 설계가 썩어있기 때문이다. 앞서 언급한 것과 같이 그때그때 단기목표를 위해 코드를 작성하고 개선 작업을 거치지 않았다면 전체적인 설계는 엉망일 가능성이 높다. 기능 하나를 추가하는데 시간이 오래걸리는 이유는 어디에 기능을 녹아낼지 알기가 힘들다. 설계가 제대로 되어있지 않기 때문이다. 좋은 설계는 어디에 이 기능을 추가 할지, 어떻게 고칠 지 바로 알 수 있어야 한다.

리팩터링을 해야 할 대표적인 몇 가지 케이스

코드에 기능을 새로 추가 할 때, 이 기능(로직)이 중복되지 않는가? 한번 살펴보고 진행한다. 중복되는 코드가 있다면 리팩터링을 진행하기 시작한다. 그리고 버그가 발생했을 떄 중복된 코드에서 버그가 발생하는지 확인 후 만약 중복된 코드에서 발생한다면 리팩터링 후 버그 수정을 진행해야 한다. 마지막으로 의도가 명확하지 않은 코드를 발견 했을 때 좀 더 이해하기 쉽고 수정하기 쉽게 리팩터링한다.

리팩터링 하지 말아야 할 떄

1. 내부 동작을 이해하지 않아도 될 때 (외부 api 호출)
2. 너무 너무 엉켜있어서 도저히 리팩터링이 불가능 할 때 (새로 작성해야 할 때) → 판단하기 쉽지가 않음

느낌점

리팩터링을 진행하게 되면 별도의 시간을 투자하기 때문에 생산성이 떨어 질 것이라고 조금의 의심은 있었다. 하지만 이 의심은 리팩터링을 제대로 이해하지 못해서 발생했던 것 같다. 리팩터링은 대대적인 개선 작업이라고 생각했었고 리팩터링 도중 중간 중간 코드 실행이 되지 않아도 된다고 생각했었다. 그래서 도중에 멈추기 힘든 개선 작업이라 생각했었다. 하지만 리팩터링을 진행 할 때는 테스트를 통해서 계속해서 코드의 결과(동작)은 변하지 않아야 한다. 그러므로 리팩터링 도중 언제든지 멈출 수 있다. 또한 리팩터링은 대대적으로 며칠동안 시간을 잡고 하는 작업이 아니기 때문에 엄청난 시간이 들지도 않는다. 그래서 리팩터링을 통해 설계를 개선한다면 개선하지 않은 설계보다 요구 사항에 따른 기능 추가나 수정이 더욱 유연하게 대응이 가능하다. 그러므로 오히려 리팩터링을 진행 했을 때가 시간을 더욱 들렸음에도 종국적으로 봤을 때에는 프로젝트의 생산성이 높아진다(시간이 더 단축 됨).