📜 협업 환경

🐣 Coding Convention

• 함수 표현식
• 파일 네이밍: components, pages: 파스칼 케이스, 그외는 카멜 케이스
• custom hook은 use로 시작하기

컴포넌트 내부의 이벤트 핸들러를 작성할때는 handle로 시작하고

function App(){
  const handleClick = ()=>{}
  <button onClick={handleClick}></button>;
}

상위 컴포넌트에서 받는 이벤트 핸들러는 on으로 시작

function App(){
  const doAnything = () =>{}
  <Button onClick={doAnyThing}/>;
}

function Button({onClick}){
  const handleClick = () =>{
    onClick && onClick()
  }
  <button onClick={handleClick}></button>;
}

한번의 PR에서는 최대 300줄까지 코드 작업 가능 브랜치 병합 전략 (의견1)

커뮤니케이션 비용을 줄이기 위한 Pn 룰을 적용하면 좋을 것 같습니다.

**(확정) 전역 상수 파일(index.ts)**을 사용합시다

✅ Coding Style

코드 네이밍

• 줄임말을 사용하지 않고 풀 네임을 사용합시다.
  • ex) btn ❌ button ✅
• 주석
  • 주석은 웬만하면 사용하지 맙시다.
  • 최대한 코드만으로 이해할 수 있도록 작성하는 게 좋을 것 같습니다!
• 상수
  • **constants 폴더를 만들고 내부에 전역 상수 파일(index.ts)**을 사용합시다.
  • 대문자 + 스네이크 네이밍 방법론을 사용합시다.
    • ex) TOTAL_DISCOUNT_ACCOUNT = 30000
• 변수: 카멜케이스. 명사를 사용합시다.
• 함수: 카멜케이스. 동사를 맨 처음에 작성하는 방식을 사용합시다.
  • ex) getValue , getRandomNumber , fetchUsers , onChangeInput , navigateToNextPage
  • 최대한 명확한 이름을 가질 수 있도록 작성해주세요!
    • 명확한 이름을 짓기 힘들다면 함수로 분리하는 것도 좋은 방법일 수 있습니다!
• 클래스: 파스칼 케이스를 사용합시다.
• 타입: 파스칼 케이스를 사용합시다.

  • type 키워드를 사용해서 타입을 정의합시다.(interface X)

    [TS] type과 interface의 차이

  • 재사용할 타입만 분리하여 전역으로 관리합시다.

    • 재사용 안하는 건, 각 파일의 최상단에 둡시다.
• CSS
  • rem 기준으로 작성합니다.

폴더 구조

• 일단 필수적이라고 생각되는 폴더들만 작성했습니다.
  • 추후 다른 폴더가 필요하다면 그때 추가하는 방식으로 진행하면 될 것 같습니다!

/src
│ App.tsx
│ main.tsx
│ /api
| /assets
| /components
| /hooks
| /pages
| /types
| /utils

경로

vite alias로 src는 @ 를 사용하도록 설정했습니다.

같은 폴더 위치라면 상대경로를 사용하고 그 외에는 절대경로를 사용합시다.

ex)

• import LoginButton from ./LoginButton
• import LoginButton from @/Login/LoginButton

브랜치 네이밍

타입/기능이름(카멜 표기법) 으로 작성하면 좋을 것 같습니다.

ex)

• refactor/login-button
• feature/login-button

파일 네이밍

components, pages: 파스칼 케이스

hooks: 카멜 케이스 - use prefix

utils: 카멜 케이스

api: 카멜 케이스

types: 카멜 케이스

develop merge 방식

PR올렸을 때 1명 이상 approve해야 merge 가능합니다!

코드 리뷰 방식

커뮤니케이션 비용을 줄이기 위한 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 뱅크샐러드 개발 문화 | 뱅크샐러드

<aside> 📌 참고: [GitHub] Git 브랜치의 종류 및 사용법 (5가지)

</aside>

💌 Git Commit Message

---

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

• 커밋메시지는 한국어로 작성
• 타입은 소문자로 작성
• init은 프로젝트 세팅 시 한정적으로 사용
• chore는 프로젝트 설정 변경 시 사용
• 작성 예시 : git commit -m 'feat: 로그인 버튼"

👩‍💻 Branch Rules

---

✅  작업 진행 순서

작업 진행순서

