Github
•
•
•
•
•
•
•
•
팀원 각자의 코드 리뷰 스타일을 적어주세요 
•
김민재
◦
기능을 구현하는 것에 있어서 불필요한 코드가 있는지 확인
◦
프로그램 실행시 있을 수 있는 예외상황
◦
커밋 메시지의 의미가 명확한지의 여부
•
박범서
◦
기능 로직에 대한 이슈가 무엇이 있을지
◦
PR에 담긴 커밋으로 전체적인 흐름 파악이 되는지
◦
커밋 컨벤션을 잘 따랐는지
•
박중현
◦
코드가 일관성 있게 구현이 되었는지 확인
◦
객체 지향 개념이 잘 적용 되었는지 검토
◦
피드백할 때 올바른 개념을 바탕으로 설명하기
◦
잘 짜여진 코드의 경우 칭찬 아끼지 않기
•
송주환
◦
중복 코드 있는지
◦
코드의 가독성
◦
commit 시 어떤 작업을 했는지 알 수 있는지
•
이지현
◦
구현한 로직 중 오류가 발생할 수 있는 부분이 있는지 확인한다.
◦
변수, 클래스, 메소드 등에 명확한 이름을 선택했는지 확인한다.
◦
필요하지 않은 코드가 있는지 확인한다.
•
최수용
◦
커밋의 단위(커밋 메시지로 어떤 작업을 했고, 메시지만 보고 알 수 있는지)
◦
변수, 메서드, 클레스 네이밍(이름만 보고 무엇인지 알 수 있는지)
◦
다른 방안의 코드가 있을 때 추천해보기
•
허경주
◦
변수, 함수, 클래스 등의 이름이 적합한지, 혹은 이와 관련되어 필요한 주석이 잘 되어있는지 확인한다.
◦
각 기능이 의도에 맞게 잘 구현 되었는지 확인한다.
◦
리뷰를 작성할 시 긍정적이고 올바른 언어표현을 지향한다.
•
박민준
타인이 코드를 보았을 때 이해할 수 있도록 주석을 올바르게 달았는지 확인한다.
◦
커밋 메시지를 올바르게 작성했는지 확인한다.
◦
코드를 최대한 간결하게 작성할 수 있는지 방법을 구상해본다.
우리 팀의 코드 리뷰 가이드를 세워봅시다!
리뷰 작성자명 | 김** |
좋았던 점 | ** 기능에 대한 구현을 하신 부분에서 ***을 사용하셨는데 이것으로 코드가 간결하고 효율적으로 작성된 것 같습니다. |
궁금한 점 | ** 부분에서 ***한 것을 사용하신 이유가 있으실까요? 저는 ****을 사용했는데 둘의 차이점이 궁금합니다. |
의견 제시 | ** 부분에서 사용하신 메서드 외에도 **과 같은 메서드가 있는데 이 메서드를 활용할 경우 …한 장점이 있습니다. 한번 확인해보시고 사용에 대해 고려해보시면 좋을 것 같습니다. |
총평 | 코드 리뷰 전반에 대한 총평입니다. |
우리 팀의 1인당 코드 리뷰 최소 시간은?
•
최소 30분의 시간을 소요하는 것을 원칙으로 한다.
코드 리뷰 완료 확인은 어떻게 진행할까요?
•
코드 리뷰어는 리뷰 작성이 되었을 경우 리뷰 대상자를 태그해 디스코드 채널에 메세지를 보낸다.
◦
예시 : @리뷰_대상자 님 N주차 리뷰 작성했습니다.
•
코드 리뷰 대상자는 리뷰를 확인한 후 해당 메세지에 확인했다는 이모지 를 남긴다.
를 남긴다.