👑 팀 그라운드룰 - boostcampwm-2022/web17-waglewagle GitHub Wiki

🧑‍🤝‍🧑 팀 문화

💡 우리 모두가 리더다.

리더가 있더라도, 모두가 참여하며 수평적으로 의사결정함. 리더라는 포지션은 말 그대로 책임과 리딩을 위함.
의사결정의 논리와 근거에 대해 팀 모두가 알아야함.
작업과 학습에 대해 적극적으로 공유.
초기에는 공유하는 시간이 많고, 이후에 서로 익숙해지면 개인 작업 (공유는 필수)
프로젝트 기간의 과정도 결과가 된다. 그러나 완결성이 완성도보다 중요하다.
출근했다고 생각하면서 코어타임에 임하기

🤼 팀 undefined 역할 및 책임

🧑🏻‍💼 운영 역할

회의에서 각자의 책임이 있다면, 회의가 더 원활하지 않을까?
다만 모두가 회의에 동등하게 참여해야하는 것은 확실하다.
굳이 명패를 달아놓으면 책임 방기가 생길 것 같다.
아이디어는 모두 함께 내고, 정리와 비판이 따로 떨어져 나오는 것이 좋겠다.
일단 진행하며, 필요한 것이 생기면 정하자
비판은 차라리 따로 시간을 갖는게 낫겠다.
기획 담당은 프로젝트 자체에 대한 애착이 있는 사람으로 한다.

🦸 프로젝트 리더 (J022_김관경)

올바른 방향으로 가고 있는지 체크, 회의 진행.
필요시 회의록 작성.
일단은 전체적으로 관리, 이후 분리.

⌨️ 기록 일정 관리 (J144_이승민)

회의록 작성.

⚙️ 기술 역할

구현 : 기능구현에 있어서 달려나가는 역할 (2022.11.07.)
품질관리 : 구현에 있어서 간과되거나 코드 품질에 대해 신경써야하는 부분들을 짚어주기

🖥️ 프론트엔드 리더

구현 리더 (push) : J069_문성현

프론트엔드에 대해 구현 리딩

품질관리 리더 (pull) : J022_김관경

프론트엔드에 대해 코드 품질, 테스팅 등 관리

📥 백엔드 리더

구현 (push) 리더 : J026_김대호

백엔드에 대해 구현 리딩

품질관리 (pull) 리더 : J144_이승민

백엔드에 대해 코드 품질, 테스팅 등 관리

📏 팀 undefined 규칙

🚷 최소한의 규칙

이것만큼은 지켜요

코어타임 : 10시 ~ 19시
점심시간 : 12시 ~ 13시 (일정 따라서 변경)
게더타운이 코어타임 중 회사라고 생각하기
상대방을 생각하며 말하기
공지 & 비상 채널 읽으면 체크표시
트러블 슈팅이 있었다면 문서화 & 다른 사람들은 해당 문서 읽어보기
질문이 있다면 손을 들고 기다려요
진행상황 확인을 위해 하루에 하나 PR을 날려요. (단위가 안맞아서 거절당해도 괜찮아요.)
프로젝트 리더 ‘죄송합니다’ 금지
프로젝트 리더에게 ‘죄송합니다’ 금지

개발 규칙

코드 치기 전에 하려고 하는 것을 적기. 이후 작업이 종결되었을 때, 작업 내용을 공유하기 (로그를 남기는 것에 포커싱)
이후 이 내용을 정리하여 모두가 작업 내용을 이해할 수 있도록 함. (이슈, 학습 사항, 레퍼런스 등)
읽을 사람을 생각하며 코딩하기 & PR 날리기 & 커밋 메세지 쓰기
30분 고민해보고 한 명에게 물어보기, 이후 그 사람도 모르면 전체 소집
- 2명이상이 한 트러블 슈팅과 혼자한 트러블 슈팅은 따로 분류하기
  - 💡 우리 undefined의 트러블 슈팅 분류 기준
    - 🐶 도지 하나 : 혼자 고민한 문제
    - 🐶🐶 도지 둘 : 둘이서 고민한 문제
    - 🐶🐶🐶 도지 셋 : 다같이 고민한 문제

