<aside>
💡 오늘의 목표를 세분화하여 계획하고, 각 세션 별 진행상황을 관리하세요
</aside>
프로젝트 방향성
API 버전 구분을 진행해야 하는가?
From 디스코드 메세지
- 버전 구분을 진행하지 않는다면, API v1.0는 어떻게 정의되는가?
- 명확한 DoD가 없다면 지속적으로 통합 발전시키는 방식으로 개발하는 것이 좋을까?
- 버전 구분을 진행한다면, 구분된 버전에 대한 독립적인 개발을 진행하는가?
- 독립적인 개발에 투입될 개발자의 절대적인 수가 부족하진 않은가?
문서 다중화의 문제
<aside>
💡
추가되는 개선점들을 반영하는 것은 MVP 개발까지의 시간 소요를 증가시킨다.
</aside>
- 하나의 문서에서 특정 버전에 대한 요구사항을 명시하고,
요구사항 만족 시 Release하는 방식으로 개발하는 방식은 어떨까?
- 요구사항은 문서로 작성될 수 있지만, 테스트를 통한 검증 과정으로도 작성될 수 있다고 본다.
- Figma 작성에 대한 목적을 다음과 같이 정의하는 것은 어떨까?
- 본 프로젝트를 처음 접한 개발자가 30분 이내로 프로젝트에 대한 구성과 동작 방식을 이해하기 위한 도식을 제공한다.
- 목적을 위와 같이 설정했을 때, 실제 백엔드 개발자들이 개발을 위해 필요한 내용도 정리가 필요해진다.
해당 내용은 API 버전에 따른 요구사항 문서에 통합하여 관리하는 것은 어떨까?
API 개선점
POST 메소드에 전달되는 Body에 queryString을 담아 처리하자
- 이 경우, base64-encoding을 사용하지 않아도 괜찮다는 것이 @성우 송 의견
Java21 가상 스레드를 활용하여 클라이언트 및 관리자 요청을 흉내내는 벤치마커 서버 만들기
- 의사결정이 난해하거나 성능 개선에 대한 수치화를 진행할 때, 큰 도움이 될 것이라고 확신한다.
- 단, 매번 volume을 삭제하고 docker-composing하는 작업이 필요할 수 있는데,
이는 테스트에 동일한 환경에서의 실행이 필수적이기 때문이다.
- 또는 현재 저장된 데이터를 모두 삭제하는 기능을 API로 구현하여,
매 테스트 시작마다 호출하는 방식으로도 구현이 가능할 것 같다.
예외처리: 상태코드 ≠ 200인 경우
From 디스코드 메세지