팀원 각자의 코드 리뷰 스타일을 적어주세요 
1.
김도율
설득력이 있고, 읽기 좋은 코드인지를 중점적으로 봅니다!
2.
김상훈
코드 리뷰할때 PR의 내용만 보고서도 변경 사항에 대해 충분히 이해할 수 있고, 원하는 부분이나 토의해야 하는 내용을 잘 명시할수있는 PR이 핵심이라 생각합니다.
3.
김우용
다른 사람이 확인했을 때, 금방 코드의 동작을 이해할 수 있도록 가독성이 좋은 지를 중점으로 확인합니다.
4.
김치훈
•
변수와 클래스 명이 명확한지
•
디렉터리 구조를 잘 나눴는지
•
예외 처리를 적절히 했는지
•
모듈화를 잘 시켰는지
5.
이소영
변수를 적절하게 사용했는지 예외 사항을 고려하여 잘 반영 했는지, 그리고 기능 구현이 명확히 되었는지 확인할 수 있으면 좋겠습니다.
6.
이우엽
일관된 아키텍처를 유지하고 있는지, 일관된 네이밍을 사용하는지
중복된 코드를 최대한으로 없애려고 노력했는지를 살펴볼 생각입니다
똑같은 기능이라도 다양하게 구현한 코드를 보며 많이 배우고 싶습니다
7.
이재호
로직을 보고 쉽게 이해할수 있는지, 좀더 쉽게 읽히는 방법이 있는가에 대한 고민을 하면서 리뷰를 해보고 싶습니다.
8.
정혜수
변수명과 로직이 코드를 리뷰하는 사람이 쉽게 이해할 수 있는 지에 대해 중점적으로 볼 생각입니다.
9.
최승근
내가 작성한 코드와 타인의 작성한 코드를 비교해보며 작성자의 구현방법, 차이점, 장단점을 중점적으로 볼 생각이며, 코드의 가독성이나 모듈화를 통해 쉽게 이해할 수 있는지 확인해볼 생각입니다.
우리 팀의 코드 리뷰 가이드를 세워봅시다!
•
팀 레포 + 개인 레포
◦
팀 레포 : 개인 레포 주소 남기기
•
issue convention
1.
매 주 구현해야하는 기능을 분리
◦
[x] 기능1
◦
[ ] 기능2
•
MD
# 📑 체크리스트
- [ ] N_Week_Mission 디렉토리 생성
- [ ] N_Week_Record 디렉토리 생성
- [ ] check1
- [ ] check2
- [ ] check3
Markdown
복사
•
commit convetion
◦
커밋을 단위별로 자세히 남기기
◦
Feat : 기능 개발
◦
Fix : 오류 수정
◦
Refactor : 코드 리팩토링
◦
Chore : 빌드 업무 수정
◦
Test : 테스트 관련 코드
•
pr convention
◦
pr 메시지
▪
PR의 의의
•
의도나 기대하는 내용?
▪
커밋 단위 별 구현내용 요약(모든 커밋을 할 필요는 없고 중점적인 내용만 기술)
▪
리뷰어가 중점적으로 봐줬으면 하는사항
•
MD
## 📖 Key Changes(write include commit)
* ex) Feat : 로그인 기능 생성
* Oauth2 를 이용한 구글 로그인 기능 생성
* commit2
* comment2
* commit3
* comment3
## 👀 To Reviewers
* ex) 다른 로그인도 추가할까요?
* comment2
* comment3
Markdown
복사
참고 URL
우리 팀의 1인당 코드 리뷰 최소 시간은?
•
피어 리뷰 시간: 목요일 10시 ~ 18시
•
1단계 : [오전 10시~ 15시], 30분씩 코멘트를 남긴다.
•
2단계 : 자신의 코드 코멘트에 대한
•
3단계 : 15시 ~ 18시 코드 설명
