요즘 공채 시즌 들어서면서 자소서 쓰랴 포트폴리오 손보랴 눈 코 뜰 새 없이 바빠서 블로그 포스팅에 영 신경을 못 썼다.
프로젝트 속도도 느리게 진행되고 있어서 더 그런 것 같다. 이러다 점점 해이해진다. 정신 차려야지,,
블루밍 프로젝트를 진행하면서 날짜 데이터를 사용하고 있는데, 특히 골의 시작날짜와 종료날짜로 전체 날짜수를 계산하고 오늘 날짜는 몇일째인지 날짜수도 계산해야한다.
그래서 날짜수 계산을 위해서 Java의 Chronounit 라이브러리를 사용했다.
ChronoUnit 라이브러리의 장점
- YEARS, MONTHS, DAYS, HOURS, MINUTES, SECONDS 등 단순 날짜수 뿐만 아닌 월 단위, 연 단위, 혹은 시간/분/초 단위의 차도 구할 수 있다.
- 윤년 계산을 따로 고려하지 않아도 알아서 고려해서 결과를 리턴해준다.
여기서 고민이 생겼다.
Chronounit 라이브러리의 날짜수 계산은 결과를 long 타입으로 리턴해준다.
그런데 이미 도메인 설계에서 날짜수-days-를 int 타입으로 지정해줬기에.. 처음엔 별 생각없이 long 타입의 리턴값을 int로 형변환 해주었다. days 필드의 타입을 long으로 바꾸기는 귀찮았다. 이미 여기저기서 days를 많이 가져다 쓰고 있었기 때문에 도메인에서 형변환만 해주면 되는 문제가 아니었음..
그러다 제이미님이 리뷰로 굳이 형변환을 해주어야하는 이유가 뭔지 질문을 주셨고 위와 같은 귀찮음 이슈로 형변환을 해주고 있었기에 말문이 막혔다.
ㅋㅋㅋㅋㅋ아니 그렇잖은가
🧐: 왜 형변환 하셨죠?
🤪: 귀찮아서요
라고 할 수 없으니 그제서야 뭐가 맞는지를 생각하게 되었다.
1. 지금처럼 도메인에서 int로 저장하고 ChronoUnit으로 받은 결과를 int로 형변환 한다.
2. 도메인 필드 타입을 long으로 바꾸고 ChronoUnit으로 받은 결과를 그대로 넣는다.
우선 ChronoUnit 라이브러리에서 결과값을 int가 아닌 long으로 반환하는 이유가 있지 않을까? 해서 고민을 해봤는데, 내가 내린 결론은 이랬다.
1. 날짜 데이터는 시계열 데이터이다. 즉, 시간이 흐름에 따라 계속해서 변하는 값이다.
2. 시간은 계속 흐르니 그 값의 범위가 끝도 없이 방대해질 수 있다. 따라서 int 보다 범위가 넓은 long 타입을 사용했다.
그렇다면 int 범위로 나타낼 수 있는 최대 시간 범위를 계산해보자
위 자료에 따라 int가 나타낼 수 있는 숫자 범위에서 365를 나눠주면 대충 588만년 정도를 반환할 수 있다. (시간은 사용하지 않기 때문에 고려 대상이 아니었다.)
사실 이정도면 서비스 운영에서 문제가 될만한 사항은 아니었기에 그냥 int로 써도 되겠다~ 싶었다.
그런데 만약 형변환 과정에서 문제가 생기면..?
하는 생각이 들어서 몇가지 테스트를 더 해봤다.
- int 타입 메서드 반환값 long 타입 변수에 할당해주기
- long 타입 메서드 반환값 int 타입 변수에 할당해주기
long 타입의 범위가 더 넓기 때문에 1번은 문제 없이 잘 돌아가나 2번에서 에러가 발생했고, 그렇게 되면 데이터가 잘못 들어왔을 경우에 발생하는 문제를 예방하려면 도메인 필드 타입을 가장 범위가 넓은 long으로 지정을 해주는 것이 낫겠다는 결론을 내렸다.
사실 남들 다 int로 형변환해서 사용하기도 하고 해서 아무 생각 없이 도메인 필드도 int겠다 걍 int로 형변환 하자 싶었는데 발생할 수 있는 문제 상황에 대해 좀 더 고민하고 결론을 내릴 수 있었던 것 같다.
나중에 문제 발생해서 뭐가 문제야!!! 하면서 머리 싸매는 것보단 백번 낫지..
