Team Rule

작업 규칙

• 작업 시간: 월-토(오전 10시-오전 12시)
• 쉬는 시간: 작업중에는 2시간 마다 10분 휴식, 점심시간 12시-1시, 저녁시간 6시-8시
• 휴일: 일요일은 자율
• 회의 시간: 마일스톤 작성->매일 오전 10시, 코드리뷰->매일 오후 10시

커뮤니케이션 규칙

• 의견이 갈릴 경우 최소 30분 토의 뒤에 팀장이 최종 결정한다(물리👊🏻).

커밋 메시지 규칙

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

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

예시

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

1. 사용할 단어의 목록 (대문자로 작성)
   • ADD(기능의 추가)
   • FIX(에러 수정)
   • MERGE(병합)
   • REMOVE(삭제)
   • UPDATE(문서 파일을 수정)
   • REFACTOR(코드의 수정을 통한 리펙토링)
   • SIMPLIFY(코드 단순화)
   • IMPROVE(기능의 향상)
   • MOVE(코드의 이동)
   • RENAME(이름의 변경)
   • VERIFY(검증)
2. 동사 : 이후 짧게 내용을 적어주세요.
3. 필요한 경우를 제외하고는 동명사 대신 명사를 사용하세요.
4. 필요한 경우를 제외하고 관사는 사용하지 마세요.
5. 부정문을 사용할때는 Don't 를 사용하세요.
6. 전치사를 주로 사용하여 정확하게 어떤 부분을 수정한 것인지 명시하세요.

브랜치 이름 형식

종류	사용패턴	특징
master	master	프로덕션 스냅샷 가장 최신의 배포된 버전
dev	dev	개발 단계에서의 기본 브랜치
feature	feature/이슈번호-이름 feature/1-branch-name	dev에 병합

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를 첨부할 수도 있습니다.

❗ 이것은 꼭 지킵시다!

• PR 전 이유없는주석이나 console 등 지우자!
• PR 시 양식 통일 하자!
• img, btn, idx 등 변수명 줄여쓰지 말자!
• 함수 명은 무조건 동사로 통일하자!
• Boolean 값은 is(ex. isLogin)명사로 통일하자!
• 배포 주기는 feature 하나 합칠 때마다 다같이 하자!
• 논의되지 않은 새로운 스택 사용 하지말자!
• 혼자서 MERGE,PR 금지! 필요할 시 상의후 PR 하자!

💅 Front-end

• 스크롤바 항상보기 표시하자 !
• 반응형 디자인 신경쓰자 (ex. 미디어 쿼리) !
• 컴포넌트 이름 PascalCase로 통일 하자! (ex. WebDesign )
• 이미 디자인 가이드가 만들어져있는 CSS 프레임워크를 사용하지 말자! (ex. Material UI, Ant design, bootstrap)
• UX상 나쁜 디자인으로 평가받는 브라우저 내장 기능의 지나친 사용하지 말자!(ex. `alert, prompt, confirm)
• 콘텐츠가 존재하나 스크롤 할 수 없는 영역이 존재 하면 안된다!
• "스크롤바 항상보기" 옵션을 사용시, 불필요하게 스크롤바가 보임 그러므로 사용하지 말자!
• 데이터가 없거나 에러가 있을경우 안내가 나와서 명시적으로 보이게끔 하자!
• 로딩 실패 시 적절한 피드백을 제공 하자!
• 로딩 시 레이아웃이 깨짐 현상이 없게 로딩처리를 하자!
• 개발자 콘솔을 열었을 때 자바스크립트 에러가 발생하지 않게 하자!
• 로그인을 하지 않을 경우 일부 기능에 제한을 두게 만들자!

📚 Back-end

• 에러 메시지는 무조건 한글로 적자!
• 파라미터에 민감한 정보가 노출되지 않게 하자!
• EndPoint, DataBase Table 모두 단수 형식으로 통일 하자! (ex. number , list)
• 소셜 로그인 구현시 passport.js 사용을 하지 말자!

📂 API

• 리소스 CRUD시 목적에 맞는 HTTP 메소드를 사용하자!
• 리소스 CRUD시 엔드포인트에 동사를 사용하지 말자!
• 리소스 요청/응답시 필요한 json의 키/값 타입을 명시하자!
• 리소스 여러 개 조회 시 배열을 사용하자!
• HTTP 응답 코드의 사용이 적절하게 표시되게 하자!
• 응답 에러 메시지의 일관성이 있게 작성하자!
• 리소스 조회 시 json과 스키마 field간의 일관성이 있게 만들자!
• 리소스 생성 시 신규 아이디를 리턴하자!
• 사용자 정보를 필요로 하는 요청에 토큰 또는 세션을 사용해서 만들자!
• 특정 사용자와 연관된 리소스 조회시 권한 문제를 고려해서 만들자!
• JWT 사용시 헤더에 토큰을 전달하는 내용을 명시해서 만들자!
• 엔드포인트가 spinal-case (소문자와 대시 문자열) 를 따르게끔 만들자!
• GET 요청에서 쿼리 파라미터 대신 HTTP body를 사용하지 않고 만들자!
• HTTP body를 사용해야 하는 상황에서 쿼리 파라미터를 사용하지않고 만들자!

🔍 Schema

• 스키마의 1:N, N:M 관계가 적절하게 만들자!
• Join Table의 이름이, 관계있는 테이블 이름을 포함하게 만들자!
• 리소스의 CRUD에 필요한 테이블이 존재하도록 해서 만들자!

TASK CARD 예시

ISSUE

Group: client, server, sr

Type: bug, feature, delete

TODO

-[ ] Job1

-[ ] Job2

-[ ] Job3

Estimated time

Pick one

0.5h

1h

1.5h

2h

2.5h

3h

Labels

Estimated time: E: 1h

Group : client, server

Sprint: Sprint__NUMBER__

Urgency: High, Middle, Low

npm & node version 통일

• npm 8.1.0
• node 16.13.0