컨벤션 정하기

네이밍 컨벤션

[x] 레포 이미 정해짐
[x] 브랜치 - Branch 전략에 따라 정해짐

[x] 폴더 구조

├── .expo
├── android                #  Android 구동에 필요한 파일들 (수정할 필요 없음)
├── ios                    # IOS Native 구동에 필요한 파일들 (수정할 필요 없음)
├── node_modules           # npm 패키지
├── src
│   ├── assets             # 이미지, 폰트, 로고 등
│   ├── components         # 컴포넌트
│   ├── pages              # 페이지 단위
│   ├── utils              # 자주 사용하는 함수
│   ├── hooks              # custom hook
│   ├── api                # api
│   ├── theme              # color 정의
├── .gitignore             # Git 설정 (레포에 올리지 않을 파일들)
├── .prettierrc.js         # Prettier 설정
├── .cz-config.js          # commitzen 설정
├── App.js                 # Entry 파일
├── app.json               # 앱 구성
├── babel.config.js        # Babel 설정
├── metro.config.js        # metro 설정
├── package.json           # package.json
└── yarn.lock

폴더 및 파일 이름은 케밥 케이스 (ex, home-page)

[x] 메서드 - 카멜 케이스 (ex, onClickHandler) 컴포넌트 - 파스칼 케이스 (ex, VoteTab)

규칙을 강제할 수 있는 시스템을 만들자
1. 코드 형식
  1. Prettier
```
{
  "trailingComma": "all", // 객체나 배열 작성 시 데이터의 마지막에 후행쉼표 사용
  "semi": true, // 명령문 끝에 세미콜론 추가
  "singleQuote": true, // 작은 따옴표 사용
  "bracketSpacing": true, // 객체 리터럴 괄호 안에 공백 넣음
  "arrowParens": "always", // 화살표 함수 사용 시 파라미터 소괄호 사용
  "bracketSameLine": false, // >를 다음 줄로 내려서 사용
  "tabWidth": 2, // 들여쓰기 공백 수 2칸
}
```
    참고
2. Git commit message format
  1. git hook
  2. Commit Convention
    
    Feat, Fix, Design, HoxFix, Style, Refactor, Comment, Docs, Test, Chore, Rename, Remove
3. branch 전략
  
  대표적으로 Git Flow 전략과 Github Flow 전략이 있는데
  
  Git Flow는 브랜치가 많아 복잡하고, 쓰기 애매한 브랜치들이 있다.
  
  짧은 기간동안 빠른 개발과 배포를 해야하는 입장에서는 Github Flow와 같이 단순한 흐름으로 가져가도 괜찮다고 생각한다.
  
  Github Flow의 특징으로 전략이 단순하다.
4. PR template
  1. README: [x] DoD 정의
  2. PR을 하는 이유는 branch를 Merge 하기 위함도 있지만, 코드 리뷰를 받기 위해서이다. 팀원 간의 코드 스타일을 맞출 수 있고, 발견하지 못한 위험도 발견할 수 있다. 따라서 코드 리뷰를 해주는 리뷰어를 위해 PR 단위와 내용이 중요하다.
  3. 좋은 PR을 하기 위해서는 내용만 보고도 변경 사항에 대해 이해할 수 있어야 하고, 필요한 부분에 대해서 명시해주는 것이 중요하다.
  4. 뱅크샐러드 예시
    
    https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https://blog.kakaocdn.net/dn/HIvSv/btrj0V1pRX3/1Tsi2Y47LcNSr7zMF5hcek/img.gif
    - 무슨 이유로 코드를 변경했는지
    - 어떤 위험이나 장애가 발견되었는지
    - 어떤 부분에 리뷰어가 집중하면 좋을지
    - 관련 스크린 샷
    - 테스트 계획 또는 완료 사항
```
## What is this PR?
- 
<br/>
## Key Changes
- 
<br/>
```
리뷰
1. 변경을 제안할 때는 이유와 함께 제시하기
2. 참고할 수 있는 레퍼런스를 알고 있다면 같이 제공하기 (코드 가이드라인 제공 가능하면 좋음)
3. 질문도 리뷰가 될 수 있다.
4. 모든 PR에 대해 리뷰를 할 필요가 있을까?
  1. PR을 등록하는 사람이 리뷰가 필요할 때 요청하는 건 어떨까?
  2. 그러면 모든 PR에 대해 리뷰 하지 않아도 되고, 코드 리뷰로 인해 병목 될 가능성도 낮추고, 리뷰가 필요해서 요청한 것이므로 유의미한 리뷰가 될 확률이 높아지지 않을까?
5. 불필요한 리뷰를 줄이기 위해서는 컨벤션 확립과 코드 일관성이 유지되어야 한다.
https://jbee.io/essay/code-review-goal/
Commit 단위
1. 커밋은 수시로 하는게 좋지 않은가?
CI/CD 기반, 프로젝트 자동 배포로 실행 가능한 상태 유지
1. Github Actions
테스트 코드
1. 테스트 작성하면 좋지만… 프론트는 도입하기 힘들 것 같습니다.

참고

폴더구조