1순위 태스크 정리

지난번 킥오프 때 말씀드렸던 기획을 바탕으로 에픽-스토리-태스크 단위로 쪼개서 정리를 해봤습니다. 현재는 가장 우선 순위에 해당 하는 스토리에 대해서 태스크를 나눠보고 정리를 하고 있습니다(Github 프로젝트에 동기화 진행 중)

태스크 목록 링크

0순위 스토리 태스크 정리
- 마일 스톤 추가하기
깃허브 프로젝트

https://github.com/orgs/boostcampwm-2024/projects/11
피그잼
- https://www.figma.com/board/aygt6qnDwDNRKkVbOdcNNo/Web08-피그잼?node-id=0-1&t=vaOTNjHmrziwtgrX-1

질문 거리

퍼널을 적용해서 퀴즈 풀이 과정을 관리하려고 하는데, 해당 퀴즈존에 대한 데이터를 세션 스토리지에 저장하는 것이 좋을 지 혹은 메모리(리액트 상태관리 등)에 담아서 처리를 하는 것이 좋을 지
고유아이디로 pin번호를 설정하려는데 uuid는 너무 길어 다른 짧은 고유 id생성할 방법 생각중입니다.
- URL에 pin번호를 uuid 36자리로 박는건 안되겠죠? 😉
- 시간?, nanoId, short unique id 등 이 있는 것 같더라고요..
서버와 클라이언트의 시간을 동기화하는 방법이 고민입니다.
- 클라이언트들이 모두 동일한 시점에 동작을 하기 위해
- 서버에서 기준 시간을 주면 클라이언트에서 서버에서 넘겨준 시간을 기준으로 동작하도록 하는 방안
  - 문제 풀이 대기에서 문제 풀이로 넘어가는 동작 등
- 대기실
  
  서버에서 시작 요청에대한 응답 완료 후
  
  문제풀이를 시작합니다. 잠시 대기해주세요
- 문제풀이
  - 문제풀이 완료 다른 사용자들이 문제를 모두 제출할 때 까지 기다려 주세요
- 시작(321)
  - 모든 사용자가 제출을 완료하면 남은 문제 풀이 시간과 별개로 다음 문제로 넘어갈 수 있도록 하는 것도 고려해야함.

정리

무엇을 만드는 것이 좋은 지에 대해서는 팀원들끼리 함께 얘기해서 정리하기
멘토님은 전체적인 내용에 대한 피드백을 위주로
멘토님이 나누셨던 단위랑 비슷하게 쪼갠 것 같음
멘토님이 구현 하실 때도 퀴즈 생성 하는 부분에 대해서 제대로 생각을 해봐야 됨.
UI를 1주차 안에 끝내야 될 지 → 이번 주에 디자인을 대충이라도 뽑아 내야 됨
데이터셋 → 세션 스토리지에 담으면? → 까볼 수 있음.
- 퀴즈 데이터에 대한 부분을 좀 더 고려해야 될 수도 있음.
- 퀴즈 문제에 대한 부분만 유출이 안된다면 다른 부분은 크게 상관이 없음
- 메모리에 담아도 크게 상관 없는 부분임.
- 편하신데로 하면 됨
- 세션 스토리지에 담는다면 전역 상태관리랑 별개로 정보를 불러올 수 있지 않을까?
- 유저 상태 변화에 대해서 어떻게 처리를 해야 될 지 → 전역 상태 관리로 넣어줘야 될 수도
  - 변할 수 있는 값이라면 상태관릴르 할 수 있는 걸 적용해야 됨
  - 유저 별로 바뀔 수 있는 데이터 값들이 많다면 상태관리를 적용을 해줘야 될 것 같음
- 다른 사용자들의 제출 현황도 보여주는 부분이 있기때문에 지속적으로 변경될 여지는 있음
- 나중에 테스트를 짤 때 전역상태를 어떻게 뽑아올 것인가에 대해서 고민을 해야 됨.
- 멘토님: 최상단에 결국 provider를 넣어줘야 됨.
  - 각 테스트 마다 초기에 넣어줘야 됨
  - 어떤 라이브러리를 사용하든 간에 크게 차이가 있음.
