Skip to content

Team Rule

Jump to bottom
dddtttt000 edited this page Oct 28, 2021 · 11 revisions

Team Schedule

시간 내용
09:00-09:30 Issue Card 정리
09:30-10:00 전날 완료 업무 및 금일 진행 업무 공유
12:00-13:30 점심
18:00-20:00 저녁
20:00 포지션별 Code Review

* 주말에는 가급적 연락을 자제하고 자율적으로 작업한다.
* 이슈 카드 작성 여부 메세지를 팀 채팅에 올린다.

Communication

  • 서로 반말을 삼가고 존댓말을 사용한다.
  • 상기 Team Schedule의 절차를 준수하되 피치 못할 사정이 발생 시 사전에 디스코드로 글을 남긴다.
  • 의견대립이 있을 시 그 이유에 대해서 상세히 설명하여 상대방을 설득시키도록 노력해야 한다.
  • 의견 대립으로 인하여 갈등이 해결되지 않는 경우 시간을 두고 각자의 생각을 정리하여 다시 회의를 진행한다.

Commit Message Rules

커밋 단위

메서드 리팩터링이나 새로운 메서드 또는 클래스를 추가할 때마다 커밋한다. 실험이나 성능 튜닝을 할 때도 각 단계별로 커밋한다. 소스 코드 변경 내역이 없을 때는 커밋하지 않는다.

커밋 메시지는 제목, 본문(선택) 두 부분으로 작성한다.

  1. Type: 제목(Title) 커밋 메시지 제목은 docs: Edit README.md to include New Features Use-Cases 와 같이 작성한다.

제목은 타입 라벨을 맨 앞에 붙어 타입(Type): 제목 형식으로 작성한다. 각 타입 라벨은 아래와 같다.

  • feat: 새로운 기능을 추가할 경우
  • fix: 버그를 고친 경우
  • docs: 문서 수정한 경우
  • style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
  • refactor: 프로덕션 코드 리팩터링
  • test: 테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 없음)
  • chore: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)

제목의 처음은 동사 원형으로 시작하고 첫 글자는 대문자로 작성한다. "Fixed", "Added", "Changed" 등 과거 시제가 아닌 "Fix", "Add", "Change"로 명령어로 시작한다. 총 글자 수는 50자 이내며 마지막에 마침표(.)를 붙이지 않는다.

  1. 본문(Body) // 선택 본문은 커밋의 상세 내용을 작성한다. 제목과 본문 사이에 한 줄 비운다. 본문은 한 줄에 72자 이내로 작성한다. 한 줄을 띄워 문단으로 나누거나 불렛을 사용해 내용을 구분한다.

예시

feat: Summarize changes in around 50 characters or less
docs: Add some codes
Type Description
FIX 올바르지 않은 동작을 수정
ADD 코드나 테스트, 예제, 문서 등의 추가
REMOVE 코드의 삭제
USE 특별히 무언가를 사용해 구현
REFACTOR 전면 수정
SIMPLIFY 복잡한 코드를 단순화
UPDATE 개정이나 버전 업데이트
MAKE 기존 동작의 변경
REVISE 문서의 개정
CORRECT 문법의 오류나 타입의 변경, 이름 변경
MOVE 코드의 이동
RENAME 이름 변경
VERIFY 검증 코드
SET 변수 값을 변경하는 등의 작은 수정
PASS 파라미터를 넘기는 처리

Lint 규칙

  • semistandard 를 따릅니다.
  • Prettier 를 사용한다. (.prettierrc 파일 생성)

주요 규칙

  • space는 두 칸, 탭 사용 x
  • 템플릿 리터럴은 표현식 사용할때만 사용하세요.
  • 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 제목

[Client] / edit: readme
  • 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
  • NPM v7.24.0
  • React 제일 최신버전

Clone this wiki locally