목차
1. 코드값이란
2. 규모가 작을 때
3. 규모가 클 때코드값
어플리케이션을 만들다보면 여러 코드값을 사용한다. 코드값의 대표적인 예시는 jwt의 만료시간, error code와 메시지 등이 있다.
규모가 작을 때
규모가 작을 때는 static 변수에 담거나, enum 값으로 관리했었다.
1) JwtProperties 클래스를 만들고 static 변수에 담았다
public class JwtProperties {
public static int EXPIRATION_TIME = 864000000; // 10일 (1/1000초)
public static String TOKEN_PREFIX = "Bearer ";
public static String HEADER_STRING = "Authorization";
}2) 관계가 있는 경우에는, enum 으로 관리했다
public enum ErrorCode {
private final String code;
private final String message;
NULL("NO_ERROR", "에러 없음"),
UNKNOWN_ERROR("UNKNOWN_ERROR", "예기치 못한 오류가 발생하였습니다."),
TEAM_NOT_FOUND("TEAM_NOT_FOUND", "해당 그룹(팀)을 찾을 수 없습니다.")
}규모가 커질 때
하지만 코드를 소스파일로 관리하는 것은 여러모로 불편한 점이 있었다. 코드값이 무슨 클래스에 저장되어 있는지 한눈에 파악하기 어려웠다. 그리고 코드값을 수정하고 적용을 하려면 배포를 해야했다 ㅎㄷㄷ
그래서 "코드테이블"을 만들어 관리하기 시작했다. 코드테이블 DDL도 우여곡절이 있었다.
상위코드와 하위코드를 나누고, 하나의 row에는 하나의 code만 담도록 했다. 하지만 이러한 설계는 enum(value1, value2)으로 관리하던 사례를 담기에 어려웠다. 급기야는 value2를 code_desc에 담는 개발자가 나왔다. 이런 개발은 본인만 규칙을 알고 있기 때문에, 다음에 다른 사람이 왔을 때 에러가 나기 십상이다.
1) 상위코드
2) 하위코드_name
3) 하위코드_value
4) 하위코드_desc그래서 아래와 같이 DDL을 추가로 적용했다.
5) 하위코드_name_2
6) 하위코드_value_2
7) 하위코드_desc_2
8) 하위코드_name_3
9) 하위코드_value_3
10) 하위코드_desc_3
11) 하위코드_name_4
12) 하위코드_value_4
13) 하위코드_desc_4느낀 점
- 소스 코드보다 DB에 저장된 값에 접근하는 것이 속도는 느리겠으나, 관리 측면에서 훨씬 용이하다. 어떤 결정이든 trade-off가 있고, 잘 선택을 해야겠다.
- 은행에서 일을 잘한다는 건.. 나 이후에 누가 와도 돌아가는 "시스템"을 만드는 것 같다.
