1년 간의 리팩토링, 예상과 다른 결과: 무엇이 문제였을까?

리팩토링은 기존 코드의 단순한 버그 수정이 아닌, API 인터페이스(API Interface) 및 내부 구조의 근본적인 변경을 수반한다. 특히, 데이터 구조가 변경되면 기존 코드의 재사용은 극히 제한적이며, API 호출 코드 또한 수정이 불가피하다. 저자는 텍스트 에디터 리팩토링 과정에서 10% 미만의 코드만 재사용했으며, 이는 리팩토링 프로젝트의 현실적인 어려움을 보여준다. 결과적으로(Consequently), 리팩토링은 사실상 모든 코드를 폐기하는 것과 유사한 과정을 거치게 된다.

저자는 텍스트 검색과 같은 기능을 비동기적으로 처리하기 위해, 스레드 안전 큐(Thread-safe Queue)를 구현해야 했다. 초기에는 간단한 파이프를 사용했지만, 성능 개선을 위해 더 복잡한 구조로 전환했다. 비동기 시스템 구현에 한 달 이상이 소요되었으며, 이는 초기 예상보다 훨씬 긴 시간이다. 특히(Specifically), IO 스레드, 일반 작업자 스레드, 메인 스레드 간의 메시지 전달을 효율적으로 관리하는 설계가 필요했다.

LSP 및 DAP 지원을 위해, 저자는 관련 데이터 구조 및 직렬화 코드를 생성하는 과정에서 예상치 못한 어려움에 직면했다. LSP의 복잡한 구조로 인해, 코드베이스에 과도한 조건문(Conditional Statements)이 추가되었고, 이는 코드의 가독성을 저해했다. 기술적으로 보면(Technically), LSP는 동일한 데이터를 여러 방식으로 표현하여, 코드 유지보수를 더욱 어렵게 만들었다. 결론적으로(In conclusion), LSP/DAP 지원은 프로젝트의 범위를 확장시키고, 코드 복잡성을 증가시키는 요인으로 작용했다.

저자는 리팩토링 과정에서, 초기 예상보다 더 많은 기능을 구현하게 되면서, 프로젝트 기간 예측에 실패했다. 실제 사례로는(For example), LSP 및 DAP 지원 범위를 확장하면서, 예상보다 많은 시간이 소요되었다. 또한, 린터(Linter) 및 CI/CD 구축과 같은 부가적인 작업에 대한 고려가 부족했다. 주목할 점은(Notably), 프로젝트 범위 설정의 중요성을 강조하며, 재사용 가능한 코드의 부재를 고려하여, 넉넉한 시간을 할애해야 함을 강조한다.