Portfolio

🧑‍🤝‍🧑팀원 소개 🏆 공통 목표 🛠️기술 스택 🚀코딩 컨벤션 📌 코딩 스타일 📌코드 네이밍 📌브랜치 네이밍 📌파일, 폴더 구조 및 네이밍 📍세부사항 📌스타일 네이밍 📌브랜치 구조 및 Merge 규칙 📌코드 리뷰 룰 📌커밋 룰 🎀ETC

🧑‍🤝‍🧑팀원 소개

✨최고 운영 책임자 COO 겸 팀장 김석주

✨최고 지식경영 책임자 CKO 신수영

✨최고 기술 책임자 CTO 오원주

✨최고 관리 책임자 CAO 황민호

🏆 공통 목표

화려하고 멋진 기술이 아닌 핵심 기능을 커뮤니케이션을 잘 하면서 완성하는 것을 목표로 한다.

🛠️기술 스택

언어	TypeScript
라이브러리	React
상태관리	Redux-toolkit, Tanstackquery
번들러	Vite
스타일링	css, styled components, tailwind UI
협업 툴	Notion, Slack, Discord, Github
API	axios
코드 포맷팅	eslint, prettier, airbnb Rule
Commit 규칙	https://www.notion.so/1bb7b196eadb467bbd249b6a97f23cdf?pvs=4#881d2369358e4b3184b0612b0bd15ed1
브랜치 전략	Git Flow
노드 버전	node (20.10.0 LTS), npm(10.2.3)
라우터	react-router
배포 툴	Vercel, Gabia(도메인)

🚀코딩 컨벤션

📌 코딩 스타일

규칙	설명	비고
풀네임을 사용하도록 한다.	btnX buttonO	ㅤ
함수 표현식 사용	변수 혹은 타입 export const func = () => {} 컴포넌트, 페이지 const func = () ⇒ {} export func	ㅤ
src경로는 @를 사용합니다.	tsconfig.json, vite.config.ts 설정 필요	ㅤ
함수 네이밍 규칙_세부항목	prop -> onChangeHandler func -> handleChange init, props 같은 약속된 축약어 허용	5어절 이상이면 PR시 의논
eslint, prettier 설정	airbnb 기반 설정, 필요한 경우 airbnb 기반에 추가로 설정	ㅤ
css 단위는 rem으로 통일한다.	ㅤ	px
주석여부	필요할 경우 함수 혹은 변수 정의 상단에 기입하기 main 브랜치에 병합시 모든 주석 제거 dev, feature브랜치에는 주석 유지	ㅤ
상수 관리	constants 폴더에서 index.ts 파일로 관리한다.	ㅤ
스타일 상수 관리	styles 폴더에 theme.ts 파일을 정의해서 사용한다.	ㅤ
컴포넌트 export 방식	한 디렉토리 폴더에 있는 컴포넌트는 index.ts 파일에서 export 하도록 한다.	ㅤ
type 선언 방식	ㅤ	ㅤ

📌코드 네이밍

상수	전체 대문자 + 스네이크 케이스	TOTAL_USER = 3000
변수	카멜케이스	ㅤ
함수	카멜케이스, 동사를 처음에 작성	getValue, onChange …
타입	T + 파스칼 케이스	type TPost = { … }
인터페이스	I + 파스칼 케이스	interface ISomeInterface { … }
ㅤ	유니언 타입을 사용해야하는 경우에만 타입을 사용하고 이외는 Interface를 지향한다.	ㅤ
api	원주님 케이스 _(대문자)	간★지 ex) _GET

📌브랜치 네이밍

main, dev, feature브랜치

ex) feature/login → dev → main 순서로 PR 진행

브랜치 명은 영어로 작성한다.

기능명세서에 브랜치 명을 정의하고 사용한다.

예시) feature/login-password-0.2.0 feature/main-sub-ver

📌파일, 폴더 구조 및 네이밍

components, pages	파스칼 케이스	ㅤ
hooks	use + 파스칼 케이스	useHover.ts
utils	카멜 케이스	ㅤ
api	카멜 케이스	api/rootAPI.ts /queries login.ts getUsersList.ts
types	index.ts에 export형태로 선언 ㄴ 이후 복잡해지면 회의 후 분리 수정사항(옵셔널체이닝 등) 있을 시엔 미리 공지하기	interfaces/ pageInfo.interface.ts


/src
│ App.tsx
│ main.tsx
│ /api
| /assets
| /components  
| | /Login -> 고유한 컴포넌트 (단일 페이지 내에서 사용)
| | /common -> 복수 페이지에서 사용, 다른 컴포넌트에서 사용되는 컴포넌트
| | | /Layout
| | | /Navigator
| | | /Post
| | | | /modules
| | | | | /PostPhotoBox
| | | | | /PostContentBox
| | | | | /PostCommentBox
| | | | | /index.ts
| | | | /Post
| | | | /index.ts
| | | /Card
| | | | /Card.styles.ts
| | | | /Card.tsx
| | | | /index.ts
| | | /Header
| | | /Button
| | | /Avatar size={size : S M L X?} 
| /hooks
| /constants
| | /index.ts //길어지면 분기
| /pages
| | /profilePage/Post
| | /postPage/Post
| /types
| | / index.ts
| /utils
| | /유틸리티 함수 
| /styles 
| | /Theme.ts
| | /GlobalStyle.ts

📍세부사항

컴포넌트 내부 파일은 재사용 여부에 따라 common 인지 아닌지 나눔, 두 번 이상 재사용시 common 폴더 내부에서 선언, 사용

폴더 내부 파일을 나눠야 할 경우, 위에 Post예시를 따른다. 단 이때 나누는 기준에 대해서는 그때그때 판단하여 진행한다.

📌스타일 네이밍

컴포넌트 단위인 경우 컴포넌트명 + 스타일명 ex) PostCardContentText, PostContainer global인 경우 스타일명 ex) TitleText, Row, Column

📌브랜치 구조 및 Merge 규칙

신속하고 빠른 개발을 위해 GitHub Flow에 dev 브랜치를 추가하는 형식으로 브랜치 구조를 만들어 진행한다.

Merge 규칙

주말제외, 평일 19시 이전에 올라온 PR은 당일 리뷰하고 Merge하는 형식으로 한다.

만약 Conflict가 나거나 Approve가 2개 미만일 경우 익일 해당 문제점 해결 후 Merge하도록 한다.

📌코드 리뷰 룰

불필요한 감정 소모와 시간 낭비를 줄여 효율적으로 코드 리뷰를 하기 위하여 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에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

안녕하세요, 뱅크샐러드 BanksaladX iOS Engineer…

https://blog.banksalad.com/tech/banksalad-code-review-culture/

📌커밋 룰

Git Conventionalcommits 의 내용을 기반으로 구성

Type	내용
feat	새로운 기능 추가
fix	버그 수정 또는 typo
refactor	리팩토링
design	CSS 등 사용자 UI 디자인 변경
comment	필요한 주석 추가 및 변경
style	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
test	테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우)
chore	위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets image, 패키지 매니저 등)
init	프로젝트 초기 생성
rename	파일 혹은 폴더명 수정하거나 옮기는 경우
remove	코드, 파일을 삭제하는 작업만 수행하는 경우
docs	문서를 추가하거나 수정하는 경우