주제 후보
1. 스타벅스 사이렌 오더
주제
스타벅스 사이렌 오더
선정 이유
다른 서비스에 비해 쉽게 MVP를 만들 수 있을 것 같다.
엄격한 파트 구분 없이 빠르게 진행할 경우 사용자, 주문, 충전 서비스만 만들어도 될 것 같음.
팀 프로젝트의 목적 중 하나인 협업 스킬 향상에 초점을 둘 수 있을 것 같다.
과제 기간이 짧기 때문에 분석 및 구현이 너무 어려울 경우 협업 또한 형식적으로 진행 될 가능성이 있다.
시간이 남을 경우 맡은 기능을 더 깊게 파거나, 우선순위에서 밀렸던 기능을 추가하면 될 것 같다.
진행 방식
원하는 파트 맡기(구상)
사용자(로그인 등 인증 중심)
주문
가게 관련 API
선물하기
쿠폰 CRUD
추천
나를 위한 추천
전체 사용자 통계 기반 추천
충전
카드 CRUD
이벤트 안내
설계하기
UML? ERD?
각자 설계 → 모여서 합치기
처음부터 다 같이 설계
기본 개발 환경 규칙 설정
저장소(브랜치 규칙 등)
린터
스크럼 진행 방식
개발
코드 리뷰 병행
설계 관련 이슈 있을 경우 다시 앞단계로
마무리
프로젝트 문서화(Readme 정리)
2. ✅커머스 + 커뮤니티(오늘의 집, 당근마켓 등)
업무 분담 용이(사용자 1, 커머스 2, 커뮤니티 2)
여유가 있을 경우 1 : 1 채팅 등 심화 기능 구현
수업에서 배웠던 내용들 활용 용이(Spring Security, OAuth, JPA …)
관련 논의
논제: AWS
- 과거 클론코딩 repo들을 보면, AWS를 공통적으로 사용했던데, 우리도 해야 할까?
- 우리 학습 커리큘럼에 AWS가 있는데, 그게 마무리된 이후에 진행하는 편이 낫지 않을까?
- 꼭 AWS를 도입해야 하는지, 운영진에게 문의가 필요해 보인다.
업무 분담 단위에 관하여
- 민재: aggregate 단위로 쪼개자
- 한빈: 너무 크게 쪼개는 것이 아닌지?
- 민성: 스펙을 너무 구체적으로 정하고 시작하면 변화에 대응하기 힘들어지지 않을까?
- ⇒ 어느 정도 구체적인 방향을 잡고 나중에 수정하면 된다.
- 현정 : 메서드 시그니처 양식 통일 중요하다.
멘토님과의 논의 사항
- 패키지 별로 업무를 분담하는 경우? 없음
- 설계 방식
- 다 같이 설계
- 각자 맡은 영역 설계 이후 병합
- 기타?
- 배포 환경을
- 프로젝트를 시작할 때 미리 설정
- 어느 정도 기능이 완성되고 나서 설정
- 멘토님이 올리신 토스 강의 관련
- 모듈은 하나의 라이브러리?
- ERD 작성 구체적 방식?
- short url 관련하여
- 조회 수 관련하여 동시성 이슈
- base 62 외에 8자 이내 제약사항을 충족할 방법?