2022.07.12

모닝톡

쿤의 아이디어 설명

• (장점) 신뢰도가 상승한다
  • 아직 출석하지 않았음에도 불구하고 출석하는 것을 방지할 수 있다.
• (단점) 강제성이 떨어진다.
  • 예를들어
    • 내가 9번 결일하고 1번 더 결일하면 퇴소라고 가정했을 때 해당 크루는 출석 버튼을 누를 수 밖에 없다

개인적인 서기의 생각

초기 개발을 진행할 때는 최대한 프로덕션 위주로 진행했으면 아이디어를 빠르게 변경할 수 있지 않았을까…

• 예를들어 E2E 테스트 코드만 작성
  • 이마저도 Java위주가 아닌, Json 파일로 In 데이터/Out 데이터 파싱했더라면 ...

Git 실습에서 나온 얘기

• upstream 머지를 하는 것의 순서

  • merge를 할 때 마다 pull을 땡겨서 dev 브랜치를 갱신해야함

• squash merge 등의 얘기를 했었음

• main과 dev 등의 충돌이 있었음.

• 이 경우 main 브랜치를 카피하여 dev 브랜치를 반영하는 것으로 반영하는

16 ~ 18시 스프린트2 회의

(서비스 시작의 계기)
포비(talk): 여러분들의 출결 관리 문화를 만들어보세요.

• 출석 체크의 편리함보다는 출결 내역 기록과 벌칙(커피스택등)의 자동화에 포커스를 두자.

마스터가 오지 않은 경우에 대한 경우

• 마스터가 스스로 권한을 넘김
• 3명이상으 크루가 동의하면 권한 부여
• 1명의 크루가 동의하면 권한 부여

데일리 마스터가 있어야 하는가?

• 있어야 하는 것으로.

• 필수 구현 순서: 1 ~ 4

(서기) 노션과 깃허브

노션 -> 깃허브

이유: 노션은 실시간으로 확인이 가능하다

플래닝 포커

• 기능 구현을 하는 데 필요한 최소한의 단위

• 이 시간의 개념은 리뷰하는 시간을 포함하지 않은 순수 개발(coding)을 하는 시간

• 모드: 피보나치

플래닝 포커: 기능 시간 산정

스크럼 - 플래닝 포커

1. (JWT) 회원가입 + 로그인의 경우 - 이번 주에(쿤 아스피 포키)
   • 8 시간
2. email 중복 검사 확인(회원 가입 시) - loginid? email?
   • 1 시간
3. User 검색 목록 조회(ex. 아스피([email protected]) 처럼) - elastic search?
   • 회원을 닉네임으로 검색할 수 있다
   • 프롤로그 API를 레퍼런스로 삼는다
   • 13 시간
4. 마스터가 한명씩 출석 누를때마다 (제출할때마다) (서버에서 마감여부 확인)
   • 8 시간
5. 모임을 생성 API 변경 - Master 권한 분리(이번 Sprint에서는 모임 생성자가 데일리 마스터 유지)
   • 모임을 만드는 회원은 마스터가 된다
   • Meeting 생성시 참여인원에서 Master 뺀다.
   • 어떤 방에서는 마스터, 어떤 방에서는 아니다
     • (BE) 인터셉터 처리하는 부분 고민 필요
   • 13 시간
6. 로그인을 하면 해당 User가 속한 Meeting 목록 조회
   • 출석 가능 시간인지 확인하는 필드 추가 (출석 마감 or 출석 중)
   • 3 시간
7. 커피스택
   • 매 날짜마다 개인 지각을 표시하는 테이블이 필요함

이메일을 ID로 사용하는 이유

• 메일링할 때 편하기 때문

PR 전략

from ~ to	병합 방식
feature/** -> dev	Create a merge commit
dev -> main	Squash and merge