팀원 각자의 코드 리뷰 스타일을 적어주세요 
1. 팀원 깃 레포지토리를 한눈에 볼 수 있게 링크 작성하기
2. 본인이 생각하는 코드 리뷰 핵심이 무엇인지 고민하기
3. 어떤 점을 중점으로 코드 리뷰에 임할 것인지 등을 작성해주세요!
갤러리 보기
Search
우리 팀의 코드 리뷰 가이드를 세워봅시다!
참고자료1) https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/
참고자료2) https://2jinishappy.tistory.com/337
참고자료3) https://techblog.woowahan.com/2712/
상단 자료들을 참고하여 우리 팀만의 코드 리뷰 가이드를 작성해주세요!
개발의 민족의 코드 리뷰 가이드
원래 코드리뷰는 Pull Request 기반 Comment를 통해 진행됩니다. 하지만 지금 개인 프로젝트에서는 하나의 pull request를 생성하지 못한 등 다양한 이슈로 인해 PeerReview_5Team 이라는 팀 레포를 생성하여 이곳에서 피어리뷰를 진행하기로 하였습니다. (팀 프로젝트에서는 정석대로 해봅시다ㅎㅎ)
1. 에 들어갑니다.
2.
새로운 branch를 생성합니다.
3.
자신의 이름으로 branch 명을 지어주세요.
4.
branch 생성 후, main → 자신의 브랜치로 바꿔주세요.
5.
(WebIDE 사용) 레포를 local에 클론하지 않고 빠르게 편집하고 싶을 때 사용합니다.
1) 아래와 같이 왼쪽 하단에 브랜치명이 자신의 브랜치 인지 확인하고, 자신의 이름.md 의 마크다운 파일을 생성하고 위에 자신의 코드 리뷰 스타일 적은 것을 복사해주세요.
2) 파일을 생성하면 왼쪽 source control에 아래와 변경파일이 표시됩니다. commit message에 Docs : Create dongyeon.md 와 같이 커밋 메시지를 입력하고 commit & push 버튼을 눌러주세요. (커밋 메시지 가이드는 본 페이지 하단에 있습니다. )
3) 다음과 같은 창이 뜬다면 No : Use Current branch를 선택하셔야 합니다!!
(개인 로컬 편집기 사용) Vscode나 IntelliJ와 같은 편집기를 사용하고 싶으신 경우
1) git 주소를 복사하여 자신 로컬에 clone합니다.
git clone https://gitlab.com/dongyeon-0822/peerreview_5team.git
PowerShell
복사
2) 브랜치를 자신의 브랜치로 변경합니다. 이 부분은 어떤 IDE를 사용하느냐에 따라 다르지만 보통 맨 밑에 버튼을 branch를 변경할 수 있습니다.
3) 이제 평소에 하던 것처럼 편집하고 commit하고 (main이 아닌 자신의 브랜치에) push하면 됩니다.
6.
다시 GitLab 프로젝트로 돌아와 자신의 브랜치에 다음과 같이 커밋이 잘 됨을 확인할 수 있습니다. 여기서 Create merge request 버튼을 클릭합니다.
7.
다음과 같이 제목은 Mission_1_peerReview_브랜치이름 으로 하고, 하단의 Pull Request Template을 복사하여 리뷰어가 자신의 코드를 잘 이해할 수 있게 내용을 자세하게 작성해주세요!
8.
리뷰어를 이름 순으로 다음 사람에게 요청합니다.
9.
Label을 reviewing으로 설정하고 Create merge request를 하면 됩니다!
10.
자신에게 할당된 리뷰들에 comment를 달아 리뷰를 진행해주시면 됩니다! 요청받지 않은 merge request에도 들어가서 리뷰를 해주세요!! (리뷰어가 한 명밖에 설정안되는 이슈로 인해,,ㅜ)
팀원들의 레포에서 commit 기록을 보면 좀 더 쉽게 리뷰를 할 수 있습니다!
11.
리뷰어가 리뷰를 완료하면 main에 merge할 수 있습니다.
Pull Request Template
아래 템플릿을 복붙하시고 작성하실 때는 주석을 지우고 작성해주세요!
### 작업 개요
-- 작업의 제목을 간단하게 적기
ex) MusaSNS Mission 1 구현
### GitLab 레포주소 및 이슈 번호
-- 이슈 번호 및 브랜치명
ex) https://gitlab.com/dongyeon-0822/likelion-final-project
### 수행 작업
-- 작업 항목 적기
- [ ] 포스트 등록 기능 구현
- [ ] 포스트 Controller Test 코드 작성
- [ ] 포스트 Service Test 코드 작성
### 작업 상세 내용
-- 작업 세부 사항 적기(어떤 코드를 왜 변경했는지)
1. Post Response 형식에 맞게 수정
2. SQL Exception 처리
### 리뷰어들에게
-- 기능 구현에 대해 이슈사항 언급, 리뷰어가 집중하여 리뷰할 부분 등 자유로운 형식으로 적기
* Service Test 코드를 저런 형식으로 작성하는게 맞을까요?
혹시 다른 방법이 있다면 리뷰해주시면 감사하겠습니다!
* 이런 부분들을 중점적으로 구현했습니다!
Markdown
복사
코드 리뷰 체크 사항
자신이 코드리뷰에서 꼭 체크하고자 하는 사항 3가지 이상 정하고 그 부분은 꼭 체크합시다! (무엇을 체크해야 될지 모르겠다면 팀원들의 체크리스트를 참고 하거나 아래 링크에서 자신이 체크할 수 있는 항목들을 찾아보세요!)
### Reviews
1. ~~ 부분에서 예외가 발생할 수 있을 것 같습니다.
(참고링크) Exception manager에서 이 부분을 추가하면 좀 더 안정적인 프로그램이 될 것 같습니다!
2. 이 부분은 어떤 기능을 위해 필요한 것인가요?
### 칭찬 한마디!
- ex)이 부분은 코드 가독성이 좋아서 이해가 잘 갔습니다!
Markdown
복사
REF
커밋 메시지 규칙
Commit Message 의 구성 방법
<type>[optional scope]: <description> -- 제목
[optional body] -- 본문
[optional footer(s)] -- (바닥글)
Plain Text
복사
1.
제목 : 어떤 것을 했는지 핵심 내용을 명확하게 적는다.
2.
본문 : 자세한 커밋 메시지를 작성하고자 할 때, 제목에 이어 부가적인 설명을 작성한다. (커밋 이유, 변경 내용 등)
3.
바닥글: 주로 관련 이슈 번호를 참조할 때 사용한다.
커밋 유형
COMMIT TYPE | 뜻 |
Feat | 새로운 기능의 추가 |
Fix | 버그 수정 |
Chore | feat이나 fix와 관련 없는 변경 사항, src나 test 파일이 아닌 다른 파일 수정 사항
(ex .dependencies 수정 같은 경우) |
Refactor | 버그를 고치거나 새로운 기능 추가가 아닌 코드 리팩토링 |
Docs | 문서 수정 (README.md) |
Style | 스타일 관련 코드 (코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우) |
Test | 테스트 코드, 리펙토링 테스트 코드 |
Perf | 기능 개선 코드 추가 |
Ci | CI/CD 관련 코드 |
Build | 빌드 시스템이나 외부 종속성과 관련있는 코드 |
Delete | 코드 삭제 |
Remove | 파일 삭제 |
Rename | 파일이나 디렉토리 이름 수정 |
Move | 파일위치 이동 |
Remove | 파일 삭제 |
Rename | 파일이나 디렉토리 명 수정 |
우리 팀의 1인당 코드 리뷰 최소 시간은?
어떤 식으로 코드리뷰를 진행할 것인지 단계별로 고민하여 코드 리뷰 시간을 정해주세요!
1.
템플릿을 읽고 코드 이해하기
10 ~ 20분
2.
코드 리뷰하기
15분
3.
코드 리팩토링
60분
코드 리뷰 완료 확인은 어떻게 진행할까요?
1. 어떤 플랫폼을 사용해서 어떻게 소통할지
2. 확인 요청 메시지는 어떻게 구성할지
3. 확인 후 코드 리팩토링은 어떻게 진행할지 등을 고민하여 작성해주세요!
1.
GitLab & Discord 사용하여 소통하기
2.
Pull Request → Reviewer 설정으로 리뷰 요청 보내기 (Discord로 한번 더 알리기)
3.
리뷰어에게 comment로 리뷰하기
4.
자신에게 온 리뷰들을 확인 후 코드 리팩토링하기 (comment로 소통하기)
5.
모든 리뷰 완료 후 Merge 하기