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) 모임을 생성한다

• (2-1) 회원 검색 쿼리

  • 회원을 닉네임으로 검색할 수 있다
  • 프롤로그 API를 레퍼런스로 삼는다
  • 13 시간

• (2-2) 마스터 권한 부여

  • 모임을 만드는 회원은 마스터가 된다
  • 어떤 방에서는 마스터, 어떤 방에서는 아니다
    • (BE) 인터셉터 처리하는 부분 고민 필요
  • 13 시간