[트러블 슈팅] - 장비 평가 항목의 중복 로직 리팩토링

문제 상황

목요일에 급하게 보고서 기능을 구현하면서 RF 스캐너와 레이더 장비의 평가 항목 중 유사한 계산 로직을 복사-붙여넣기로 처리했습니다.

당시에는 빠른 기능 완성이 우선이었기 때문에, 일부 로직은 장비별 서비스 클래스에 중복된 형태로 존재하게 되었습니다.

 

예

• 추적성 등의 로직이 장비별로 거의 유사
• 단지 레포지토리나 필드 이름 정도만 다르고 계산 방식은 동일

이로 인해 발생한 문제

• 유지보수 시 하나의 로직을 수정하면 다른 곳도 찾아서 수정해야 함
• 가독성이 떨어지고, 로직을 재사용하기 어렵고 테스트도 중복됨

 

원인 분석

• 기능 구현 당시 시간 부족으로 인해 구조보다는 기능 구현 자체에 집중
• 비슷한 평가 항목이 장비마다 존재했음에도 공통화에 대한 고려 없이 복붙으로 처리
• 서비스 계층이 CRUD와 분석 계산까지 모두 처리하고 있어 단일 책임 원칙(SRP)도 위배

 

해결 방법

• 공통 계산 로직 분리
  • 중복되는 계산 (예 : 거리 계산, 정확도 등)을 별도의 공용 유틸리티 클래스로 분리
  • 예 : Calculator 클래스 생성 후 static 매소드로 제공
• 장비별 분석 책임 분리
  • RF스캐너와 레이더 각각에 대해 분석 전담 클래스 생성
  • 기존 RfscannerDataService, RadarDataService에서 RfscannerDataAnalysis, RadarDataAnalysis로 이동
  • 결과적으로 서비스 계층은 CRUD에 집중하고, 분석은 별도 분석 서비스에서 수행

 

개선할 점

• 기능 구현 전에 평가 항목 간 유사성을 미리 분석하고 설계했더라면 중복 없이 구현 가능했음
• 공통 로직을 발견했을 때는 임시 방편으로 넘기지 말고, 즉시 리팩토링을 고려할 수 있는 여유를 확보해야 함
• 서비스 클래스는 단일 책임 원칙에 따라 역할을 명확히 분리하여 유지보수성을 높여야 함