코드 리뷰 요청 가이드 라인

리뷰요청이란,

저장소(Repository)에 반영하고자 하는 코드의 리뷰를 Reviewer에게 요청하는 활동입니다.

 

< Commit 단위 >

- Commit은 단일 기능, 단일 주제로 구성한다.

 

- Commit을 Atomic하게 구성함으로써 리뷰하는 사람이 짧은 시간에 효율적인 리뷰가 가능하다.

 

- 개발 업무 시스템화를 위해 Commit을 WBS, Issue, Defect 단위로 구성 가능하다.

 

< Commit LOC(코드 줄 수) >

- 1시간 내 리뷰를 고려하여 200라인 이하의 짧은 코드로 Commit을 구성한다.

 

- 예외 : 파일 전체를 삭제하거나, 신뢰할 수 있는 자동 리팩토링 도구를 활용한 경우 많은 양의 코드 변경이 있을 수 있다.

 

< Commit 단위를 작게 구성하는 이유 >

- 리뷰가 빨라진다.

5분이 걸리는 작은 단위의 Commit을 여러번 리뷰하는 것이 30분짜리 긴 Commit을 리뷰하는 것보다 용이하다.

 

- 좀 더 철저한 리뷰가 가능하다.

커다란 Commit은 리뷰어들을 괴롭게하고 집중력을 떨어뜨려, 코드의 중요한 부분을 놓치게 할 수 있다. 

 

- 버그를 검출하기 쉽다.

적은 양의 코드를 추가하기 때문에 작성자와 검토자 모두 효과적인 검토가 가능하며 버그를 검출하기 쉽다.

 

- Commit Reject시 낭비되는 시간을 줄인다.

큰 Commit에 대해 검토자가 잘못되었다고 한다면 개발자는 많은 업무 시간을 낭비하게 된다.

 

- 병합하기 쉽다.

대규모 Commit은 병합할때 많은 출동이 발생하며 시간이 오래걸리므로 자주 병합해야 한다,

 

- 더 쉽게 디자인 할 수 있다.

큰 코드변화에 대한 세부사항을 수정하는 것보다 작은 코드 변화의 디자인과 코드를 다듬는 것이 훨씬 쉽다. 

 

- 개발/리뷰 싸이클이 효율적이다.

큰 Commit의 리뷰 요청시 리뷰를 기다리느라 지체되는 시간이 늘어나지만, Commit을 분리하여 크기가 작아지면 리뷰

받는동안 개발을 계속 진행할 수 있다.

 

- Roll Back이 더 간단하다.

큰 Commit은 더 많은 파일이 변화하기 때문에, Roll Back을 복잡하게 한다.

 

< Commit Message 제목 >

- 50자 이내로 작성하여 commit의 의도가 잘 드러나도록 한다.

 

- 제목과 본문 사이에 한줄을 띄어 구분되도록 한다.

 

- 문두에 If applied, this commit will 이 생략되어있음을 가정하고, 뒷부분을 작성

 

- 사람의 직관적인 이해를 돕기위해 아래와 같은 통일성 있는 동사 사용을 원칙으로 한다.

 

< Commit 동사 및 용도 정리 >

동사	용도
Add	새로운 기능 / 파일 / 모듈 추가
Remove	기능 / 파일 / 모듈 제거
Fix	버그 수정
Rename	함수 / 변수 / 파일 / 모듈 명 변경
Update	Code 수정 이외의 단순 내용 업데이트
Set	constant 설정 및 변경
Change
Refactor	리펙토링
Release	릴리즈
Merge	브랜치 병합 작업

 

< Commit Message 본문 >

- Commit Message 본문 작성시 변경에 대해 What과 Why에 대해 더 자세히 설명한다.

 

- 향후에 작업하는 사람을 위해 코드 작성의 이유에 대해 기술한다   

 

- '결함 해결을 위한 Commit의 경우, 결함 관리 번호나 정보의 포함을 권장한다

 

< 리뷰요청 점검 사항 >

항목	세부항목	내용
사전 점검	Self-Inspection	기능, 빌드, 스타일 준수, 문서화, 정적검증, 테스트 수행 여부를 확인
Commit 구성	Commit 단위	Commit 단일기능, 단일 주제로 선정
	Commit LOC	x라인 이하로 구성
	Commit Message 제목	x자 이내로 변경 내용을 요약
		변경 유형에 따른 예약 명령을 동사로 사용
	Commit Message 본문	What, Why, How 등을 명확하게 작성
Reviewer 선정	Reviewr 선정	팀 내 x명 이상 리뷰어 선정