[main project day6] 아침 회의, 멘토링, 사용자 요구사항 정의서, sprint, issues 등록

브랜치명 컨벤션 결정

지난 주에 민환님이 프론트엔드와 백엔드의 브랜치명을 구분하여 관리하자는 의견을 주셨다.

• 프론트엔드: FE/feat/login
• 백엔드: BE/feat/login

pre-project에서는 프론트와 백엔드 구분하지 않고 feat/login 이렇게만 정했었는데, 프론트엔드와 백엔드를 구분하고 나니 각 브랜치가 같은 기능을 구현하는 경우에도 명확하게 구분할 수 있어서 더 좋은 것 같다.

브랜치명 접두사 정리

pre-project 때는 브랜치명 접두사를 기획단계에서 미처 정리하지 못했고, 다들 새로운 기능 추가하는 브랜치가 아닌데도 접두사에 일단 feat를 붙이고 보는 일이 생겨버렸다. 이번 main-project에서는 접두사를 케이스 별로 정리하여 PR 시에도 브랜치명 접두사에 브랜치의 기능을 명확히 나타내도록 했다.

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• refactor: 코드 리팩토링
• test: 테스트 코드 추가, 테스트 코드 수정
• chore: 빌드 업무 수정, 패키지 매니저 수정

주말 작업 진행 점검

• 프론트 초기셋팅 및 배포: 주말에 완료!
• 백 초기셋팅 및 배포: HTTPS로의 전환만 남았다고 하신다.
• 사용자 요구사항 정의서: 어제 아영님이 멘토링 때 사용자 요구사항 정의서 엑셀 표를 받아오셔서 오후에 같이 정리하고 채우기로 했다.
• 피그마 PC
• 피그마 모바일 반응형
• 플로우 차트
• 화면 정의서 (오늘 마무리 목표!!)
• API 명세서
• 테이블 명세서 + ERD
• 기술 발표 영상 (유튜브 URL, MP4 파일) (내일: 7월4일 → PPT 틀 짜기 목표!!)
• 서비스 매뉴얼(PDF 파일, PDF 파일이 임베디드 된 노션 URL) 윤곽 만들기 - 멘토링 때 추천? 혹은 피드백 받아보기

---

• 깃허브 wiki(아영 님, 명규 님)
• 칸반보드 + 이슈스 + 태그정보 (FE 와 BE 합 → 색깔 구분 // 가끔 볼 때마다 수정 해주세요)(아영 님,명규 님)
• cloudcraft (채연 님)
• README(마지막으로 미룸)

FE 멘토링

채팅 웹소켓

1대1 렌탈 거래 플랫폼이다보니 빠지면 곤란하지만 우리 쪽에서 구현이 가능할지 여부가 불투명해서 가장 걱정되는 기능이었다. 그래서 가장 먼저 질문을 드렸다.

• 프론트 쪽으로 찾아보면 라이브러리가 꽤 있다고 한다.
• 2가지 방법 존재
  • 웹소켓
  • polling
    polling은 웹소켓보다 구현이 쉽지만 여러 단점들이 있고 웹 소켓이 이를 보완한 기술이라고 한다. polling은 실시간 통신이 아니므로 채팅보다는 쪽지에 가깝게 구현할 수 있다고 한다.

그래서 우리도 웹소켓을 도전해보고 plan B로 polling 방식을 두었다.

회원탈퇴 버튼 어디에 둘까

닉네임 수정 -> 회원정보 수정으로 변경
회원정보를 수정하는 곳에 회원 탈퇴 기능을 넣는다.

완성도

-> 프로젝트의 기능이 다 돌아가는 상태
-> 만약 구현을 못했을 때 사용하는 사람이 미완성된거같다라는 것을 느끼지 못한다면 완성도가 높다고 생각한다.
미완성 된 것이 없는 것.
미완성 된 항목은 삭제

프로젝트에서 챙겨야 할 것들(부트캠프에서 이루고자하는 목표)
내 포트폴리오에 도움이 되는 것들
취업에 도움이 되는 어떠한 것.

사용하는 기술들 ( 취업공고 많이보기 )
- 최근에 어떤 것들을 쓰는 지
그러한 기술들에 대한 습득
프로젝트를 통해서 협업을 할 수 있는 사람이라는 것을 보여줘야함.
-> Git hub
->github 기능들을 잘 사용한다. 
(리드미 , 칸반보드 , 풀리퀘스트 리뷰를 잘 많이 하는 것)
잘못한 것에 대한 리펙토링 (회고)
블로그 정리
-> 겪은 문제점 
꼭 개발내용이 아니더라도 폴더구조 생성이라거나 등 겪은 점들 올리기

——

요즘트렌드 
cra 에서 vit , Natve 사용하는 것으로 변경되는 추세

데이터 패칭 -> 리액트 쿼리를 잘 쓰는 방법에 대해 고민하기
상대관리 도구 -> react toolkit
styled component

story book -> ui 테스트

사용한 이유들을 적기

컴포넌트 분리 잘하기

—

작업한 내용에대해 정리해서 멘토링때 이야기 했으면 좋겠다
pr리뷰 , 일정관리 잘하기

화면 정의서 작성

사용자 요구사항 정의서 작성

github milestone, issues 등록

처음에 사용자 요구사항 정의서를 보고 issues를 등록하기로 했었는데, 도메인 별로 되어 있어서 프론트에서 issues를 등록하는데 어려움이 있었다. 그래서 프론트에서는 페이지 별로 issues를 등록하는 것으로 변경.