Refactoring

1. 여러 기능에 분산된 휴게시간 계산 로직 수백 명 규모의 새로운 고객사에서는 우리 서비스가 기존에 제공하는 휴게 옵션으로 운영이 어려웠다. 앞으로 존재할 수 있는 잠재적인 고객사의 커버리지까지 높이기 위해 코드 구조를 파악했다. 레거시 코드들은 법령을 그대로 하드코딩하여 유연하게 옵션을 제공하지 않는 형태였고 새로운 옵션이 추가되었을 때도 확장이 불가능한 구조였다. 또한, 기존 휴게 옵션은 유틸리티 클래스로 작성되어 약 35곳에서 직접 호출 중이었다. 문제는 유틸리티 클래스 밖에서 적어도 11개 운영 클래스가 휴게 규칙을 해석 및 계산하는 로직을 중복으로 갖고 있었다. ...

B2B 서비스에서 새로운 고객사가 들어오거나 기존 기능을 수정 및 이슈 픽스 해야하는 상황일 때 복잡한 if-else 레거시가 유지보수 효율성 문제를 자주 발생시켰다. enum 방식의 전략 패턴을 도입했고, 각 로직에는 단위테스트를 쉽게 도입할 수 있었다. 결과적으로 회귀테스트 비용이 제로로 떨어졌고, 나중에 팀원이 동일한 작업을 진행하면서 추가 작업이 쉬워졌음을 느꼈다고 공유해주었다. 이 글에 사용된 코드는 실제 프로덕션 코드가 아닌, 핵심 구조만 재구성한 예시입니다. 유지보수 관점에서 if-else의 문제점 모든 if-else 구조가 나쁜 것은 아니다. 때론 간결하고 단순한 코드 방식이 더욱 유지보수에 유리한 경우가 있다. ...