🧑🤝🧑팀원 소개🏆 프로젝트 목표✅ 커뮤니케이션 규칙기술 스택PR 템플릿이슈 템플릿PR 템플릿커밋 메세지 컨벤션브랜치 네이밍코드 컨벤션📌 코딩 스타일📌 코드 네이밍📌브랜치 룰ESLint/Prettier📌코드 리뷰 룰디렉토리구조
🧑🤝🧑팀원 소개
🚀 지휘/조절자(CO) 겸 팀장 김석주
🚀 완결자(CF) 김현주
🚀 추진자(SH) 박경빈
🚀 분위기 조성자(TW) 안재현
🏆 프로젝트 목표
공통목표
개인목표
김석주
김현주
박경빈
안재현
✅ 커뮤니케이션 규칙
- 배려는 default.
- 솔직한 자신의 의견 다 말하기.
- 너무 오랜시간 고민하다가 모르겠으면 질문하기(권장 30분 내외 고민).
기술 스택
언어 | TypeScript |
라이브러리 | React |
상태관리 | zustand, tanstack-query v5 |
번들러 | Vite |
스타일링 | styled-components |
협업 툴 | Notion, Slack, Discord, Github, Gather town |
API | MSW, Axios |
코드 포맷팅 | husky, eslint, prettier default |
Commit 규칙 | |
브랜치 전략 | Github Flow + dev 브랜치 추가, 브랜치 별 버전 명시 |
노드 버전 | node (20.10.0 LTS), npm(10.2.3) |
라우터 | react-router-dom |
배포 툴 | Vercel, Gabia |
분석 툴 | sentry, 구글 애널리틱스(기회 되면) |
PR 템플릿
회의록이슈 템플릿
# 📌간단한 기능 설명
# 📄Todo
PR 템플릿
# 📝작업 내용
# 📷스크린샷(필요 시)
# ✨PR Point
커밋 메세지 컨벤션
커밋 메세지 방식은 커밋 메세지 템플릿을 사용한다
################ # ✨feat : 새로운 기능 추가 # 🐛fix : 버그 수정 # 📝docs : 문서 수정 # ♻️refactor : 코드 리팩토링 (기능에 영향을 주지 않을 때) # 🎨style : 코드 스타일링 # 💄design : css 스타일링 (UI 변경점) # 🔧chore : 빌드 부분 혹은 패키지 매니저 수정사항 # 💡comment : 주석을 추가, 삭제, 변경하는 경우 # 🚚rename : 파일 혹은 폴더 이름 변경 # 🗑️remove : 파일을 삭제한 경우 ################ ################ # 본문(구체적인 내용)을 아랫줄에 작성 # 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내) # ===========바로 아래 공백에 작성하세요============ # ===========아래 공백은 지우지 마세요 (자동 생성 코드 분리를 위함)
브랜치 네이밍
#${issue번호}/${컴포넌트 명시}-${버전 명시} ex) #123/signUpPage-3.1.0
어차피 커밋 메세지로 구분되고 명시돼서 구분되기에 브랜치에서 feature을 고민할 필요는 없는데
지난 브랜치에 대해서는 어떻게 할 것인가?
merge되면 삭제하기로 하지만 만약 이 방식이 불편하다고 느껴질 경우 추후 조정
merge 방식!
멘토님에게 질문 rebase vs 일반 merge
코드 컨벤션
📌 코딩 스타일
규칙 | 설명 | 비고 |
풀네임을 사용하도록 한다. | btnX buttonO | ㅤ |
함수 표현식 사용 | 변수 혹은 타입
export const func = () => {}
컴포넌트, 페이지
const func = () ⇒ {}
export func | ㅤ |
src경로는 @를 사용합니다. | tsconfig.json, vite.config.ts 설정 필요 | ㅤ |
eslint, prettier 설정 | 순정 eslint, prettier 사용 | ㅤ |
주석여부 | 필요할 경우 함수 혹은 변수 정의 상단에 기입하기
main 브랜치에 병합시 모든 주석 제거
dev, feature브랜치에는 주석 유지 | 헷갈릴것 같은 부분에 주석이 있으면 좋다!
헷갈려서 주석을 쓴다! 남도 헷갈릴 수 있다! merge할때만 지우면 되지 않을까~
2가지로 사용, 헷갈림 방지 + jsDoc 사용, 유틸함수 같은 부분 사용
주석이 없는 코드가 클 린 코 드다.
나의 수준에서는 안달수가 없다..
일단은 남기는 걸로 하고 만약 PR리뷰에서 코드가 너무 좋다. 그래서 주석이 없어도 될 것 같다. 하면 그때 피드백
|
상수 관리 | constants 폴더에서 관리한다. | 페이지별 상수 관리 혹은 기능이나 컴포넌트 별로
공통 상수도 남기고, 페이지나 혹은 컴포넌트 내부에서 필요한 상수 분리해서 사용 |
스타일 상수 관리 | theme.ts 파일을 정의해서 사용한다. | ㅤ |
컴포넌트 export 방식 | 한 디렉토리 폴더에 있는 컴포넌트는 index.ts 파일에서 export 하도록 한다. | ㅤ |
type 선언 방식 | Default는 interface형식으로 선언, 사용 | type 사용 시 PR에서 이유와 함께 명시 |
함수 네이밍 규칙_세부항목 | onChange, HandleChange 이거 ㄹㅇ 모르겠어
커피챗 멘토님 답변 >> | 실제 핸들러 함수 → handleChange
Props로 받는 함수 → onChange
예시)
const handleChange = () ⇒ {}
…
<Component
onChange={handleChange}
/ > |
if문에서 중괄호 여부 | if(조건) {
setValue(true)
} | ㅤ |
singleQuote vs doubleQuote | singleQuote | ㅤ |
📌 코드 네이밍
상수 | 전체 대문자 + 스네이크 케이스 | TOTAL_USER = 3000 |
변수 | 카멜케이스 | ㅤ |
함수 | 카멜케이스, 동사를 처음에 작성 | 동사 + 명사
getValue, onChange … |
타입 | 파스칼 케이스 | type Post = { … } |
인터페이스(지향) | 파스칼 케이스 | interface PropsInterface { … } |
api | 카멜케이스, 동사를 처음에 작성 | createPost, deletePost |
폴더 & 파일 네이밍 | 최상단 폴더들 - 전체 소문자
컴포넌트, 페이지 - index를 제외한 파스칼 케이스 사용
hooks - use를 포함한 카멜 케이스
constants - index를 제외한 카멜케이스
routes - index를 제외한 파스칼 케이스 사용
types - index를 제외한 소문자
utils - index를 제외한 카멜케이스
styles - index를 제외한 카멜케이스
store - index를 제외한 카멜 케이스, 폴더 이름도 카멜 케이스 | index.ts or index.tsx 는 어디서나 소문자 |
스타일드 컴포넌트를 쓴다면?
그대들은 어떻게 할 것인가. | 기술스택에서 사용되는 코드에 따라 다름.
css-in-js << 너 성능문제 있자나~ | ㅤ |
📌브랜치 룰
git flow?
- main << 배포, 최종 병합용 브랜치 dev << 개발된 전체 병합 브랜치 개별 개발 브랜치 << 기능 개발 ing
- 브랜치를 영어로 작성한다.
- feature → dev → main 순서로 PR 진행
- 브랜치 예시) #${issue번호}/${컴포넌트 명시}-${버전 명시} ex) #123/signUpPage-3.1.0
Merge Rule
Merge시간을 어떻게 할 것인가?
코어타임 시작 후 프론트 스크럼에서 리뷰 후 Merge
PR 리뷰 시간
업로드 후 24시간 이내, 1차 리뷰 완료하기
늘 같지만 급한것은 항상 말하면서 소통!
Approve 권한 & 갯수
당사자가 할 것이냐 아무나 할 것이냐 → 어차피 같이 하니까 의미 X
Approve 2명 이상, 단 코드 리뷰 빡세게
깃허브 프로젝트를 써봅시다!
ESLint/Prettier
singlequote vs double quote
if문을 쓸때 한 줄이면 중괄호 제외? 아니면 무조건 써야한다?
eventHandler → onMove ? handleMove?
// prettier "endOfLine": "auto" // EOF 관련 처리 방식 "printWidth": 80, // 줄 바꿈 기준 "tabWidth": 2, // 탭 너비 "useTabs": false, // 탭 대신 스페이스를 사용할지 여부 "semi": true, // 세미콜론 사용 여부 "singleQuote": true, // 작은따옴표(') 대신 큰따옴표(") 사용 여부 "singleAttributePerLine" : true, // 속성 하나당 한줄씩 차지하게 설정 "bracketSpacing": true, // 객체 리터럴에서 중괄호 앞뒤에 공백을 추가할지 여부 "arrowParens": "always", // 화살표 함수 괄호 사용 방식 "trailingComma": "es5", eslint-plugin-import eslint-plugin-simple-import-sort
📌코드 리뷰 룰
불필요한 감정 소모와 시간 낭비를 줄여 효율적으로 코드 리뷰를 하기 위하여 Pn룰 채택
작은 PR 규칙뱅크샐러드의 코드 리뷰 문화가 성숙해지기 전에는 PR의 코드 라인 수에 대한 규칙이 없었습니다. 개발하는 기능의 복잡도에 따라 짧게는 코드는 수백 줄, 많게는 10,000줄 이상의 PR 이 만들어지기도 했습니다. 코드의 길이가 길어질수록 리뷰어의 집중도는 떨어질 수밖에 없었습니다. 코드를 이해하는 시간이 길어지고, 리뷰는 목표한 일정에 완료되지 못하고, 병목이 되기 시작했습니다. 코드 리뷰가 고객 임팩트를 내는 부분에 있어서 병목이 되지 않도록 ‘작은 PR 규칙’ (1개의 PR은 1,000 Line을 넘을 수 없다“) 을 정했습니다.‘작은 PR 규칙’ 도입 초기에는 “복잡한 기능을 만드는데 1,000줄은 너무 적은 것 아닌가?“, “테스트 코드도 라인 수에 포함해야 하는가?” 등의 원칙에 대한 의문과, 여러 개의 PR을 만들어야 하는 부분이 오히려 생산성을 떨어트리지 않을까 하는 우려도 있었지만, 이후 몇 차례의 코드 리뷰를 진행하면서 규칙을 구체화해 나가고 노하우도 쌓이기 시작했습니다. - PullRequest, Commit의 단위는 최소의 기능 단위로 세분화한다. - 테스트 코드는 Mock json 이 라인 수의 대부분을 차지하므로 제한을 두지 않는다. 코드 리뷰 문화가 성숙해가면서 우리는 리뷰 병목 해소와 조직의 확장성을 얻을 수 있었습니다. 모든 PR은 200 ~ 300줄 내외가 되고 1~2일 이내에 리뷰를 완료하여 리뷰의 병목을 해소할 수 있었습니다. 서비스의 성장과 함께 iOS 챕터의 구성원도 4명에서 8명으로 늘어났고, 개발되는 코드의 양(= PR의 양) 도 증가했지만 ‘작은 PR 규칙’ 아래 병목 없는 성장을 계속 해나가고 있습니다.
Pn 룰
- P1: 꼭 반영해주세요 (Request changes)
- 리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다.
- 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
- P2: 적극적으로 고려해주세요 (Request changes)
- 작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
- P3: 웬만하면 반영해 주세요 (Comment)
- 작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다.
- Request changes 가 아닌 Comment 와 함께 사용됩니다.
- P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
- 작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다.
- 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
- P5: 그냥 사소한 의견입니다 (Approve)
- 작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
LGTM, Look Good To Me << 약자 요게 이제 딱히 변경점 없을때~
디렉토리구조
/src │ App.tsx │ main.tsx │ /api | | /services | | /index.ts <- 공통 GPPDU | /assets | /components | | /common <- OK, 하지만 규칙을 어떻게 할 것인가! | /hooks | /constants | /pages | /types | /utils | /styles | /stores | /routes
