0. 목차

1. 개요
2. 로직의 목표
3. 초기 구현 코드
   • 2.1. 템플릿 정의 방식
   • 2.2. Validator의 메인 로직
4. 상태 패턴을 적용하기
   • 4.1. 고민한 내용
   • 4.2. 상태 패턴
   • 4.3. 구조 설계
   • 4.4. 적용 결과
5. 여전히 남은 문제들
6. 결론

1. 개요

본 글에서는 사내 업무 시스템 개발 과정에서 겪은 리팩토링 경험을 공유합니다. 비즈니스 프로세스의 순서를 검증하는 로직을 구현했는데 너무 복잡하여 이를 상태 패턴을 적용하여 개선해보는 내용입니다. 만족할 만큼의 클린 코드에는 달성하지 못해 결과적으로는 기술 부채로 남겨두었지만 나름 많은 고민을 했던 내용이라 작성해보았습니다.

• 예시 코드는 실제 코드가 아닌 컨셉 코드로 대체하였습니다.

1. 로직의 목표

먼저 리팩토링의 대상이 되는 로직의 주 목표에 대해서 생각해보겠습니다. 목표는 주어진 비즈니스 시나리오의 순서를 검증하는 것입니다.

특히, 비즈니스 시나리오에 따라 발생한 로그 메시지의 순서를 검증하는데, 이때 메시지 내부에 정의된 페이로드(Payload) 시퀀스가 기준이 됩니다. 여기서 페이로드는 서버와 클라이언트 간에 전송되는 메시지를 의미하며, 각 페이로드는 특정 비즈니스 시나리오의 한 단계를 나타냅니다.

예를 들어, "특정 시나리오"라는 시나리오를 생각해보겠습니다. 이 시나리오에서는 아래와 같은 페이로드 순서가 정의되어 있습니다.

1. 서버에서 클라이언트로 CertainPayload 타입의 메시지 전달
2. 클라이언트에서 이에 대한 응답
3. 클라이언트에서 NotificationPayload 타입의 메시지를 서버로 전달
4. 서버에서 이에 대한 응답

이 경우, 총 4개의 페이로드가 서버와 클라이언트 간에 교환됩니다.