Team Rule

회의 일정

시간	내용
09:00	오늘 일정 및 이슈 공유
13:00	중간 회의
17:00	코드 리뷰

• 중간 회의는 디스코드로 필요여부 확인 후 진행
• 매주 월, 목 저녁회의는 화, 금 KPT제출을 위한 회의

작업 및 휴식

• 당일 목표를 설정합니다.
• 목표 달성 시 개인시간을 갖습니다.
• 목표 미달성 시 개인시간을 투자합니다.
• 정해진 예상 시간을 1시간 이상 초과한 경우, 도움을 요청합니다.
• 개인 작업 중 휴식시간을 갖을 시 디스코드 상태를 변경합니다.
• 매주 금요일 주말 간 개인시간 사용여부를 결정합니다.

커밋 메시지 규칙

• 커밋 메시지 작성 양식은 행동 #이슈번호 변경내용 입니다.
• 커밋 메시지 첫 글자는 대문자로 작성합니다.
• 마침표를 사용하지 않습니다.
• ex) Add #2 landing page, Fix #5 pipeline

PR 형식

• 코드 컨벤션을 잘 지켜주세요. 컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋습니다.

• 리뷰 가이드라인을 잘 작성해 주세요. 모든 코드 변경사항에는 의도가 필요합니다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야 하고, 줄바꿈과 같이 아주 단순한 변경사항이라도 그 부분을 리뷰어가 볼 필요가 없다면 “Just line change” 와 같은 코멘트를 달아 명시하여 리뷰 시간을 줄여줄 수 있을 것입니다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법입니다.

• 작업중, 리뷰 가능 여부를 잘 명시해 주세요. 아직 코드를 작성 중일 때에는 [WiP] (Work in Progress) 를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed 태그를 설정할 수 있습니다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이 과정을 반복하여 명시해 주세요.

• PR 제목

[Client] / #88 / edit: readme

• PR 본문
• 아래 형식을 복사해 Github Pull Request 의 템플릿으로 지정 후 해당 본문은 삭제하시면 됩니다.

### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
ex) feat/login -> dev

### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

### 테스트 결과
ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.

Lint 규칙

• semistandard를 따릅니다.
• 오직 single quote만 사용, 템플릿 리터럴은 표현식 사용할때만 사용합니다.
• var 키워드는 사용하지 않습니다.
• 키워드 다음엔 스페이스 하나를 띄워 사용합니다.
• VSCode extension 중 하나인 Prettier를 사용합니다.

.prettierrc.json

{
  "singleQuote": false,
  "semi": true,
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 100
}

브랜치 이름 형식

종류	사용패턴	특징
master	master	가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature이슈번호/변경내용	dev에 병합

변수 이름

• Camel-case
• ex) camelCase

파일, 생성자 이름

• Pascal-case
• ex) PascalCase

node, npm 버전 통일

• node: 14.18.0
• npm: 7.24.2