Validation 리팩토링 - Kareer

기존 MVP에서 구현했던 Validation 리팩토링을 진행하였습니다.

기존 로직은 Validation 파일에 모든 유효성 로직이 한 파일에 모여있었습니다.
기능 구현이 우선이었기 때문에 일단 돌아가게만 하자... 라고 생각하고
구현을 한 결과 Validator 한 파일에 모든 유효성 검증이 몰려버렸습니다...
(무려 유효성 로직만 277줄...)

기존 코드의 문제점

1. 모든 검증 로직이 한 파일에 집중

• 날짜 검증
• 텍스트 검증
• Autocomplete 검증
• 비자 발급일 검증
• 비자 만료일 검증
• 비자 타입별 조건 분기

전부 하나의 파일에 있었습니다.
문제가 되는 분이 단순히 코드가 긴게 아닌
형식 검증 + 비즈니스 로직 + 도메인 조건이 한 함수 안에 섞여있는 문제였습니다.

2. 하나의 input에 여러 도메인이 겹침
예를 들어 비자 발급일 검증의 경우

• 날짜 형식 검사
• 실제 날짜 유효성 검사
• 미래/과거 날짜 검사
• 비자 타입에 따른 추가 조건 검사

이 모든 로직이 한 곳에 섞여 있었습니다.

해당 구조의 문제점은 명확하였습니다.

• 수정할때마다 전체 맥락을 다시 읽어야 함
• 비자 타입이 늘어나면 if depth가 늘어남
• Date 정규식과 검증 로직이 중복됨

DX도 좋지 않았고 확장성 역시 매우 나쁘다고 생각하였습니다.

3. Date 검증식 중복
Date 검증식이 여러 곳에서 중복 사용되고 있었습니다.

• 일반 Date Input
• 비자 발급일
• 비자 만료일

해당 부분 역시 공통 로직으로 분리해야 하는 영역이었습니다.

리팩토링 중점 사항

• 기존 비즈니스 로직에 관계없이 한곳에 모여있던 Validation에 대해서 역할별 로직을 분리
• 추후 확장성 및 유지보수를 고려하여 분리하기
• 중복된 로직을 제거하고 순수한 함수를 바탕으로 훅 활용
• 기존의 명령형 방식의 코드에서 최대한 선언적으로 코드 구현

구조 분리

우선 기존 한 파일에 모여있던 유효성 검증을 도메인 및 공통 사용으로 분리하였습니다.

공통 검증 (common)
- validateDate.ts
- validateText.ts
- validateAutocomplete.ts

비자 도메인 검증 (visa)
- validateIssuanceDate.ts
- validateExpirationDate.ts

validateDate – 날짜 검증 통합

기존에는 정규식 검사, 날짜 객체 생성, 미래 과거 검증이 각 파일에 흩어져 있었습니다.
그래서 이를 하나의 순수 함수로 통합하였습니다.

validateDate(value, allowFuture, allowPast)

• 숫자와 하이픈만 허용
• 날짜 포맷 검증
• 실제 존재하는 날짜인지 검증
• 미래 / 과거 날짜 제어

형식 검증과 기본 유효성은 해당 순수 함수로 처리하며 사용하는 곳에서 해당 순수함수를 바탕으로 유효성 검증 로직을 추가하였습니다.

const dateValidation = validateDate(issuanceDate, false, true);

if (dateValidation !== true) {
  return dateValidation;
}

1. 공통 날짜 검증은 validateDate에서 처리
2. 통과한 이후에만 비자 도메인 로직 수행

리팩토링 결과

• Date 중복 로직 제거
• 비자 타입 확상 시 별도 파일에서 관리 가능
• 함수별 단일 책임을 확보함
• 코드의 depth 감소
• 유지보수성 및 DX 개선