• 매 주 금요일 경과 발표

  • Week 2 ~ 5
  • 데모? 세미나?
  • 아직 눈에 들어올 만큼 결과물이 나오진 않은 상태??

• 3주차 스프린트 Sprint 주요 목표

  • Week 2 에 목표한 것들을 Week 2에 다 하지 못해서 주말 및 Week 3에 넘겨서 하게 되었다.
  • 월요일 회의 때 이번 주에 어떤 것들을 할지 정함.
  • Week 3 목표 (이번주에 어디까지 했고, 어디까지 할 수 있을지?)
    • J034 민정님
      • 아이디 중복 API ✅
      • mock데이터 생성!!!!! ✅
      • 모집상세 페이지FE , BE 30% → ✅ 목표
      • 코스상세 페이지FE, BE 30% → ✅ 목표
        • 예상 작업 시간 10 이상
      • 검색 필터링 API 60%
      • 메인 페이지 API 🙅‍♀️ → Week 4
    • J171 수길님
      • 목데이터 생성 방식 Faker 튜토리얼 ✅
        • 작업이 완료되었다? 기준?
          • 개인의 목표를 채웠다면 완료.
          • gitlab flow
            • develop
              • feature
            • distribute(release, main) - 안정화 X
          • 작업이 완료 되었다. → develop → feature를 따서, 작업을 하고 git push 해서 PR을 올리고 (리뷰를 한다면 거치고) merge 해서 develop에 반영이 되는 것.
      • 코스 목록 페이지 30%
        • 퍼블리싱 ✅
        • API 연결 및 추가 UI 작업이 되어야 마무리가 되는 작업이다.
      • 무한 스크롤 ✅
      • 검색 API + 필터 API (일정 조율 필요) 60%
        • 예상 시간에서 가장 큰 비중을 차지
        • 기능적인 부분에서 난항을 겪고 있음
        • 다 같이 합의를 해서 진행, 공통 목표
      • 지도화면 캡처 🙅 → Week 4
        • 우선순위가 낮음.
    • J182 석준님 (BE)
      • class-validator & class-transformer 추가 ✅
      • interceptor 추가 → Week 4
        • 우선순위가 높지는 않다.
        • 개발적인 의미
      • 전체 목록 반환 API? 구현 ✅
        • 공통 영역 작업과 연관
      • 검색 API + 필터 API 60% → 이번주 중에 마무리 가능
        • 공통 작업 영역
      • 무한 스크롤 API ✅
    • J199 건님
      • 카카오 장소 검색 API 연동 ✅
      • 메인 페이지 퍼블리싱 + 기능 구현 ✅
        • carousel 컴포넌트 구현 ✅
          • react-slick

  ---

어려움

• conflict가 많이 남
  • 완성에 대한 기준이 달라서 완성 될 때 까지 PR을 안 날림.
    • (작게 쪼갤 수 있으면) PR 단위를 작게 여러차례로 나누어서 올리고 merge한다. 👍
    • (작게 쪼갤 수 없다) 큰 작업일 경우에는, 미리 팀과 충분히 합의를 하자.
      • A : Map.tsx 라는 컴포넌트에서 지도에 위치를 트래킹하는 기능을 구현 합니다.
        • 예상 소요 시간 : 10 (3일 이상)
        • A : Map.tsx 에서 작업을 하면서 주기적으로 작업 상황을 공유
        • B, C, D : 가능하면 Map.tsx와 의존성이 적은 파일을 건드리는 작업부터 우선순위를 높여서 하자.
        • PR merge 할 때는 A와 B, C, D 중에 한 분 이상이 같이 PR을 보면서 conflict가 났다면 같이 해결한다.
  • 완성에 대한 기준

    • BE - 테스트 코드 포함?

      로그인 API

      POST /auth/login

      req

      • 로그인 요청

      { "userId": "myid", "password": "p@ssw0rd" }

      ---

      res

      • 로그인 성공

      { "statusCode": 200, "data": { "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c", "userId": "abcd1234", "userIdx": 3, } }

      • 로그인 실패

      { "statusCode": 401, "error": "Bad Request", "message": "Your login request has failed" }

    • edge case, corner case

      • 유저가 비밀번호를 입력 안 하고 로그인 요청을 보내면?
      • 로그인 시도를 다섯 번 했는데 다 실패 한 경우 10분동안 로그인을 못 하게 한다.
  • A 50% 되고 B가 그걸 이어받아서 하는데, 서로 불편함.
    • 좋은 케이스는 아니라고 생각.
    • A가 큰 작업을 잘게 쪼개서 작은 단위로 커밋하고 푸시고 머지한다.
    • 500 lines
      • Task 1 (250 Lines) : A → develop에 merge
      • Task 2 (250 Lines) : 그리고 나서 이 작업을 git pull → 새로 feature branch (A, B)
  • SRP : Single Responsibility Principle
    • 커밋에서도 적용
    • commit log 보면서 장애가 났을 때, rollback, 일정을 변경해서 계획했던 것보다 적은 기능만 릴리즈를 해야 할 수도 있는데(cherry-pick) 커밋을 붙였다가, 뗐다가, 바꿨다가.