# iOS10-Wavvie 🔊 Team Ground Rule

## 기본 규칙
- 🔥10시부터 19시까지는 boostcamp에 집중하기🔥
- ⏰작업 시간 외, 그리고 주말은 연락을 최대한 피하기⏰
- 🚨긴급한 일의 경우 slack 채널을 통해 `@태그`, `📞허들`로 연락하기🚨
- 슬랙 팀 채널의 알림 설정을 `멘션`으로 해놓기
- 꼭 답이 올 것이라는 기대는 하지않기
- 🤦서로의 의견이 상충할 때, 근거를 기반으로 설득하기🤦
- 합의를 실패할 경우, 팀원의 다수결로 진행
- 동률일 경우, 담당자의 의견을 우선시 하기
- 🧘‍♀️과부하 걸리지 않게 50분 작업, 10분 휴식🧘‍
- 🗣매일 스크럼 시간 때 자기 컨디션 설명하기🗣

## 미팅 방법

#### 비대면 회의
- 이 시국을 조심하며 대면회의는 최대한 자제하기 ~~어차피 다들 멀리 살아서...~~

#### 주제별 회의 최대시간
- 하나의 주제에 최대 2시간으로 제약
- 2시간이 부족할 경우, 다음 회의와의 간격을 1시간을 두어 생각을 정리할 시간을 가지기
- 많은 시간을 소모하다보면 감정적인 발언을 하거나 한쪽에 치우친 사고방식이 유지될 수 있기 때문에 리프레시할 시간을 둠

#### 쉬는시간
- 50분 회의, 10분 휴식🥕

## 코어 타임

##### 코어 타임 중에는 항상 zoom에 접속하기 (Cam은 자유)

#### 주간 스프린트 계획 회의
- 매주 월요일
- 10:00 ~ 12:00

#### 데일리 스크럼
- 별도의 회의가 없는 날의 10:00 ~ 10:15

#### 개발 회의
- 팀원의 요청에 따라 유동적
- 회의 시작 1시간 전에 미리 공지하기

#### 데일리 회고
- 월, 화, 수 18:45 ~ 19:00

#### 팀 회고
- 매주 금요일 18:00 ~ 19:00

## 개발 환경

#### 소프트웨어
- Xcode 13.0 (2021.10.25 기준)
- Git 관련 프로그램 통일 논의 중

#### SwiftLint Rule

excluded:
- Pods
- [Unit Tests]

disabled_rules:
- switch_case_alignment
- trailing_whitespace

opt_in_rules:
  - force_unwrapping
  
force_unwrapping: error
force_cast: error
force_try: error
comma: error
vertical_whitespace:
    severity: error
colon:
  severity: error
  
line_length:
  warning: 120
  ignores_function_declarations: true
  ignores_comments: true
  ignores_interpolated_strings: true
  ignores_urls: true

## Programming Naming Rule

## Commit

######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |
# <Gitmoji> 제목
# ✨:sparkles:️ 기능 (새로운 기능) #이슈번호
# 🐛:bug: 버그 (버그 수정) #이슈번호
# ♻️:recycle: 리팩토링 #이슈번호
# 💄:lipstick: UI 변경 #이슈번호
# 🎨:art: 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음) #이슈번호
# 📝:memo: 문서 (문서 추가, 수정, 삭제) #이슈번호
# ✅:white_check_mark: 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음) #이슈번호
# 🔥:fire: 코드, 파일 삭제 #이슈번호
# 📦️:package: 관련 라이브러리 추가 (빌드 스크립트 수정 등) #이슈번호
# 🚀:rocket: 배포 관련 #이슈번호
# —————————
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기
#     본문은 “어떻게” 보다 “무엇을“, “왜”를 설명한다.
# ————————— 

#### 참고하기
- [Gitmoji Style Guide](https://gitmoji.dev)
- [Udacity Style Guide](https://overcome-the-limits.tistory.com/entry/협업-협업을-위한-기본적인-git-커밋컨벤션-설정하기)

## Git Branch Rule

#### GitLab Flow
- Git Flow의 모든 기능들을 사용하기에는 프로젝트의 스케일에 걸맞지 않다고 판단함
- Github Flow는 자주 배포되는 Saas 애플리케이션에 적절함
- Gitlab Flow와 같이 production 브랜치를 이용하는 것이 버전 관리에 용이하다고 생각하여 해당 브랜치 전략을 선택함
- GitLab Flow에서는 master 브랜치에 작업 사항들이 업데이트 되므로 project, issue, pr 연동이 편함
- 참고) [Gitlab 공식 홈페이지](https://docs.gitlab.com/ee/topics/gitlab_flow.html#production-branch-with-gitlab-flow)

master: pr merge 및 issue 관리용 브랜치
staging: production에 배포하기 전, 통합 테스트를 수행하는 브랜치
production: 배포용 브랜치

새로운 기능을 작업 할 때: feature/taskID 으로 브랜치 생성
새로운 기능 개발이 끝났을 때: feature/taskID 를 master에 merge하고 PR 메시지로 해당하는 task를 닫는다.

master에서 버그가 발견되었을 때: bug/issueID로 브랜치 생성
발견한 버그를 수정하였을 때: bug/issueID 를 master에 merge하고 PR 메시지로 해당하는 issue를 닫는다.
ex: Resolve #1, Closed #1

배포를 할 때: master에서 staging으로 merge 후, staging에서 통합테스트를 통화하면 production으로 merge

## 코드 리뷰 규칙

#### 코드 리뷰

- PR에 대해 모든 팀원을 리뷰어로 지정
- UI 관련 코드는 리뷰 요청 X
- 로직이 포함된 부분에 대해서는 리뷰 요쳥 O

#### 리뷰 항목
- Unit Test가 충분한 경우의 수를 모두 포함하는가
- code의 indent가 3~4 이상으로 깊은가

#### 코드리뷰 관련 참고 문서
- [구글의 코드리뷰](https://madplay.github.io/post/speed-of-code-reviews)
- [우형의 코드리뷰](https://techblog.woowahan.com/2712/)
- [왜 코드리뷰를 해야하는가?](https://techwell.wooritech.com/blog/2021/04/19/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0/)
- [효과적인 코드 리뷰를 위해서](https://engineering.linecorp.com/ko/blog/effective-codereview/)

## PR Merge

#### 기본적으로 PR에 대해 2인 이상의 코드 리뷰가 있을 경우 병합 가능

- Git Branch 전략
- Github Flow를 기반으로 사용

- PR 병합
- Rebase? Squash?

## 변경 이력
- 최초 업데이트 (2021.10.25)