Rules

📒 Team Rules

업무 규칙

• 야근은 절대로 절대로 Never 안됨. (체력을 생각합시다.)
  • 같이 작업 마무리는 6시!
  • 만약 추가 작업의 경우 리미트 시간은 본인 재량으로 하되, 밤 11시는 넘기지 마시오!!!!!
  • 만약 오버할 가능성이 있는 경우는 이에 대해서 그 다음날 아침에 디스코드에 공유를 해주세요.
    • 이 때 자기 상황과 그 전날 작업 한 내용들을 공유 합니다.
• 깃허브 싱크는 무조건 같이 작업할 때만, 그 외에는 깃허브를 건들지 맙시다..
  • 이것의 경우에는 아침에 간략한 회의 후, 화면 공유해서 깃허브 싱크 맞추기 작업
  • 싱크를 맞춘 뒤, 각자 포크한 레포지토리에 푸시합니다. (git push origin dev로 최신 환경으로 맞춰주기)
• 머지는 항상 공동 작업 마지막 시간에!
• 작업 방식
  • 모각코처럼 화면 및 마이크는 전부 꺼두되, 만약 자잘하고 사소한 이슈 및 모르는 부분이 발생한 경우 마이크를 키고 말합니다! (집단 지성의 힘으로 난관 극복합시다!)
  • 점심시간은 시간표 대로 따라갑니다.

추가 공부 시간 및 주말 업무 관련

• 6시에 공동 작업 및 업무후, 팀 전체적으로 부족한 서버 부분 및 CSS 공부를 합시다. (개인의 재량에 맡기겠음!)
  • urclass 서버 부분 복습 (스프린트 코드 리뷰하는 것을 추천합니다)
• AWS 부분을 다시 돌아봅시다.
• 주말에는 모이지 않고 주중에 미처 다 못한 자신의 구현 업무를 하거나 위에 언급한 서버나 개인 공부(면접이나 코딩테스트 공부)를 합시다.

휴식 및 지각에 대한 규칙

• 휴식은 각자 알맞게 쉽시다.
• 지각을 할 경우
  • 10분까지는 기다립니다.
  • 10분을 넘기는 경우, 벌금 1000원 (누적제도 -> 늦으면 2000원으로 2^배로 기하급수적으로 늘 예정입니다.)
• 경조사가 생기는 경우에는 작업량을 줄이되 이 상황에 대해서는 디스코드에 이야기해주세요!
  • 화이자 백신의 경우 체력과 부작용을 고려해 작업량을 그날과 다음날까지 줄이세요.

갈등 해결

• 말하기 전 삼세번은 생각하고 말해봅시다.
• 만에 하나 갈등이 발생한 경우, 오붓한 삼자대면 혹은 전체 대면 시간이 있을 예정입니다.
• i 화법을 사용해 볼까요! (예시: 약간 너 때매 이러잖아가 아닌, 나는 이 때 기분이 나빴어, 왜냐하면 이러이런 것 때문에.)

2. 작업 규칙

주석은 꼭 달도록 하되, 짤막하고 간결한 설명으로 달아둡시다!

커밋 메시지 규칙

커밋 메시지는 제목과 본문으로 나누어 집니다. 한 줄만 작성해도 설명이 충분하다면 제목만으로도 괜찮습니다. 하지만 어떤 변경 사항이 있는지 맥락과 설명이 필요하다면 본문을 작성할 수 있습니다. 다음은 제목과 본문을 작성하는 규칙입니다.

• 제목과 본문을 한 줄 띄워 분리해 주세요.
• 제목은 영문 기준 50자 이내로 적어주세요.
• 제목을 모두 대문자로 적어주세요.
• 제목 끝에 . 는 금지합니다.
• 제목은 명령어로 작성합니다.
• 본문은 50자마다 줄을 바꿔주세요.
• 본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성하세요.
• 예시

FEAT: Add get data api function
!BREAKING CHANGE: change API arguments

FEAT : 새로운 기능에 대한 커밋
FIX : 버그 수정에 대한 커밋
BUILD : 빌드 관련 파일 수정에 대한 커밋
CHORE : 그 외 자잘한 수정에 대한 커밋
CI : CI관련 설정 수정에 대한 커밋
DOCS : 문서 수정에 대한 커밋
STYLE : 코드 스타일 혹은 포맷 등에 관한 커밋
REFACTOR :  코드 리팩토링에 대한 커밋
TEST : 테스트 코드 수정에 대한 커밋
FINAL: 최종 마스터 브랜치로의 PR

Lint 규칙

• semistandard 를 따릅니다.

주요 규칙

• space는 두 칸, 탭 사용 x
• 오직 single quote만 사용, 템플릿 리터럴은 표현식 사용할때만 사용하세요.
• var 는 사용하지 않습니다.
• 키워드 다음엔 스페이스 하나를 띄워주세요.
• 더 많은 정보는 https://standardjs.com/rules.html 를 참고하세요.
• 위 링크의 룰에서 오직 한 가지만 예외입니다. 세미 콜론 사용을 허용합니다.

브랜치 이름 형식

종류	사용패턴	특징
main	main	프로덕션 스냅샷, 가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature/이슈번호-이름, feature/1-branch-name	dev에 병합
hotfix	hotfix/이슈번호, hotfix/#911	메인에 병합

PR 형식

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

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

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

PR 제목
FEAT: Add get data api function => git 커밋 메시지 이 부분 그대로!

PR 본문
아래 형식을 복사해 Github Pull Request 의 템플릿으로 지정 후 해당 본문은 삭제하시면 됩니다.
### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

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

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

### 테스트 결과
ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.
Issue 형식
Issue 제목
[title] / body
아래 형식을 복사해 Github Issue 의 템플릿으로 지정 후 해당 본문은 삭제하시면 됩니다.
### Issue 타입(하나 이상의 Issue 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 상세 내용
ex) Github 소셜 로그인 기능이 필요합니다.

### 예상 소요 시간
-[] `0.5h`
-[] `1h`
-[] `1.5h`
-[] `2h`
-[] `2.5h`
-[] `3h`

### 라벨
- 예상 소요 시간: `E: 1h`
- 그룹: `client`, `server`
- 긴급도: `High`, `Middle`, `Low`

변수 이름 - Camel-case

clientLogin

파일 & 생성자 이름 - Pascal-case

ClientSide

node & npm 버전 통일

Node v16.13.0 NPM v8.1.0