프로그램이야기 두번째 - 리펙토링이란

프로그래머는 항상 자신의 코드가 정리 잘되어 있어 구조적으로 이쁘고 읽기 쉽게 코드를 작성하기 위해 많은 시간을 할애하여 코드를 작성한다. 이것이 리펙토링이라 생각한다. 서점에 나온 책이나 인터넷 사이트를 검색하다 보면 많은 기법이 있고 어렵다고 생각이 드는데 리펙토링은 자신이 작성한 코드나 다른 개발자가 작성한 코드의 기능을 유지하면서 코드를 구조화(이쁘게) 변경하는 것으로 레거시 시스템을 리펙토링 할때는 알려진 버그가 있어도 수정하지 않고 그대로 코드를 읽기 쉽게 만드는 과정이다.

개발자가 코드를 작성 할때 요구사항을 수집하고 요구사항에 따라서 기능을 정의하고 정의된 기능을 기초로 하여 설계하고 코드를 작성한다. 설계 시 작성한 물리적인 폴더 구조, 클래스, 함수, 메서드(이하 함수라함)의 각 기능을 개발단계에서 설계에서 작성한 기능을 코드로 상세화 한 후 테스트-수정-배포를 한다. 처음 작성한 코드가 읽기 쉽고 구조화되어있다면 분석 및 설계단계에서 많은 시간을 투자하여 코드 레벨로 나왔을 것이다. 개발 단계에서 능력 있는 개발자는 객체지향의 5대 요소 중 하나의 책임이야기 하면서 하나의 함수에 하나의 기능을 수행하기 위해서 많은 함수를 만들고 함수명도 적절하게 작성하게 작성을 하여 읽기 쉽게 코드를 만들지만 많은 개발자는 기능 수행을 위해서 조금 덜 이쁜 코드를 작성한다. 두 경우 모두 함수를 만들고 테스트하여 이상이 없으면 개발 끝 배포를 하고 나면 다른 기능을 만들고 시간이 되어 개발 종료가 되어 떠나고 유지보수 팀으로 이관하고 떠난다. 이것이 현실이다. 이런 과정에서 리펙토링을 한다고 이건 미친 짓이다. 과연 미친 짓일까? 코드를 작성할 때 많은 개발자는 다음과 같은 단계를 거친다.

1. 설계 문서를 통해서 설계서에 작성된 내용을 개발하고
2. 코드 리뷰를 통해서 수정하고 ( 하지 않는 곳도 많음 )
3. 테스트 하고 오류가 있으면 수정하고
4. 오류가 없으면 배포한다.

이 과정에서 리펙토링은 언제 할까? 리펙토링은 많은 시간이 들어서할 시간이 없어라는 개발자가 많이 있다. 이건 잘못된 것이라 생각한다. 리펙토링은 적은 시간을 투자하여 코드를 구조화하는 과정으로 코드 작성-코드 리뷰-단위  테스트 과정에서 빈번히 일어나는 과정이라 생각한다. 테스트 주도 개발, 애자일 환경에서는 각 단계에서 자연스럽게 발생하는 것이 리팩토링이다. 즉 기존 개발자는 개발의 패러다임이 바뀌는 것이고 신입 개발자는 자연스럽게 코드 작성의 단계라 생각을 해야 한다.

리펙토링을 하면 뭐가 좋은가?

1. 함수의 길이가 짧아져서 기능을 쉽게 파악할 수 있다.
2. 기능 확장 시 쉽게 영향도 파악을 할 수 있고 적은 시간을 투자하여 확장이 가능하여 생산성이 좋아진다.
3. 클린 코드로 작성이 작성이 된다면 개발 문서를 별도로 만들지 않고 코드를 통해서 기능을 파악할 수 있어 새로운 개발자 투입 시 적은 투자 하여 기능 파악을 할 수 있다.

리펙토링은 함수 추출, 변수 추출등 많은 기법이 있지만 궁극적으로 코드를 읽기 쉽게 구조화하는 과정으로 클린 코드를 작성하는 것으로 클래스, 함수, 변수등의 이름 짓기를 잘하고 하나의  클래스에 하나의 기능, 하나의 함수에 하나의 기능이 되도록 하는 즉 객체와 함수의 단일 책임이 부여가 되도록 하면 자연스럽게 자신의 코드 작성 스타일을 만들어 가는 과정이다.