web:신규서비스

차이

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

차이 보기로 링크

--- web:신규서비스 [2018/11/07 17:44]
kwon37xi [Logging]
+++ web:신규서비스 [2019/03/30 18:15]
kwon37xi [API 설계]
@@ 줄 278: / 줄 278: @@
 ===== API 설계 =====
-  * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 ''offset''/''limit'' 으로 요청을 받는 것이 낫다.
+  * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 **더보기 방식**으로 요청을 받는 것이 낫다.
-    * 요청자 측에서 페이징 방식으로 자기네가 알아서 감싸는 것이 쉽다. 즉, 두가지 방식을 모두 요청자측에서 결정해서 할 수 있다.
+    * 더보기 방식은 항상 Primary Key를 기준으로 하여 PK asc 로 정렬을하고, 앞서 1~10 의 결과를 읽었다면 다시 파라미터로 앞의 마지막 PK 10을 받은 뒤 ''pk > 10 limit pageSize''로 그 다음 조회를 한다.
+    * 이 경우 페이지가 뒤로 늘어나도 전혀 성능저하가 발생하지 않고 균일하다.
     * 다음 페이지의 존재 여부를 알고자 한다면 ''limit''이 10이면 11개를 쿼리해서 결과가 11개가 나오면 다음페이지가 존재하고, 아니면 여기서 끝인 것으로 판단하면 된다.
+    * ''offset''/''limit'' 방식도 전체 카운트를 하는 Paging 보다는 낫지만 offset 값이 커질 수로 조건에 맞는 그 앞 데이터에 대한 카운팅을 해야해서 성능이 점점 느려진다.
+      * ''offset''/''limit''은 요청자 측에서 페이징 방식으로 자기네가 알아서 감싸는 것이 쉽다. 즉, 두가지 방식을 모두 요청자측에서 결정해서 할 수 있다.
   * API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다.
     * 호출자 서비스 이름
@@ 줄 312: / 줄 315: @@
   * 각 분야별(OS, 보안, 각 개발 언어, DB, AWS, ...) 등에 대해 전사 표준 가이드를 만들고 Checklist 를 수립하고 신규 서비스 런칭/변경시마다 체크리스트를 각 분야 전문가 한명씩 참가한 상태로 체크하도록 한다.
   * 장애 대응시 [[:5why|5 Whys]]와 [[:pokayoke|Pokayoke 포카요케]]를 적용한다.
+===== 마이그레이션 =====
+  * 서비스를 리팩토링하면서 재구축할 때 실서비스 기준으로 마이그레이션을 먼저 시뮬레이션 해보는게 좋다. 그래야 현재 실제 존재하는 데이터들의 구성을 정확히 파아할 수 있다.
+===== 프로젝트 관리 : 기본적으로 애자일 =====
+  * 오픈 예정일이 굉장히 밀도 높고 여러 팀이 엮인 프로젝트를 진행해야 할 경우
+  * Jira(혹은 관련 이슈 트래커)에 여러 팀별 이슈를 하나로 묶은 보드를 생성한다. (묶음의 조건을 만족시킬 수 있는 이슈 레이블 등이 필요할 듯)
+  * 모든 팀을 통합하여 스프린트를 일괄로 잡는다.
+  * Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다.
+  * 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다.
 ===== 참조 =====
   * [[http://startupstash.com/|Startup Stash]] 스타트업에 필요한 도구들 소개

web/신규서비스.txt · 마지막으로 수정됨: 2024/03/08 11:26 저자 kwon37xi