코드란?
- 코드는 분류, 범주화를 목적으로 하는 것으로 아래와 같은 장점이 있다.
- 그룹핑과 관리가 용이해진다.
- 로직 분기를 위해 사용한다.
- 압축된 형태로 가독성을 높인다.
- 데이터를 유형화하여 조회하는 데 용이하다.
- 식별자와 코드는 다르다.
- 식별자는 엔티티의 각각의 인스턴스를 유일하게 식별하는 것으로 PK 라고 할수 있다.
- 코드는 특정 기준 중심의 분류로 사용되는 것이다.
- 결정해야 할 사항
- 코드의 분류는 어떻게 할 것인가?
- 코드의 저장은 어떻게 할 것인가? - DB, ENUM
- 어떻게 Sync를 맞출 것인가?
- 코드의 규칙은 어떻게 할 것인가?
코드 관리에 정답은 ? 없다.
하지만 DB,백엔드,프론트엔드까지 유기적이고 동기화가 쉽도록하기 위해 반드시 적절한 관리가 필요하다.
관리 방법
DB - 공통 코드 테이블
장점
- 실제 코드가 사용된 테이블을 조회해서 해당 코드값의 의미를 찾을 때 편리하다.
실제 입력된 데이터만을 가지고 바로 코드값의 의미를 찾을 수 있다.
- 특정 코드값만으로 코드유형을 알 수 있고 해당 유형의 코드값들을 조회하기 편리하다.
코드 구성(format)이 전체 5자리로 구성되어 있을 경우 앞의 3자리가 코드 유형을 의미한다는
일정한 규칙이 있을 경우, 우리는 코드값만 알면 앞의 3자리를 조회해서 코드유형의 의미를
찾을 수 있다.
- 위의 모든 과정은 단순히 실제 코드가 사용된 테이블에서 코드값만을 알면 모두 한번의 간단한 쿼리로 알 수 있다.
- 코드 수정 시 서버의 재기동이 필요 없다.
단점
- 관련된 테이블은 조회를 할때마다 항상 join으로 code용 테이블에 있는 데이터를 함께 가져와야 한다.
- 컴파일 단계에서 체크할 수 있는 것이 없다.
- 코드레벨에서 확인할 수 있는 것이 없다.
- 히스토리 관리가 어렵다.
- 높은 DB와의 결합도
ENUM : 상수 컬렉션을 정의하는 데 쓰이는 특수한 자바 유형(type)
장점
- 문자열과 비교해, IDE의 지원을 받을 수 있습니다.
- 자동완성, 오타검증, 텍스트 리팩토링 등
- 데이터 연관 관계 표현
- if문을 포함한 메소드 단위, 반복성 코드 증가 해결
- Y", "1", true 가 한 묶음으로, "N", "2", false를 한묶음으로 사용 가능
- lombok의 @Getter 까지 사용하여 깔끔한 코드
if문과 Enum 활용한 예시
- 상태와 행위까지 한곳에서 관리
- 가독성 : 코드에서 사용하는 값을 의미있는 이름으로 표현 가능하여 가독성 향상
- 상수 정의 1번
- private final static String KBL_LEAGUE_TYPE_VALUE = "01";위와 같이 final 을 사용하여 한번 지정하여 바뀌지 않게 하면서 static으로 메모리에 한번에 할당 할 수도 있다.발생 할 수도 있다.
- 또한 이름 또한 무엇인지 한번에 알 수 있지만, 상수가 너무 많아지면 힘들게 되고 중복 이름이 발생하여 컴파일 에러가
- private final static String WKBL_LEAGUE_TYPE_VALUE = "02";
- interface 로 생성한 상수 집합
- public static final 속성이 생략하여 간결해졌으나, 서로 다른 집합의 상수를 비교하면 컴파일 에러가 난다.
- enum
- 코드가 단순해지고 가독성이 좋으며, enum의 의도가 열거임을 분명하게 알 수 있다.
- 열거형에 추가 속성을 부여할 수 있다.
- 상수 정의 1번
- type-safe : 열거형에 속하는 값만 허용하기 때문에 잘못된 값이 들어오는 오류 방지
- 불변성 : 한 번 정의된 enum값은 변경할 수 없음.
- enum은 고정된 상수 집합으로 런타임이 아닌 컴파일타임에서 모든 값을 알아야 하며, 다른 패키지 또는 클래스에서 접근하여 동적으로 값을 지정해 줄 수 없다.
- 이 때문에 private 로 생성자의 접근제어자를 설정해야 하며 이것은 실질적으로 final과 같다.
단점
- 변경이 어렵다.
- 코드를 추가하거나 변경해야 하는 일이 빈번할 경우
- 매번 Enum을 변경 배포하는 것보다 관리자 또는 운영자가 직접 변경이 편리 할 수 있다.
그렇다면 우리의 상황은 ?
- 공통 코드들이 많은가?
- 추가 되는 공통 코드가 많은가?
- 소스 수정이 많은가?
우리의 상황을 고려했을 때 테이블로 관리하는 것보다 Enum을 활용하는 것이 더욱 편리하다고 생각한다.
또한 0, 1 이 경기상태와 노출타입 등에서 각각 같은 0,1 … 을 사용하여도 Enum을 통해 어떤 의미인지 파악할 수 있다.
코드를 별도로 컨플이나 협업툴에 관리할 필요도 없다.
또한 DB에 의존하게 되면 객체를 중심으로 코드와 설계가 힘들다.
Enum 을 사용하든 상수로 정의하든 코드레벨에서 정의하여 사용한다면 객체간의 책임을 분리할 수 있고
각 서비스간의 동기화도 쉬워질 것이라고 본다.
특히 코드레벨에서 검증이 가능하기 때문에 유지보수가 더 용이하다고 본다.
결론 :
사실 답은 없다. 하지만 코드 정의를 단순히 표준화 수준으로 보는 것이 아니라, 모델링의 중요한 과정으로 보고
적절한 방법을 선택하는 것이 중요하다.