• 깃허브 이슈 생성

  1. new issue 클릭

     

  2. 이슈 목적에 따라 템플릿 선택

     

  3. 이슈 작성

     

     assigness : 해당 이슈를 누가 맡을지 선택 - 생성자 ≠ 작업자 (모르면 비워놔도 됌)

     label: 해당 이슈가 어떤 작업과 관련 있는가 - ex) feat, fix, refator…

     project: 오프팀 프로젝트 선택

     

     milestone: 이슈에 해당하는 스프린트 선택 (쉽게 말해서 1주차, 2주차, 3주차)

     

  4. submit new issue를 클릭해서 이슈 생성!

• 깃허브 이슈에서 브랜치 생성

  1. 이슈 클릭

     

  2. assign, project status 세팅 후 create a branch 클릭

     

  3. 브랜치 이름 변경

     • +기본적으로 default branch로 설정한 develop branch를 부모로 가진 브랜치가 생성됨
     • 만약 main이나 다른 부모 브랜치로부터 생성하고 싶으면 change branch source 클릭해서 수정)

     

  4. 명령어 프로젝트 터미널에 복붙 후 작업 시작~

     

• 작업 마친 후 PR

  1. pr 생성 - 지금은 변경사항이 없지만 나중에는 상단에 pr을 작성하라는 알림이 뜰 꺼임! 일단은 new pull request 클릭

     

  2. pr 작성

     1. close 에 관련된 이슈를 작성하면 PR이 merge 되면서 이슈도 같이 닫힘
     2. project status done으로 변경

     

  3. Merge 할 때 feature 브랜치도 같이 삭제 merge는 어떤 방법으로 할지 아직 상의 필요

Branch 전략

git flow 전략을 이용하되 release branch를 제거해서 사용한다.

각 브랜치 설명

Main 브랜치

Main 브랜치는 출시 가능한 프로덕션 코드를 모아두는 브랜치이다. Main 브랜치는 프로젝트 시작 시 생성되며, 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시해둔다.

Develop 브랜치

다음 버전 개발을 위한 코드를 모아두는 브랜치이다. 개발이 완료되면, Main 브랜치로 머지된다.

Feature 브랜치

하나의 기능을 개발하기 위한 브랜치이다. Develop 브랜치에서 생성하며, 기능이 개발 완료되면 다시 Develop 브랜치로 머지된다. 머지할때 주의점은 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 한다. 이렇게해야 히스토리가 특정 기능 단위로 묶이게 된다. - Squash 어떨까 ❓

Hotfix 브랜치

이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제를 해결한다. Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘다 머지한다.

✅  브랜치 공통 규칙

1. develop: 개발용
2. main: 배포용
3. 작업은 각자 브랜치 파서 작업합니다.
   1. main ← develop ← feature/기능/이슈번호
   2. main ← develop ← refactoring/기능/이슈번호

🐝 Pull Request(PR) Rules

---

논의 할 점

1. 브랜치 병합 전략

   

   1. Merge

      

      

   2. Squash and Merge

      

      

   3. Rebase and Merge

      

      

   참고: https://im-developer.tistory.com/182

   여러 의견들

   의견 1

   feature → develop 머지 Squash & Merge가 유용하다. feature 브랜치에서 기능을 개발하기 위한 지저분한 커밋 내역을 하나의 커밋으로 묶어 develop 에 병합하면서, develop에는 기능 단위로 커밋이 추가되도록 정리할 수 있다.

   또한 feature 브랜치는 develop 브랜치에 병합 후 제거하므로, Merge Commit 을 남길 필요가 없다.

   +기능 별로 커밋을 묶기 위해서는 merge나 squash 사용하도록 권장하는 듯

   develop → main 머지 main 브랜치는 지금까지 작업한 모든 기능을 배포할 때 병합한다. develop 브랜치를 squash & merge 하게 되면 커밋 이력이 모두 사라져, 특정 기능에서 문제가 생겼을 때 롤백할 수 없게된다. main 브랜치 또한 Merge Commit 을 남길 필요 없다. 따라서 Rebase & Merge 가 적합하다.

   의견 2

   팀이 실력이 아직 부족하다 느끼면, 이제 막 git으로 버전관리하는 법을 배우기 시작했다면 Squash and Merge가 좋을 겁니다.

   (정동환) 개인적으로는 의견 1이 괜찮다고 보는데 2도 상관없슴다

# 🐣 Coding Convention

---

(투표하고 갔으면 좋겠는 것) 함수 선언문 vs 함수 표현식 (둘 중 어떤걸 더 선호하시나요?)

