Final Project SR 대면 피드백 정리 내용

SR 대면 피드백 내용

Wiki

• 리드미나 위키 상단에 줍깅의 의미(혁신적인)를 적어주기
• 웹 표준 적용
• 배포링크 상단에 첨부
• 선배포 진행 꼭!!! (세팅해서 헬로월드 띄우기) ⇒ 서비스 구현 될때마다 중간중간 배포(HTTPS 적용되는지)

Worklog

• 워크로그에다가 데브로그, 에러로그 적어서 넣는 것도 좋다.
  • 워크로그에 칸반보드 링크를 넣기
• Dev-log : 일정대로 소화하지 못했다면 그 이유도 남겨주기

Requirements

• 우선 순위에 따른 구분
• 우선 순위 순서로 진행하다가 시간 부족시 포기해야 할 기능 정리

Wireframe

• 프로토타입으로 디벨롭
• Figma에서 mockup 가능한지 체크하고 프토로타입 제작시 반영

Stack

• Architecture는 시스템 구조를 표현해줘야한다(흐름을 표시해줘야 함).

위클리 일정

• 일정 작성하는 것은 좋고, 지킬 수 있도록 노력해야함
• 중요도 순에 따라 세세한 일정/태스크 분배를 했으면 좋겠다.
• 태스크카드를 기획 단계에서 발행해주는 것이 좋다.(일정 계산에 도움이 됨)
• 작업시간을 충분히 고려하여 작성할 것(태스크카드를 의미있게 사용하기 위해서)
• 사이트에 필요한 페이지인데 구현을 못했다면, (아직 구현중입니다) 메시지 넣어주기

스키마

• DB 혼용 잘 생각해볼것
• Post, Like 관계테이블 따로 빼야함(Like: 누가 취소했는지 체크할 수 있도록)

API

• 로그인 리스폰스 JWT헤더 들어와야함
• 제이슨 형식 준수 ⇒ { “message” : “success logout”}
• 중요한 정보(비밀번호)는 response에서 빼야한다.(토큰에도)
• 유저 정보 조회 토큰(인증) 필요
• Description에 Not Null(required), Null(optional) 표시 필요
• 모임 조회 쿼리 (URL에 쿼리문 추가)
• 전체적인 리스폰스 추가(모어띵킹)
• 모임 참가 취소 ⇒ 권한을 어디서 가지고 있는지를 체크할 것 (추후 논의)
• ❗️res 에서 관계테이블 묶여있는 것 다 보내주는 것이 좋다. ⇒ 가공해서 사용
• OPEN API 예시를 잘 볼 것 ⇒ 실제 예시를 적용해서 res json 작성할 것
• Socket.io ⇒ 알람 (러닝하는데 오래걸릴 수 있음)
• 새로운 스택 배울때, 레퍼런스 서로 뿌리기
• 노드메일러 시간 별로 안들어가니까 구현할 때 같이 하면 좋을듯

---

• 캘린더 손이 많이 간다.(어차피 Advanced)

---

• 이슈카드 보면 #10 처럼 태그가 있는데 태그 맞춰주면 Task card 넘기면 자동으로 close 된다.