피드로 돌아가기
컬리 기술블로그Backend
원문 읽기
코드 악취를 맡는 후각 훈련의 시간
RMS 개발팀이 리팩토링 기준 수립과 TODO 기반 추적으로 1개월 동안 8개 모듈을 3단계로 나누어 정리, 테스트 커버리지 증가 및 Exception 타입 통일
AI 요약
Context
입고관리 시스템(RMS)은 프로젝트 초기 많은 부분이 미흡한 상태에서 진행되어, 개발자 1명에서 3명으로 확대되는 과정에서 코드 품질 개선의 필요성이 대두되었습니다. 성능이나 기능 이슈는 없었으나 코드의 가독성과 유지보수성이 낮은 상태였습니다.
Technical Solution
- 리팩토링 대상 분류: 메인 기능과 코드 유사성(도메인만 다른 비슷한 동작)을 기준으로 8개 파트로 분류하고 3차로 나누어 진행
- 리팩토링 기준 정의: 30라인 초과 코드, 3중 이상 중첩 조건문, 5개 이상 parameter, 사용하지 않는 method/class/import, 주석 안의 코드, 모호한 명칭을 검출 기준으로 설정
- TODO 기반 추적: 리팩토링 대상과 변경 방향을 IDE의 TODO로 작성하여 팀 리뷰 후 최종 방향 기록
- 테스트 코드 선행 작성: 리팩토링 전 기존 로직에 대해 서비스 레벨의 mock 테스트 코드를 작성하여 모든 분기 커버
- Exception 타입 통일: RuntimeException 대신 ExceptionType enum을 추가하여 오류 메시지를 속성으로 관리하고 String 상수 제거
- 공통함수 재분리: 검수/검품 처리 공통함수에 누적된 다수의 조건문을 제거하고 각 기능별로 분리
Impact
CompletionService의 코드 라인이 리팩토링 이전 대비 감소하였고, InspectionService도 마찬가지로 코드량이 감소했습니다. 테스트 코드 커버리지가 증가하여 코드의 신뢰도가 상승했습니다.
Key Takeaway
리팩토링 기준을 명확히 정의하고 TODO와 테스트 코드로 변경사항을 추적하면, 대규모 코드 개선을 체계적으로 진행하면서 팀 전체의 프로젝트 이해도를 높일 수 있습니다. 리팩토링은 초기 구현보다 이후 유지보수 단계에서 더 중요한 지속적인 활동입니다.
실천 포인트
기존 코드 리팩토링이 필요한 팀에서 리팩토링 기준(30라인 초과, 중첩도 3 이상, parameter 5개 이상 등)을 먼저 정의하고 IDE의 TODO로 대상과 변경 방향을 기록한 후, 리팩토링 전에 기존 로직의 테스트 코드를 먼저 작성하면 변경 후 기능 정합성을 보장하면서 체계적으로 개선할 수 있습니다.