[백엔드의 협업] 기획 단계의 내용들을 개발 초기에 상수화하기

기획 단계 혹은 요구사항 분석 단계에서 API 명세, 와이어프레임 작업, 컨벤션 확립 등의 과정을 거친다.

 

예를 들어 회원 이름의 글자 수 제한은 기획 단계에서 정해진다. 

 

이러한 값들을 초기에 상수화하여 관리하면 관심사를 분리할 수 있고 개발이 편해진다. 

추후 기획이 변경되더라도 다른 파일들의 git 변경 이력을 최소화할 수 있다는 장점도 있다.

 

와이어프레임의 정보를 상수화하기

아래 사진은 피그마로 디자인된 게시글 작성 페이지. 극초기의 와이어프레임이었다.

 

 

 

public final class ConstraintConstants {

    public static final int SPOT_IMAGE_MAX_SIZE = 5;
    public static final int SPOT_CONTENT_MAX_LENGTH = 1500;

    // ...
}

 

 

요청 DTO에서 유효성 검사하기 (validation)

 

물론 프론트엔드쪽에서 유효성 검사를 하겠지만, 프론트엔드에 전적으로 맡겨선 안 된다고 생각한다. 

DTO에서 필드별로 유효성 검사를 해준다.

 

    @Builder
    public record CreateSpotRequest(
            // ...
            @NotBlank @Size(max = SPOT_CONTENT_MAX_LENGTH)
            String content,
            @NotNull @Size(max = SPOT_IMAGE_MAX_SIZE)
            List<String> imageUrls
    ) {
    }

 

엔티티에서 유효성 검사하기 (validation)

 

DTO에서 검사하는데... 왜 엔티티에서도 하지? 라고 생각할 수 있지만, DTO에서 잡을 수 없는 오류가 발생할 수 있다.

테스트 코드 등에서 휴먼 에러로 인해 유효하지 않은 데이터가 삽입될 가능성이 있기 때문에 제약 조건을 걸어준다.

 

// ...
public class Spot {

    @NotNull
    @Size(max = ConstraintConstants.SPOT_TITLE_MAX_LENGTH)
    private String title;
    
    // ...
}

 

별거 아니라고 생각할 수도 있지만, 이렇게 기획 값들을 상수화해두면 이후의 개발이 정말 편해진다. 쌩으로 문자열을 넣는것보다 개인적으로 이 방식이 가독성도 더 좋다고 느낀다.