시간대별 할 일 (2022.11.07.)

데일리 스크럼 (30분)

전 날 한 일

데일리 코드리뷰 (1시간)

가볍게 코드리뷰
전체 코드리뷰가 아니라, 팀원들의 코드 가독성 맥락 맞추기에 중점
가독성을 위주로 코드리뷰 한다.

Feature List 갱신 (30분)

전날의 이슈와 스크럼을 토대로 Feature List 갱신

개발

갱신된 Feature List를 반영하여 개발하기

코어타임 마무리 스크럼 (30분)

하루 정리가 아니라, 중간 체크포인트 개념
오늘 개발 사항 간단히 공유 (+ 2명 이상 모였던 내용이 있었음을 나누기)

⏰ 일정 (2022.11.07.)

Day01 ~ Day04 코어타임

오전

10:00 ~ 10:30 : 데일리 스크럼 (커뮤니케이션, 일정 관리 - 코드 제외)

10:30 ~ 11:00 : 데일리 코드리뷰 (가독성에 중점)

11:00 ~ 12:00 : Feature List 갱신

12:00 ~ 13:00 : 점심시간

의사결정과정
- 성현님 : 파편화된 시간 사용이 좋다.
⇒ 관경, 대호 : 파편화된 시간은 루즈해집니다.

⇒ 성현님께서 코어 이전 시간에 사용하시기로 함.

오후

13:00 ~ 17:00 / 19:00 : 개발

16:30 / 18:30 ~ 17:00 / 19:00 : 마무리 스크럼

17:00 ~ 19:00(마스터 클래스) : 마스터 클래스

코어타임 이후

슬랙 비상 채널에 올라오는것에 읽었으면 체크 이모지 남겨주기

👍 팀 undefined Github 규칙

🎋 Branch 관리 전략 : git flow

git flow 전략

의사결정과정
- ~~trunk based~~
- gitflow
⇒ 하나의 브랜치를 안정적으로 쓰기에는, 아직 그 정도로 괜찮은 테스트 코드를 처음부터 쓸 수 있을지 모르겠다.

⇒ git flow로 선정

코드 저장소 관리 규칙

네이버 부스트캠프 저장소에 main, frontend, backend 브랜치 만듬
main에 frontend, backend 합친 내용 저장 - 관상용, pull용, 서로의 코드 리뷰 등 협업을 위함
fe/main 브랜치 : frontend 배포
be/main 브랜치 : backend 배포
fe/release 브랜치 : frontend 데모 배포
be/release 브랜치 : backend 데모 배포
fe/dev 브랜치 : dev 브랜치
be/dev 브랜치 : dev 브랜치
fe/feature/기능명
be/feature/기능명
의사결정과정

독특한 구조이긴 하나, 프로젝트의 진행 방식이나 협업을 위함
1. 의사 결정이 필요한 항목들
  1. BE / FE 브랜치 분기점
    1. main ⇒ release(분리) ⇒
  2. 브랜치 네이밍 컨벤션
  3. 배포가 이루어질 브랜치 - main / release

branch 관리 규칙

main : release 되는 브랜치

release : demo 버젼 확인되는 브랜치

dev : Day별로 release에 PR 날리기

feature : dev에 merge되는 기능단위

의사결정과정

main 브랜치는 배포버전단위로만 관리되도록

dev는 정해놓은 기능 단위 (여러 feature)

feature는 커밋 단위

📌 Commit 규칙

커밋 예시

