그라운드 룰

📢 제 1원칙: 솔직하게 말하기 좋은 것도 싫은 것도 모두 그 자리에서 솔직하게 말합니다. 그래야 오해가 쌓이지 않고 빠른 문제 해결이 가능하며, 결과적으로 더 견고한 팀이 될 수 있습니다.

🤝 온라인 생활 규칙

• 프로젝트 기간 동안 상호 존대 (반말 금지)
• 팀원이 실수해도 탓하지 않기
• 지각 시
  1. 5분이 지나면 그냥 시작합니다.
  2. 10분 넘기면 1인 1잔 음료 기프티콘 쏘기

🤝 온라인 스크럼 규칙

• 13시에 모두 모였을 때 바로 진행!!
• 스크럼 시간에 대화 나누기 앞서 5분 정도 작업 내용 기록하는 시간 가지기
  • 오늘 한 일
  • 이슈(문제상황)
• 인당 2분, 오늘 한 일에 대해서 이야기하기
• 오늘 한 일을 이야기한 후 스프린트 백로그를 업데이트하기

🤝 개발 규칙

branch 규칙

• branch 전략
  • feat : 기능 단위 개발을 위한 branch
  • main : feat 를 여기에 merge하면 자동 배포
• branch 네임은 다음과 같은 방식으로 작성한다 :
  • feat(fe)/some-feature
  • fix(be)/some-error

commit 규칙

• 영어로 작성한다.
• 형식: <타입>: <변경 요약>
  • 예시:
    • feat(새로운 기능),
    • fix(버그 수정),
    • docs(문서 변경),
    • style(포맷, 세미콜론 누락 등 코드 변경이 없는 경우),
    • refactor(코드 리팩토링, 성능 개선 등),
    • test(테스트 추가 또는 수정),
    • chore(빌드 테스크 업데이트, 패키지 매니저 설정 등)

issue 규칙

• 한글로 작성 (제목과 내용)
• 형식: [<타입>]: <요약> (타입의 경우 첫 글자만 대문자로)
  • 예시: [Feat]: 어떤 기능
• issue template을 사용하여 작성한다.
• github project와 연동한다.

pull request 규칙

• 기능 단위로 최대한 자주 올린다.
• 영어로 작성 (제목만 영어로), 내용은 한글로 기재
• 형식: <타입>(<도메인>): <요약>
  • 예시: feat(fe): some feature
• PR 내부에 close, fix, resolve 와 같은 키워드와 함께 이슈 번호를 작성.
• github project와 연동하지 않는다. (github project에는 issue만 들어가도록 한다.)

merge 규칙

• 2명에게 approve를 받아야 merge할 수 있다.
• merge 종류
  • feature → main : squash merge

컨벤션

• 파일 이름 → web-socket.controller.ts (케밥 케이스)
• 클래스, 인터페이스, 등 → WebSocket (파스칼 케이스)
• 변수명, 함수명 등 → webSocket (카멜 케이스)