오랜만에 서비스중인 프로젝트의 코드를 보고있었는데, 정말 코드가 심각하게 더러워서 리팩토링을 진행하게 되었다.
분명 예전에 보았을 때는 괜찮다고 생각했는데, 오랜만에 코드를 확인해서 그런지 예전엔 생각하지 못했던 부분들이 보였다.
이번 글에서는 개발자들에게 필수적으로 필요한 리팩토링에 대해서 이야기해볼려한다.
refactoring
오늘 이야기할려는 리팩토링 (refactoring) 이라는 단어는 영어사전에는 존재하지않는 단어다.
그럼 언제부터 이 단어가 생기게 되었을까?
이 refactoring 이라는 단어는 사실 언제 생겨났는지 명확하지 않다. 하지만 널리 퍼지기 시작한 계기중 하나를 이 사람이라고 이야기 할 수 있다.
1990년 마틴 파울러라는 사람이 Refactoring: Improving the Design of Existing Code라는 책을 통해 이 개념에 대해 널리 알리기 시작했다.
이 마틴 아저씨가 이야기하는 리팩토링의 정의를 한 단어로 이야기하자면..
사용자 관점에서 변하는게 없지만, 내부적으로 함수의 성능이나 구조가 변하는 것
..라고 할 수 있다.
겉보기론 똑같은 동작을 하지만, 더 이해하기 쉬워지고, 더 수정하기 간편해지며 더욱 좋은 성능을 내게 만드는 것이라고 할 수 있다.
물론 여기서 중요한 것은 사용자 관점에서 보았을 때 이전과 같은 동작을 해야한다는 것이다.
리팩토링을 해야하는 이유
리팩토링을 하지 않게 되면 소프트웨어의 아키텍쳐가 무너져가기 쉽다. 이 내부 설계가 무너지게 된다면 코드를 통해 이 내부 설계를 파악하기가 어려워진다.
코드만으로 설계를 파악하기가 어려워질수록 이 설계를 유지하기가 어려워지고, 점차 녹이들게 된다.
코드의 의도를 잘 생각하자
리팩토링을 이야기할 때, 성능을 향상시키기 위해 코드를 수정하는 것에 중점을 맞추는 경우가 많다.
하지만 그건 잘못된 방향성이라고 생각한다. 코드 자체의 성능에 포커스를 맞추게 되면 길고 이해하기 힘든 구조의 코드가 발생하는 경우가 부지기수다.
코딩이란 컴퓨터에게 명령을 내리는 것 만이 중요한 것이 아니다.
내가 작성한 코드를 컴퓨터만 보는 것이 아니라, 이후에 다른 개발자가 수정을 위해 읽게 될지도 모른다.
잘 작동하지만 좋지않은 구조를 가지고있는 코드는 다른 개발자가 수정을 위해 코드를 살펴볼 때, 1시간이면 해결할 수 있는 문제를 2일, 5일, 일주일.. 이나 걸리게 할 수 있다.
이렇게 프로그램의 동작에 대해서만 집중하게 된다면 나중에 이 코드를 살펴볼 다른 개발자를 배려하지 못하게 된다는 데 있다.
프로그램의 동작에 집중하기보다는 코드에 목적이 잘 드러나게, 내 의도가 잘 전달 뒬 수 있는 코드를 작성하는 것이 중요하다.
지구력 가설
리팩토링을 통해 코드의 품질을 높일 수 있다.
하지만 그러면 시간이 너무 오래걸려 전체 개발 속도가 느려지는 것이 아닌가?
한 시스템을 오랫동안 개발한 개발자들을 보면 초기에는 빠르게 개발했지만 나중엔 기능 하나를 추가하는 데 훨씬 오래걸린다고 이야기한다. 새로운 기능을 하나 추가할 때 마다 기존 코드에 녹여내는 시간이 늘어나고, 기능을 추가할 때 버그가 발생하는 일이 잦아지기도 한다.
또 심한 경우에는 차라리 처음부터 다시 개발하는게 더 낫겠다고 생각하는 일까지 생기는 경우도 있다.
그래서 코드의 품질이 중요하다.
좋은 설계를 통해 코드를 작성하게 된다면 현재 코드베이스를 이용해 더 빠르게 신규 기능을 추가할 수 있고, 또한 명확한 코드를 통해 버그를 쉽게 디버깅할 수 있다.
리팩토링에 대해
리팩토링은 단순히 코드의 성능을 개선하는 것이 아니라, 코드의 가독성과 유지보수성을 높여주는 핵심 작업이라고 할 수 있다.
코드는 더 명확해지고, 수정이 쉬워지며, 성능이 개선된다.
결국 리팩토링은 사용자를 위한 수정이 아니라, 사용자와 개발자 모두에게 더 나은 경험을 제공해줄 수 있는 작업이다.