- 페이지에 진입 할 때 로드할 때 여부에 대해서 전역상태까지 갈 필요가 있을까?
  - 게임 페이지 내부에서만 돌긴 하니까
- 세션 아이디를 쿠키로 박아두는 걸 고려 하고 있어서 전역상태까지는 안해도 될 것 같다.
- 로그인이 2,3순위에 해당 하는 부분이라
- 퍼널이 뭔지
  - 단계적으로 이어지는 폼의 형식에 대해서 쉽게 관리할 수 있도록
  - 멘토님: 적용 하는 것 자체는 괜찮을 것 같음
    - 오버엔지니어링일 수도 있음.
  - 직접 만들 수 있는 부분이라서 가독성 있게 처리를 할 수 있도록 하면 될 것 같음
  - custom hook으로 만들기
고유아이디로 pin번호를 설정하려는데 uuid는 너무 길어 다른 짧은 고유 id생성
- 멘토님: 중복체크는 다 하실 거죠? → 당연히 해야 되는 부분이라고 일단 생각하고 있음
- 사용자가 pin 넘버로 퀴즈 존을 들어온다고 생각했을 때 uuid 기반으로 짧게 혹은 길게 사용을 할 지에 대해서 의견을 구하고 싶었음
  - 고유 아이디가 퀴즈 존 단위라면? → 크게 상관은 없음
    - 36자리는 좀 길 수도 있긴함
    - 시간에 대해서 만들어지면 동시에 만들어진 거에 대해서 체크를 하긴 해야 됨
    - 짧든 길든 취향으로 하면 될 것 같음.
  - 입력해서 들어간다면? 36자리는 너무길지 않나?
    - 멘토님: 이런 경우면 6자리나 8자리로 줄이는 게 맞음, 한글 단어 조합해서 만드는 방법도 괜찮을 것 같음. 짧게 강제로 만들어서 쓰는 것도 좋은 방법, 이게 퀴즈 존에 대한 부분이라서 다양한 방법으로 할 수 있을 것 같음. → 정책에 가까운 내용이라서
서버와 클라이언트 시간 동기화
- 멘토님: 클라이언트 시간은 다 조작이 가능함 → 무조건 서버에서 시그널을 줘서 넘어갈 수 있도록 하는 걸로 → 소켓으로 시그널을 줘서 처리를 하는 방식으로
  - 애초에 시간 계산 자체를 클라이언트에서 고려를 안해도 되도록
  - 클라이언트에서 뭔 짓을 할지 모르기 때문에
- 제출 우선 순위를 파악해서 등수를 매기도록 할 예정
  - 서버에서 기준 시간을 넘겨주고 그걸 기준으로 타이머를 설정 할 수도 있고, 제출이 얼마나 걸렸는 지도 측정할 수 있지 않을까?
  - 멘토님: 서버에서 클라이언트로 넘어올 때 결국 지연이 생길 수도 있고 시간 계산을 해줘야됨
  - 서버에서 시그널로 기준 정보 시간 더해서 보낸다거나 그런 방식을 더하는 식으로
  - 서버에서 제출한 시간 간의 차이로 할 수 있지 않을까? → diff를 떠야
    - 멘토님: 이거 자체는 나쁘지 않은 것 같음, 점수 공정을 위한 거니까
      - 서버에서 시그널을 보내고 이걸 체크하기 위한 과정을 확인 하는 방식
      - 서버에서 보내주는 시간
      - 조작이 가능할 수 있는 부분에 대해서 필수적으로 고려해야 될 것 같음.
- 멘토님: 만약에 동점자가 나오게 되면 정책은?
  - 동현님: 풀이 문제수, 점수, 시간 등을 해서 할 건데 만약에 그래도 동점자가 나온다고 하면 그건 동점자 처리를 해줘야 되지 않을까 싶음.