0. 각자의 FE 개발 및 협업 경험 공유
서로의 경험을 파악한 후 이후 논의에 고려해요.
1. 개발 환경 세팅
패키지 매니저
yarn vs npm✅ vs yarn berry
프레임워크 또는 빌드 도구
CRA vs Vite vs Next.js✅ vs ?
언어
JS vs TS✅
린트
- 도구
- ESLint + Prettier✅
- Stylelint
- commitlint
- 등
- 룰
- 미리 상세히 논의할 수도 있고 ✅기본적인 것만 세팅 후 필요에 따라 추가해나가도 됨.
- 검증 방식
- ✅Github Actions 활용 CI
- ✅husky + lint-staged
- 등
- 참고
폴더 구조
components
기본 라이브러리
fetch vs ✅axios, 리액트라우터돔, 스타일드 컴포넌트 vs ✅이모션, 상태 관리(Recoil, Redux, Zustand…), API 통신 및 비동기 데이터 관리(✅React Query, SWR…) 등 기본적, 전역적으로 사용하는 라이브러리 논의
* 상태 관리, API 통신 및 비동기 데이터 관리 라이브러리 ⇒ 필요할 때 도입 추천 (개인 의견)
어떤 방식으로 할 것이냐
- 한 명이 위 논의를 토대로 해온 후 피드백 받기 - 효율적
- 다같이 하기 - 팀원 모두 초기 세팅 경험이 부족하다면 학습에 도움
디자인 시스템
2. 컨벤션
코드 컨벤션
- 린트로 강제하는 것 외의 코드 컨벤션
- 만약 코드 컨벤션을 잘 지키고 싶다면 최대한 린트로 설정하는 것을 추천 ex TS 객체 형태의 타입을 interface로 선언할 것을 강제할 수 있는 ESLint 룰
- 어느 정도의 강도로 가져가고 싶은지 논의 하기
- 가독성만 좋다면 코드 스타일은 자유롭게!
- 한 사람이 쓴 코드처럼!
어떤 것들을 논의할 수 있나
- 변수 네이밍
- 명명법 ex 기본적으로 카멜 케이스, 컴포넌트 파스칼 케이스, 상수 어퍼 스네이크 케이스
- boolean 접두사 ex is 외에도 문법적으로 말이 되는 is can has 등 사용 vs 익숙한 is 사용
- 줄임말 사용 여부 (button vs btn, el vs element 등)
- 이벤트 핸들러 on동작 vs handle동작
- 스타일 컴포넌트 명시 여부 및 방식
- 등
- 컴포넌트 선언 방식: 함수 선언문 vs 화살표 함수
- setState를 바로 prop으로 넘겨주는 것을 지양하자
- svg와 같은 asset은 한 파일에 모아 export 하자
- 등
- 타입 네이밍 파스칼 케이스
- 기본적으로 카멜 케이스, 컴포넌트 파스칼 케이스, 상수 어퍼 스네이크 케이스
- 줄임말 X
- 자유롭게~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
커밋 컨벤션
(모두 개인 의견..)
- 구글링 하면 많이 나오는 가장 기본적인 방법으로 하거나 README 같은 곳에 명시하는 것을 추천
- 깃모지 - 가독성 좋아질 수 있고 예쁘고 커밋 히스토리 보면 기분 좋음
- 그러나 개인적으로는 나중에 까먹고 귀찮아서 후회했음
- 작업 효율을 위해 최대한 빠르게 완성할 수 있는 subject case 추천 ex FEAT → feat
feat chore refactor fix 등등..
의미에 맞게
커밋 단위 중요
참고
![[Git] 커밋 메시지 규약 정리 (the AngularJS commit conventions)](https://www.notion.so/image/https%3A%2F%2Fstatic.velog.io%2Ffavicon.ico?table=block&id=86c2d345-9b32-497a-bb9b-e1591c645391&cache=v2)
![[Git] 커밋 메시지 규약 정리 (the AngularJS commit conventions)](https://www.notion.so/image/https%3A%2F%2Fvelog.velcdn.com%2Fimages%2Foutstandingboy%2Fpost%2Fbb737678-1796-4778-bcb2-b407fab3460d%2FKakaoTalk_20200129_214020465_02.jpg?table=block&id=86c2d345-9b32-497a-bb9b-e1591c645391&cache=v2)
3. Git & Github 협업 룰
태스크 관리를 Github 이슈로 하며 적극적인 리뷰 문화를 장려하는 것을 전제로 함.
커밋 단위
고려할 만한 사항: 의미 있는 코드 단위, 본인이 작업하다 되돌아 갈 수 있다는 것을 고려한 단위, 나중에 해당 코드 변경 사항에 달린 커밋 메시지를 봤을 때 의아하지 않을 단위 등 (vscode gitlens)
이슈
- 이슈 단위
- 최대한 잘게 나누기
- 원활한 코드 리뷰를 위하여
- 애자일 협업을 위하여
- 누가 봐도 무슨 업무인지 알 수 있도록 명확하게 작성하기
- 이슈 템플릿 만들기
브랜치 전략
main ← 이슈 단위로 브랜치 따서 작업 후 머지
브랜치 네이밍
feat/#이슈번호 
Pull Request
- 이슈 개발을 마친 후, 메인 브랜치에 머지하기 전에 거치는 소통 과정
- 코드 리뷰를 달아줄 팀원을 배려하며 작성해야 함
- 글 명확하게 쓰기
- File Changed 개수 ≤ 15 추천 ..
- 애초에 이슈를 제대로 분리
- 좋은 PR 메시지?
- 스키밍 하기 좋은 글
- 코드에 코멘트를 직접 다는 것이 나을 수 있음
- PR 템플릿 만들기
- 팁:
- close #이슈번호라고 쓰면 PR 닫힐 때 해당 이슈도 함께 닫힘
- 어떤 것을 구현했는지 요약/어떻게 구현했는지 설명
- PR Point (우려되는 점, 집중해서 봐주었으면 하는 점 등)
- 구현 결과 스크린샷
리뷰
- 리뷰 룰 - pn 룰
- 팁
```suggestion```tsx- 최대한 한번에 모아 달기 Start a review
- 초급: 코드 컨벤션 위반한 부분, console.log(), 큰 일을 일으킬 것 같은 부분
- 고급: 코드 구조, 더 괜찮은 구현 방법 제안 ex 에러 처리 로직과 메인 로직을 분리할 방법, 리렌더링을 줄일 방법 등
- 너무너무 좋은 글 - 코드 리뷰 in 뱅크샐러드 개발 문화
리뷰가 어려워서 정했던 룰
- 리뷰 짝
- 10,11 - 규란-주영, 승훈-은아
- 12,13 - 규란-승훈, 주영-은아
- 14,15 - 규란-은아, 주영-승훈
- 16,17 - 규란-주영, 승훈-은아
- 18,19 - 규란-승훈, 주영-은아
- 리뷰 짝은 필수, 그 외는 최대한 모두 해주기 또는 크리티컬한 것만 찾아내주기
머지 방식
- PR을 거치지 않은 머지 가능 여부
PR 머지 방식
- 머지 룰
- approve를 몇 명 이상에게 받아야 머지 가능
- deploy 통과돼야 머지 가능
- 등 repo에 설정 가능
- 리뷰 짝의 어프루브 필수
- 빌드 테스트 통과 못 받으면 절대 머지 X
기타
- 깃허브 액션, 위키, 디스커션, 마일스톤, 프로젝트 등
4. 문서화
- 개발 일지, 논의 과정, 개발 담당 등
- 문서화의 끝판왕이라 생각하는 프로젝트 소개 Readme, wiki
