#PropertiesAndYAML Format Parser

📌사용 방법

properties 나 yml 파일들을 resources 폴더 내 properties 폴더를 생성하여 넣고,
해당 컨트롤러 실행 -> ${변수명:기존값} 형태로 저장.
폴더 단위로 읽기 때문에 여러개의 파일을 한번에 처리 가능.

패턴

properties : datasource.hikari.url -> HIKARI_URL (뒤에서 2자리) -> 중복 발생 가능
yml : datasource.hikari.url -> DATASOURCE_HIKARI_URL (모든 자리) -> 중복 x

패턴 자유롭게 변경 가능

📌개발 취지

회사내에서 대규모 이관이 계획되었다.
이때 문제점으로 나온것이 총 2가지가 있다. #####1. 향후 관리를 생각하여 MSA 환경에서 여기저기 분산된 properties나 yml 설정 파일들을 통합해야한다. #####2. 현재 프로젝트의 GIT을 같이 공유하는 방향으로 설정 파일들을 이관 환경에 맞게 유동적으로 변경할 수 있어야한다. 이를 해결하기 위해서는 설정 파일들이 AWS,Docker 와 같은 여러 환경에 따라 값을 주입받을 수 있도록
해야하며, 그렇게 하기위해선 모든 properties나 yml 파일을 값을 주입받을 수 있는 형태로 수정할 필요가 있었다.
현재 프로젝트에는 수십개의 API 서버가 서로 통신을 주고받고 있으며 개발, 테스트, 실용화등 여러 쓰임에 따라
하나의 API 서버가 여러 형태로 존재하고 있다.
그렇기때문에 사람이 일일이 수정하는것보단 자동화를 하면 추후에 공통으로 사용되는 property 에 대해서도
대처하기 쉬울것이라고 판단하여 개발하게 되었다.

📌작동 원리

YAML의 경우에는 String과 Map의 조합으로 깊이를 구성하고 있기 때문에, 실제 값인 String과 구조 형태의 Map을 구분하는것이 중요했다.
그래서 value 값에 따라 다음과 같이 동작할 수 있도록 정리했다.

if) Map의 value 값으로 String이 올 경우 -> String 변경
if) Map의 value 값으로 Map이 올 경우 -> 재귀함수를 통해, value가 String 일떄까지 반복

properties의 경우에는 YAML과 달리 모든 깊이를 '.'으로 표현하여 간단한 Map 형태로 저장해놨기 때문에 조금 더 간단하였다.
분기가 따로 필요없이 Map의 모든 값들을 변경만 해주었다.

📌개선점

변수명을 어떻게 넣어주느냐에 따라서 장단점이 존재하기 떄문에 더 연구가 필요할것으로 보인다.

변수를 지정하는 부분에서 모든 깊이로 변수명을 작성할 경우, 중복값이 절대 생기지 않는다는 장점이 있다.
단점으로는 변수명이 너무 길어진다는 단점이 존재한다.

반대로 일정 깊이만 변수명으로 작성할 경우, 변수명을 짧게 만들 수 있다는 장점이 있다.
단점으로는 상황에 따라 중복값이 생길 수 있는 여지가 있다.