GROUND RULE
- 지각하면 빌리엔젤
- 다른 팀원이 이해했는지 서로 설명을 하며 확인하고 넘어가기
- 회의와 문서는 돌아가면서 관리한다.
- 점심시간, 퇴근시간 보장
- 질문시간, 회의시간 지키기
- 4칭찬 1조언
- 아무리 바빠도 회고 시간을 꼭 갖기
- 월요일회의
- 유저스토리
- 이슈에 대한 할당.
- 일주일동안 어느정도 단위를 하면 좋을까? 시간단위
- 주간회의 시간
- 수요일 저녁 30분: 데모
- 코드리뷰: 오전에 하기 / 화 목 두번 하기 vs 오전에 회의 / 오후에 코드리뷰 or 회의
- 발제주제, 발제에 대한 시간을 회의 전에 적어놓기
- 질문 시간
- 화, 수, 목 오전
- 일간회의 시간
- 회의 관리는 돌아가면서한다. 이사람이 회의 결과도 적는다.
- 코드리뷰
- 코드리뷰 시간 : 오전
- 코드리뷰 투자 시간 : 1시간 수요일제외
- 초반에는 전부 리뷰하고 나중에는 중요한 것들 위주로 볼것인가?
- 커밋단위 / Pull Request단위 - Pull Request를 필수적으로 놔두고 코드리뷰때마다 볼 것인가?
- feature가 완성될 경우에 pull request를 날리고 그것을 볼 것인가?
- 데모에 대한 정의
- 실행화면을 보여준다.
- 이번주에 무엇을 신경썼는지 발표한다.
- 발표에 대한 피드백을 준다.
- 추가 의견 및 근거를 제시한다.
- 예) 이런 것들도 생각을 해야하지 않나요?
- 예상질문을 취합해본다.
- 발표자료를 만든다.
- editor : vscode
- indent
- tslint
- prettier
- 구현과 설정의 충돌을 어떻게 할 수 없는 경우
- 팀에 그 설정을 false로 할지 상의
- 그부분에만 무효화되도록 해놓고 주석으로 이유를 달아놓기
- 우린 Git-flow를 사용하고 있어요 - by 우아한 형제들
- master: release가 변경되면 여기로 푸쉬
- hotfix: master에서 버그가 생겼을 때! 심각한 상황, 에러 수정 뒤 master, release, develop에 푸쉬
- release: 금요일 전까지 release에 푸쉬 -> 전체 q/a시간 뒤 버그가 존재하면 수정하고 버전 맨 마지막 숫자 올리기(ex)1.0.1) -> master에 푸쉬
- develop:
- feature: 브랜치 컨벤션 ex)feature-01, feature-78/profile_page_publishing
- 풀리퀘 머지할때 반드시 squash하기
-
Add : 코드나 테스트, 예제, 문서 등의 추가가 있을 때 사용
-
Fix : 에러수정할때. Fix
-
Remove : 코드나 파일제거해서 기능을 제거할 때
-
Refactor : 구조 자체가 리펙토링 될 때
-
Simplyfy : 함수 리펙토링, 컴포넌트 리펙토링 같은 단위, 그냥 내비둬도 돌아가지만 수정한것!
-
Rename : 파일 이름, 변수명 등을 변경할 때 rename
-
Test :
-
Document :
- ex) [Add] 친구 삭제 API 구현
- 왜 : 어디에 사용하려고 했는가?
- 어떻게 : 동작방식 및 원리
- 이슈번호 #12 에러없는 단위로 커밋할 것!
