쓰지 않는 코드 제거
역사적인 이유 때문에 실제론 어디에서도 쓰이지 않는 코드가 생기기 마련이다. 하나씩 주석 처리하고 빌드해보기를 반복하여, 쓸모 없는 코드를 제거했다. 뇌 용량에는 한계가 있으므로 신경 써야 할 코드를 줄여야 한다.
ODBC에 종속적인 코드 제거
주로 핸들과 같은 저수준의 개체가 외부로 드러나지 않도록 코드를 정리하는 일부터 했다.
인터페이스 통일
ADO가 객체지향적으로 잘 설계되어 있기 때문에 기존에 작성한 ODBC 코드를 ADO에 맞춰 다시 설계했다. 객체들이 핸들과 같은 저수준의 개체를 주고 받지 않도록 해야 이 작업이 가능하다.
접근 제어
public이나 protected로 선언된 메서드를 그보다 낮은 수준으로 정리해본다. 우선 private으로 설정하고 빌드해본다. 재정의하는 경우가 있을 때만 protected로 조정한다. 나중에 재정의하는 코드를 작성해야 한다면, 지금은 private으로 선언한다. 나중 일은 나중에 처리한다.
이렇게 외부에 드러나는 인터페이스를 최대한 줄이면, 기존 코드의 기능을 일목요연하게 이해하기 쉬워진다. 또한 기능을 새로 추가할 때 필요한 만큼만 정확히 일할 수 있게 된다.
중복 코드 제거
급한 마음에 Copy&Paste한 코드가 분명히 있다. 각 코드가 미묘하게 달라서 깔끔하게 정리하기 어렵다면, 단위 테스트 코드를 활용해서라도 반드시 중복 코드를 제거해야 한다.
기존 코드 개선이 우선! 새 기능 추가를 미루기
ODBC 코드를 정리하고 나서 ADO 기능을 추가했다. ODBC 코드를 개선하는 데 약 6일이 걸렸고, ADO 기능을 추가하는 데 약 2.5일이 걸렸다. ODBC 기능을 앞으로 쓰지 않을 예정이기 때문에 이같은 시간 배분이 낭비 같이 보일 수도 있다. 하지만 기존 코드를 한번에 없애고 새 기능으로 대체하려고 하면, 개발 기간 내내 해당 애플리케이션 또는 라이브러리는 제 역할을 못한다. 다시 말해, 다른 사람이 자기 일을 못하게 된다. 또한 방대한 기능을 한번에 갈아 엎으려 하면 예기치 않은 문제가 발생해서 기간이 수 배로 늘어나기 십상이다. 리팩토링은 점진적으로 해야 제맛이다.
단위 테스트
이 부분이 가장 미흡했다. ODBC 코드를 정리하는 과정에서 단위 테스트 코드를 거의 작성하지 않아서, 최종적으로 나온 ODBC 코드에 버그가 발생했다. 다행히 그리 중요한 문제가 아니라서 다른 사람이 작업하는 데 크게 방해가 되진 않았다. 어차피 기존 ODBC 코드는 쓰지 않기로 했으니, 굳이 미묘한 동기화 문제를 해결하지는 않았다.
ADO 기능을 추가할 때는 비교적 상세한 단위 테스트 코드를 작성했다. 그럼에도 불구하고 ADO 코드를 커밋하고 나서 곧바로 두 가지 버그를 발견했다. 작성한 테스트 케이스로는 발견 못했던 버그였다. 운 좋게도 이 문제는 15분 내에 해결해낼 수 있었다.
