중급 프로젝트 시작 - 협업 컨벤션 정리

03.08(금) 중급 프로젝트 시작!

✨ 프로젝트 정보

이름 : 더 줄게(The-julge) - 나중에 변경하기로 함.
소개 : 급하게 일손이 필요한 자리에 더 많은 시급을 제공해서 아르바이트생을 구할 수 있는 서비스.
약간 알바천국 같은 느낌.

✨ 회의 내용

각종 컨벤션과 역할 분담을 했다.

1. 협업 툴

깃헙과 노션 슬랙 등등등 많은 툴을 왔다갔다 하면서 관리하는 것이 집중이 안된다는 의견이 있어서,

• 깃헙 : 일정관리, PR, Issue
• 디스코드 : 상시 소통
• 노션 : 프로젝트 마무리 후 문서 총 정리

이렇게 3개를 사용하기로 했다. 알고보니 깃헙에 위키, 일정관리 칸반보드 등 많은 기능이 있었다. 그 기능들을 적극 이용하기로 결정!

2. 컨벤션

각종 네이밍, PR 규칙 등을 정했다.

2-1. 네이밍 컨벤션

1. 줄임말을 쓰지 않는다. btn(x) button(o)
2. 변수, 함수 명은 길어져도 직관적이게 작성한다. (어떤 기능을 하는지 한 눈에 알 수 있게)
3. 모든 함수는 표현식(화살표 함수)으로 사용한다.

종류	방식
변수명	camelCase ex.userName="영희"
상수명	UPPER_CASE ex.REGULAR_SIZE="상수"
클래스명	tailwind 사용 (kebab-case) ex. <div className=kabab-case>
파일명, 폴더명	PascalCase ex. PascalCase.tsx
함수 네이밍 패턴	A/HC/LC 패턴
컴포넌트명	PascalCase 표현식 사용 ex. const Input = () =>
유틸 함수명	camelCase ex. getData = () => {}
유틸 함수 파일명	camelCase ex. getData.ts
확장자명	.tsx, .ts

2-2. 커밋 컨벤션

타입	용도
feat	새로운 기능 추가
fix	버그 수정
refactor	코드 리팩토링
style	코드 포맷, 스타일 변경
chore	작업 관리, 설정 변경
remove	파일 삭제
docs	문서 관련 작업
comment	주석 추가 작업

• type 뒤 띄어쓰기 없이 콜론(:), 콜론 뒤에는 띄어쓰기를 한다.
• 문장은 동사형 명사로 끝낸다. ex. 수정, 추가
• 특수 문자는 사용하지 않는다.
• type은 영어 소문자로, subject 텍스트는 한글로 작성한다.

3. Git 전략

개발 기간이 2주로 짧고, 인원이 4명이고 익숙하다는 의견이 있어 Github flow 전략을 사용하기로 했다.

브랜치	역할 규칙
main	배포 사용자들에게 배포하는 버전을 관리한다. develop 브랜치에서 merge한다.
develop	공동 개발 기능, 버그 수정 등 주요 기록들이 모여있다. feature 브랜치에서 merge한다.
feature	기능 구현 이슈 별로 브랜치를 생성한다. 브랜치명은 feature-{기능이름}-{상세내용} merge 후에 자동 삭제된다.

4. CSS

CSS-in-Js, CSS module 방식도 고려하였으나 새로운 방식을 경험해 보자는 의견을 반영해 Tailwind로 결정했다. Tailwind의 장단점은 다음과 같다.

장점

• 미리 정의된 클래스로 쉽고 빠르게 작성할 수 있다.
• 일관되고 유연하게 작성할 수 있다.

단점

• 초기 러닝커브가 높다.
• 클래스를 많이 사용하는 경우 코드가 길고 복잡해 보일 수 있다.
• 모든 프로젝트에 적합하지는 않다. 빠르고 간단해야 하는 프로젝트에 적합하다.

5. 폴더 구조

멘토링 시간에 멘토님께서 설명해주신 FSD 폴더 구조에 도전 해보기로 했다.

5-1. 기능 분할 설계(Feature-Sliced Design, FSD)

FSD 공식문서
번역 블로그

6. 기타 규칙

6-1. Export 규칙

1. 하단에 몰아서 하지 않고, export를 함수 바로 옆에 적기
2. 하나만 export 해야 하는 경우, export default를 쓴다.

6-2. Pull Request 규칙

1. PR은 템플릿에 맞게 내용을 작성해서 요청한다.
2. Assignees(본인), Reviewers(팀원 모두), Label, milestone을 모두 선택한다.
3. PR 시간대는 자유롭게 올리되, 상황에 맞춰서 어프로브를 요청한다.

6-3. Merge 규칙

1. Approve가 2명 이상일 때 merge 한다.

6-4. 코드리뷰 규칙

1. 코드 리뷰는 필수는 아니다.
2. 단, PR 요청자는 JsDocs를 필수로 작성해주고, 리뷰어는 JsDocs를 꼭 읽어본다.
3. PR 요청자는 상황에 맞게 리뷰어가 꼭 확인해야 하는 부분 항목을 작성한다.
4. 리뷰어는 PR 요청에 꼭 확인해야 하는 부분이 작성되어 있다면 필수로 코드리뷰를 진행한다.

✨ 종합

내가 맡게된 부분은 공고 리스트 페이지, 공고 상세 페이지와 관련 기능들이다.

개발을 하면서 오류와 해결방법, 새롭게 알게 된 부분들을 저장해 놓을 것이다!!!!