Team Rule - codestates/JISIK-SPONSOR GitHub Wiki

🎯 Team Goal

본 프로젝트를 통해,

🔥 지금까지 배웠던 내용들을 '충실' 하게 복습하고 '충분' 하게 반영하여 함께 계획한 기능들을 완성도 있는 파이널 프로젝트로 구현하고자 합니다.

🔥 퍼스트 프로젝트를 진행하면서 느꼈던 팀 차원의 회고 및 차후개선책을 반영하여 파이널 프로젝트를 한땀 한땀 최선을 다해 만들어봅니다.

🔥 결과도 중요하지만 그 과정 자체를 즐기며 팀 차원에서 서로 보완하고 시너지를 낼 수 있는 방법을 고민합니다.

🔥 모두가 윈윈 할 수 있는 역할 배분 및 포트폴리오 작성을 통해 올해가 가기 전에 팀원 전원 취뽀에 성공 합니다. 😁🙏

🔮 Team Rules

🙆‍♂️ To Do

• 항상 존중과 배려를 기반으로 다른 팀원들의 말을 경청하며 원활하게 의사소통 하도록 노력합니다.
• 회의 진행 시, 최대한 솔직하게 자신의 의견을 전달하되 다른 팀원들을 존중하며 소통합니다.
• 만약 팀원들 간 이견이 발생 시 의사결정은 다수결로 진행합니다.
• 개인적 차원을 넘어 팀 차원에서 함께 시너지를 내며 걸어갈 수 있는 방법을 고민합니다.
• 자신에게 맡겨진 임무를 책임감있고 성실하게 수행합니다.
• 건강 문제 등 부득이한 상황 발생 시 사전에 팀원들에게 사정을 알리고 양해를 구합니다.
• 프로젝트 진행 기간, 합의된 스케쥴을 최우선순위에 두고 전체 미팅 및 공동 작업에 참여합니다.
  • 주중 & 일요일
    • 9:00 am - 스크럼(약 10 - 15분 소요) 미팅 → 하루 동안 각자 할 일을 팀과 나눕니다.
    • 6:00 - 8:00 pm- 저녁 식사 및 자율시간(운동, 산책, 휴식 등)
    • 10:00 pm - 전체 리뷰 회의 → 하루 동안 작업한 결과물을 나누고 코드 리뷰 및 내일 할 일에 대해 공유합니다.
  • 토요일
    • 오전 일과 → 자율적으로 프로젝트와 관련한 작업을 수행합니다.
    • 오후 일과 → 일주일 동안 쌓였던 스트레스를 풀고, 충분한 휴식 및 여가 시간을 가집니다.
• 프로젝트를 위해 정신과 육체를 건강하게 유지하도록 노력합니다. 컨디션 관리도 실력이라는 사실을 기억합니다.
  • 최소 수면시간(6hr), 식단 조절, 작업 상한선 설정(3 am) 등을 준수합니다.
• 진행 상황을 지속적으로 공유하고, 매일의 작업 내용을 꾸준히(daily/weekly) 기록합니다.

🙅‍♀️ Not To Do

• 기본적으로 위에 규정된 TO-DO와 반대되는 언행을 지양합니다.
• 문제가 생기면 너무 오래고민하거나 부끄러워하지말고 팀원들에게 공유하고 알립니다.
• 팀원들과 상의 없이 push나 merge를 하지 않습니다.
• 시간약속에 늦거나, 사전 알림 없이 정해진 미팅에 불참하지 않습니다.
• 부득이한 사정이 없다면 작업 상한선(3 am) 이후에는 작업을 하지 않습니다.
• 도전적인 과제 앞에서 적당하게 타협하지 않고, 할 수 있는 최선을 다합니다.

🔩 Dev-related Rules

커밋 메시지 규칙

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

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

• 예시

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

Lint 규칙

• semistandard 를 따릅니다.

주요 규칙

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

브랜치 이름 형식

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

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 v14.18.0
• NPM v6.14.15