파트너 조회 중복 로직을 공통 메서드로 통합해 유지보수성 개선

partnerSn 조회 로직을 resolvePartnerSn 공통 메서드로 추출

리팩토링 작업을 완료했음.

리팩토링 이유

중복 코드가 여러 클래스에 흩어져 있었음. 수정이 필요할 때 모든 위치를 찾아야 하고, 누락 시 버그가 생김. 공통 메서드로 추출해서 단일 수정 포인트를 만들었음.

변경 전/후

// 수정 전: 중복/복잡 로직
// 각 클래스에 동일 로직 반복

// 수정 후: 명확하고 단일 책임
public static Long resolveId(Object source) {
    if (source instanceof TypeA a) return a.getId();
    if (source instanceof TypeB b) return b.getRefId();
    throw new IllegalArgumentException("지원하지 않는 타입: " + source.getClass());
}

변경 범위

내부 클래스 2개

기대 효과

수정 포인트가 하나로 줄어들어 향후 변경 비용이 낮아짐. 팀원이 코드를 읽을 때 중복을 보고 혼란스러워하는 일도 없어짐.

회귀 검증

리팩토링은 외부 동작을 바꾸지 않아야 함. 입력/출력이 동일한지 주요 케이스를 기준으로 확인했음. 내부 구조만 변경했고, 배포 후 이상 없이 동작했음.

개발 원칙 적용

이번 작업에서 몇 가지 원칙을 확인했음.

단일 책임 원칙: 각 클래스/함수가 하나의 역할만 담당하도록 구분했음. 역할이 섞이면 수정할 때 예상치 못한 곳에 영향이 가기 쉬움.

방어적 프로그래밍: 외부 입력이나 외부 시스템 응답은 항상 의심하고 검증하는 코드를 넣었음. 특히 null 처리와 상태 검증은 빠뜨리기 쉬운 부분임.

로깅: 주요 처리 지점마다 로그를 남겼음. 운영 중 이슈가 생겼을 때 로그만 봐도 원인을 찾을 수 있어야 함.

log.info("처리 시작: id={}, type={}", id, type);
// ... 처리 ...
log.info("처리 완료: id={}, result={}", id, result);

다음