Back-end/협업

Back-end/협업

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

기획 단계 혹은 요구사항 분석 단계에서 API 명세, 와이어프레임 작업, 컨벤션 확립 등의 과정을 거친다. 예를 들어 회원 이름의 글자 수 제한은 기획 단계에서 정해진다. 이러한 값들을 초기에 상수화하여 관리하면 관심사를 분리할 수 있고 개발이 편해진다. 추후 기획이 변경되더라도 다른 파일들의 git 변경 이력을 최소화할 수 있다는 장점도 있다. 와이어프레임의 정보를 상수화하기 아래 사진은 피그마로 디자인된 게시글 작성 페이지. 극초기의 와이어프레임이었다. public final class ConstraintConstants { public static final int SPOT_IMAGE_MAX_SIZE = 5; public static final int SPOT_CONTENT_MAX_LENGTH = ..

Back-end/협업

[백엔드의 협업] HTTP 표준 대신에 커스텀 status code 사용하기

💡 발단 기존에는 HTTP code(2xx, 3xx, 4xx)와 메세지로 서버의 응답을 표현하는 것이 무조건 옳다고 생각했다. 표준을 따른다면 웹 API에서는 이 방식을 따르는게 맞다. 그런데, HTTP의 40여개 코드로는 REST API의 모든 분기를 처리하기에 너무 적다. 예를 들면 권한 처리가 있다. 정지된 유저가 요청을 할 때와, 글쓴이가 아닌 유저의 글 삭제 요청에 대한 응답 코드는 모두 403(not Authorized) 이다. // 403 에러 { "message" : "banned user." } // 403 에러 { "message" : "not author of this content." } 문제는, 403으로 표현할 수 있는 가짓수가 너무 적다는거. 그래서 여러가지 분기를 표현하려면 ..

zorbathegeek
'Back-end/협업' 카테고리의 글 목록