[feat] 채팅 기능 구현 (#1)
[style] 세미콜론 제거

커밋 시 규칙

force push 금지
main 브랜치를 rebase merge 금지
한 문장으로 표현 가능한 단위로 commit

커밋 타입

env (environment) : 환경 설정, 의존성 추가
feat (feature) : 기능 구현
fix (bug fix) : 버그 수정 - 기능의 수정과 함께 코드를 변경하는 것
refactor : 코드 리팩토링 - 기능상의 수정없이 코드를 변경하는 것. 코드 내용이 바뀌는 것.
style (사용 후 변경) : 간단한 코드 스타일링을 포함함. import해놓고 안썼다거나, 줄바꿈 등. 리팩토링과 별도로 코드 스타일만 변경. 넘겨도 된다.
chore (maintain) : 기타 잡다한 일. 폴더, 파일 삭제, 파일명 변경 등.
test (when adding missing tests) : 테스트 코드 작성
docs (documentation) : 문서

커밋 메세지 내용

한글로 쓰기.
코드 구성 요소는 영어로 쓰기.

/ 참고자료

[좋은 git commit 메시지를 위한 영어 사전](https://blog.ull.im/engineering/2019/03/10/logs-on-git.html)

🤼 PR 규칙

PR 발생 규칙

Day별로 dev 브랜치 merge
feature 브랜치 하나가 닫히면 dev에
feature 병합 PR의 최대 길이나 기준을 정하자
- 의사결정과정 (명세서가 나온다음 추후 논의)
  
  PR이 크면 리뷰도 어렵고, conflict 나오는 양이 많아질 것 같으니 PR 기준을 정하자.
  
  feature 단위를 지금 정해야할까? ⇒ 명세서가 나온다음에

PR 병합 규칙

생성되면 다음날 00시 이전에 코멘트 or 리뷰
모든 사람이 확인해야 merge를 원칙

PR 작성 규칙

읽는 사람이 코드의 맥락을 이해할 수 있도록 PR을 작성하기
해당 PR에 담긴 코드에 대한 설명을 작성한다.
작업 배경 (Issue보다 세세하게, 왜 이렇게 접근을 했는지)
코드에 대한 설명 ⇒ 이후 PR 보면서 추가한다.
필요한 경우 작업물이나 결과물 시각 자료 (스크린 샷, ERD, UML 등등…)
트러블 슈팅 링크
새로운 함수를 만들었다면, 설명한다.

## 작업 배경

- 작업 배경입니다.
- 이런 저런 이유로 이런 방식으로 접근하였습니다.

## 작업 내역

- ~~ 파일을 처리하였습니다.
- 작업 내역 1입니다.
	- 이런 저런 플로우로 데이터가 처리됩니다.
- 작동 스크린샷입니다. (optional)

## 코드 설명

- 이런 이런 플로우로 데이터를 처리합니다.

## 트러블 슈팅

- 트러블 슈팅 내역입니다.
	- [트러블 슈팅 노션 링크 1](https://notion.so)
	- [트러블 슈팅 노션 링크 2](https://notion.so)

⚠️ Issue 규칙

이슈는 feature, bug, refactor
의사결정과정

어떨 때 이슈를 발행해야할까?
- feature list가 나왔을 때 - 다 같이(기획단계)
- feature lsit가 수정될 때 - 다 같이(진행단계)
- bug - 혼자 : 올리고 공유하기
- refactor - 혼자 : 올리고 공유하기

🖥️ 와글와글 코딩 컨벤션

🔠 코드 스타일

공통

객체 trailing comma 사용
객체 단축문법 사용
if문 한 줄짜리라도 중괄호 필수
while true 사용 금지
삼항 연산자는 조건 1개까지

함수 호이스팅 사용 금지

add(); // 동작

function add(){
}

minus(); // 에러 => undefined를 함수로 호출했기 때문에 에러가 난다.
 
const minus = () => {};

minus(); // 동작

함수 네이밍 컨벤션

카멜케이스로 만든다.
함수는 동사로 만든다.
접두어는 구현하며 확인한다.
이벤트 핸들러 : handle + 행위(ex. click) + 목적어

변수 네이밍 컨벤션

카멜케이스로 만든다.
변수는 명사로 만든다.

폴더명 네이밍 컨벤션 - 리눅스 확인

스네이크 케이스로 사용
프론트엔드는 컴포넌트에서는 첫글자를 대문자로 사용한다.

🎨 의미가 없는 스타일 (Non-semantic)

Space 2번
문자열은 single quote
semi colon 항상
한 줄에 80자 (쓰면서 불편하면 늘리기)
들여쓰기는 2번까지