Day02 스크럼

RunningMate

기획서

• 비즈니스, 마케팅 관점이 아닌 팀의 기술적 역량을 충실하게 표현할 수 있는 주제를 선정해보세요.

• 기획서는 하위 기능 변경에 따라 개발 중 업데이트 할 수 있으나, 메인 주제는 변경할 수 없습니다.

• 기획서 작성 도구 선택은 자유지만, 공동 편집을 지원하고 누구나 접근할 수 있는 URL이 필요합니다.

• 개발에 이견이 없도록 요구사항 정의를 충실히 하세요. 필수 동작 사항에 대한 설명을 포함하세요.

• 기획서는 디자인적인 미려함을 지나치게 고려하지 않아도 괜찮습니다.

• 앱은 앱 스토어에 올라간다는 가정하에 필요한 내용을 준비합니다.

Feature List 작성

• 요구사항(Spec)을 기반으로 기능을(Feature)을 정의하고 그것을 할 일(Task)로 세분화 해보세요.

유즈케이스(Use case)

• 로그인 / 회원가입 기능

• 사용자가 내 정보를 수정할 수 있다

  • 사용자가 자신의 러닝 실력을 기입한다
    • Novice/Intermediate/Advanced/Expert (5분30/1KM)
  • 내가 올린 코스들 추가/삭제 기능
  • 내가 참가한 기록 조회
    • 기록에는 코스, 페이스, 시간
  • 위시리스트 조회 및 편집

• 사용자가 참여자를 모집할 러닝 코스를 업로드한다

  • 사용자가 러닝 계획 시간을 설정한다
  • 사용자가 자신의 러닝 코스를 그린다
  • 인원수 설정

• 사용자는 다른 사용자의 러닝 코스에 참가한다

  • 1/4 -> 1신청 2/4 -> 3/4 ... 4/4 (안보이고)

• 사용자가 필터를 설정하면 필터링된 코스들을 보여준다 (실력 / 시간 / 지역 / 그리고...

  • 필터
    • (시스템적 추천 - 내 페이스 고려해서)내가 시도할만한 코스 (실력) 길이 3km
    • 나와 가까운 코스 (지역)
    • 언제 뛸 시간대 설정
    • 거리가 얼마나 되는지 (상한 하한)
    • 얼마나 오래 뛰는지 (상 하한)

• 사용자가 위시리스트를 클릭해서 원하는 코스들을 찜해둘 수 있다.

• 같이 뛸 사람을 모집하는거 != 내가 뛸 코스를 찾는거랑

욕망의 항아리

- 비공개 코스 (링크로 초대)
- 친구기능 등록
- 사용자가 뛰고싶은 총 킬로수를 입력하면, 지역에서 몇가지 추천들을 제안해서 보여주기
- 다른 사용자의 러닝 코스를 불러와 사용한다. 
- 차단한 사용자끼리는 모집 정보를 볼 수 없다.
    - 매너점수?
- 초기 화면에서 같이 뛸 사람 모집 vs 혼자 코스 찾아서 뛰기 
    - 둘다 가져갈껀지, 하나에 집중할껀지 !
- 내 러닝 실력을 기준으로 코스에 대한 추가 정보 제공(소요 시간....)
- 대댓글 문의 느낌으로
- 후기 
- 추천/비추천
- 카카오톡 공유하기

Task

• 로그인 로그아웃 OAuth + JWT
• DB (ERD) 내일

개발 환경

기술 스택 정하기

기술스택을 정하기에 배경지식이 충분하지 않다고 판단되어 다음날까지 각자 공부 후 공유

• 데이터의베이스의 선택 (코스 저장의 경우, RDB 쓰지말자X -> 요런건 NoSQL에 저장하는게 맞지 않나?)

  • RDB vs NoSQL vs Redis 학습 정리를 해서 내일 서로 기술공유 하기
  • 3 DB 의 특징 장단점
  • 우리 case 어떤게 적합할지 자신 의견

• API

  • REST vs GRAPHQL(?????이거 뭐임) 학습정리 주제로

• React + Typescript

  • Vanilla
  • Angular
  • Vue
  • 전역 상태관리 (건님이 숙제로 해오신대요 - 리액트에 대한 근거 + 상태관리 결정에 대한 장단)
    • Redux
    • Recoil
    • ContextAPI

• Backend

  • node.js http module
  • Express
  • Nest.js
    • 구조가 정형화되어 있다 -> 누가 짜든 코드가 크게 다르지 않다 (구조적으로)
    • 또한, 구조가 정형화되어 있어서 코드 알아보기가 쉽다.
    • 물론, 러닝 커브는 있다. -> 하지만, 공식 문서가 잘 되어 있다.

• ORM

  • Typeorm
    • xxx vs query builder
    • 이거 왜 편하지 ? 현업에서 많이 쓰니까 일단 써봤는데 왜 편한지는 모르겠다 ..
  • Prisma

• 문서 산출, 테스트 도구

  • REST
    • swagger
    • redoc
  • GraphQL
    • playground
  • React
    • storybook

• Docker <-- Kubernetes

• PM2

• nginx proxy

• 프론트 백 서버 따로 배포 <--- 해야 하는건가??

• 해보고 싶은건 많은 안해봐서, 경험해보고싶고

  • 오버엔지니어링일 수 있지 않을 까 ??
  • 멘토링 세션 때 여쭤보면 좋지 않을까

코딩스타일

• ESLint 설정 합의

1. 문자열 : ""
2. 세미콜론 : 사용
3. function foo () 같은줄 : 사용
4. Trailing comma : 사용
5. Space before function : 사용
6. Template String : 사용
7. tabWidth : 4 
8. import : 사용 (ES6)
9. arrow function : 사용
    - 안되는 경우 : 메서드, 프로토타입, 생성자, addEventListenerCallback
10. object curly bracing : 사용
11. console statement : 제거
12. arrow functions return assign : 비허용
13. react prop ordering : 사용
14. react prop validation : 필수 아님
15. object-shorthand : 사용
16. object destructuring : 사용

내일 일정

기술공유

1. React + 전역 상태관리 (최건)
2. DB : Redis vs RDMS vs NoSQL (정석준)
3. API : REST vs GRAPHQL
4. 배포 : Docker + Kubernetes (장수길)
5. ORM : Prisma, TypeORM VS 쿼리
6. NginX : proxy, load balancing (김민정)

기술 스택 결정

세팅

ERD 같이 작성하기