(투표 요청)파일 네이밍 : 케밥 vs (파스칼+ 카멜), 만약 파스칼, 카멜이라면 각각 어느상황에서 사용할지

components, pages: 파스칼 케이스

hooks: 카멜 케이스 - use prefix

utils: 무슨 케이스? 가 좋을까요

api: 무슨 케이스? 가 좋을까요

types: 무슨 케이스? 가 좋을까요

camelCase! kebab-case!

(제안)

• 컴포넌트 내부의 이벤트 핸들러를 작성할때는 handle로 시작하고

  function App(){
  	const handleClick = ()=>{}
  	<button onClick={handleClick}></button>
  }

• 상위 컴포넌트에서 받는 이벤트 핸들러는 on으로 시작하도록 하는게 어떨까요

  function App(){
  	const doAnything = () =>{}
  	<Button onClick={doAnyThing}/>
  }
  
  function Button({onClick}){
    const handleClick = () =>{
      onClick && onClick()
  	}
  	<button onClick={handleClick}></button>
  }

(확정) PR 코드양을 어느정도로 할지도 결정하면 좋을 것 같습니다. (ex. 300라인)

(확정) 브랜치 병합 전략 (의견1)

(논의 요청) 커뮤니케이션 비용을 줄이기 위한 Pn 룰을 적용하면 좋을 것 같습니다.

**(확정) 전역 상수 파일(index.ts)**을 사용합시다

✅ Coding Style

코드 네이밍

• 줄임말을 사용하지 않고 풀 네임을 사용합시다.
  • ex) btn ❌ button ✅
• 주석
  • 주석은 웬만하면 사용하지 맙시다.
  • 최대한 코드만으로 이해할 수 있도록 작성하는 게 좋을 것 같습니다!
• 상수
  • **constants 폴더를 만들고 내부에 전역 상수 파일(index.ts)**을 사용합시다.
  • 대문자 + 스네이크 네이밍 방법론을 사용합시다.
    • ex) TOTAL_DISCOUNT_ACCOUNT = 30000
• 변수: 카멜케이스. 명사를 사용합시다.
• 함수: 카멜케이스. 동사를 맨 처음에 작성하는 방식을 사용합시다.
  • ex) getValue , getRandomNumber , fetchUsers , onChangeInput , navigateToNextPage
  • 최대한 명확한 이름을 가질 수 있도록 작성해주세요!
    • 명확한 이름을 짓기 힘들다면 함수로 분리하는 것도 좋은 방법일 수 있습니다!
• 클래스: 파스칼 케이스를 사용합시다.
• 타입: 파스칼 케이스를 사용합시다.

  • type 키워드를 사용해서 타입을 정의합시다.(interface X)

    [[TS] type과 interface의 차이](https://www.notion.so/TS-type-interface-4fafdde6d14e4b4593749864bf55b631?pvs=21)

  • 재사용할 타입만 분리하여 전역으로 관리합시다.

    • 재사용 안하는 건, 각 파일의 최상단에 둡시다.
• CSS
  • rem 기준으로 작성합니다.

폴더 구조

• 일단 필수적이라고 생각되는 폴더들만 작성했습니다.
  • 추후 다른 폴더가 필요하다면 그때 추가하는 방식으로 진행하면 될 것 같습니다!

/src
│ App.tsx
│ main.tsx
│ /api
| /assets
| /components
| /hooks
| /pages
| /types
| /utils

경로

vite alias로 src는 @ 를 사용하도록 설정했습니다.

같은 폴더 위치라면 상대경로를 사용하고 그 외에는 절대경로를 사용합시다.

ex)

• import LoginButton from ./LoginButton
• import LoginButton from @/Login/LoginButton

브랜치 네이밍

타입/기능이름(카멜 표기법) 으로 작성하면 좋을 것 같습니다.

ex)

• refactor/login-button
• feature/login-button

파일 네이밍

components, pages: 파스칼 케이스

hooks: 카멜 케이스 - use prefix

utils: 카멜 케이스

api: 카멜 케이스

types: 카멜 케이스

develop merge 방식

PR올렸을 때 1명 이상 approve해야 merge 가능합니다!

코드 리뷰 방식

커뮤니케이션 비용을 줄이기 위한 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 뱅크샐러드 개발 문화 | 뱅크샐러드](https://blog.banksalad.com/tech/banksalad-code-review-culture/)

📌 참고: **[[[GitHub] Git 브랜치의 종류 및 사용법 (5가지)](https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html)](https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html)**