web:신규서비스

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

--- web:신규서비스 [2024/02/08 09:41]
kwon37xi [MQ 등을 통한 비동기 처리 / event driven]
+++ web:신규서비스 [2024/03/08 11:26] (현재)
kwon37xi [시간]
@@ 줄 487: / 줄 487: @@
     * 누군가가 실수로 batch job 실행시간을 잘못된 시간으로 옮겨버리는 행위 등을 감지할 수 있어야 한다.
   * 배치 실행 실간을 가정으로 만들지 말 것. 예를들어 앞선 배치가 1시간 걸릴테니 그에 관한 후속 배치는 2시간 이후 실행되게 했는데, 앞선 배치가 2시간이 넘게 걸리는 등의 현상 발생. Job 들간 의존 관계가 있을 경우 명확하게 의존 관계를 코드나 스케줄로 표현할 것.
-===== 기타 =====
+===== 날짜 / 시간 =====
+  * **한 달(28일, 29일, 30일, 31일)**, **1년(365일, 366일)** 이라는 용어는 매우 주의가 필요하다. 상황에 따라 실질 날수가 달라지기 때문이다.
+    * 가급적 의사 소통을 월/년 으로 하지말고 **날짜수**로 해야한다.
+    * 1 주는 7일 고정이라 무관.
+    * 정말로 의도가 월/년이 맞는 경우에는 항상 로직을 작성할때 ''+- month'', ''+- year'' 로직으로 짜야지 ''+- 30'', ''+-365'' 이런식으로 작성하면 안된다.
   * 날짜 <-> 문자열간 변환이 많이 필요한데, 처음부터 포맷을 결정하고 간다.
     * 날짜시간, 날짜, 시간 세가지 종류가 필요하다.
     * 가급적, 밀리초까지 포함한다. 초까지만 지정하면 추후에 밀리초를 사용할 일이 생겼을 때 매우 당황스러워질 수 있다.
+  * 시각(시분초) 만으로 기간을 설정해야하는 경우가 있다면 시작과 끝을 시각으로 만들면 큰 혼란이 온다.
+    * ''10:00~10:00'', ''10:00~03:00'' 를 어떻게 해석해야할까? (다음날 10시, 다음날 3시 등의 표현)
+    * 이렇게 되면 이 범위를 다루는 코드가 시작시각보다 종료시각이 더 큰 값인 경우는 당일 처리, 더 작은 값이나 같은 값인 경우는 익일 처리 로직을 짜야한다.
+    * 더 심각한 것은 시작은 ''10:00~11:00'' 인데 데이터 입력자의 의도가 **다음날** ''11:00'' 인 경우가 발생할 수도 있다.
+    * 시각기준의 범위를 지정할 때는 **시작 시각 + 유지 시간 형태로 하는게 나아보임.**
+===== 기타 =====
   * 네트워크 연결 되는 설정의 경우 **Connection Timeout과 Read Timeout** 두 가지가 존재한다. 항상 이 둘을 적절히 설정해야 한다.
   * UI 에 페이징을 사용하지 않는 것이 좋다. 페이징은 전체 결과 갯수를 필요로 하는데 이로 인해 DB 부하가 매우 크다. [[search:elasticsearch|Elastic Search]] 같은 검색엔진 기반이라면 써도 된다. 하지만 DB 기반으로 하는 대부분의 애플리케이션은 페이징 UI 말고 offset/limit 방식을 사용해서 페이징을 구현한다. 안그러면 서비스가 성장했을 때 UI가 사용이 불가능할 정도로 느려진다.

web/신규서비스.1707352894.txt.gz · 마지막으로 수정됨: 2024/02/08 09:41 저자 kwon37xi