'Green'의 개발 문화 알아보기 - 코드 리뷰

code review 란??

모든 코드를 리뷰를 거쳐서 배포한다. 이 과정에서 버그를 줄일 수 있고 설계나 기획 등 맥락을 공유하여 더 나은 방법을

찾을 수 있기 때문이다.
또 상하에 관계 없이 Reviewer 또한 자신이 생각하지 못한 문법이나 표현식을 다른 사람의 코드로부터 배울 수 있어

코드 리뷰는 중요하다.
master branch 에 merge 하기 전 Pull Request 를 올려 리뷰를 신청하고 동료들은 리뷰 신청을 받으면 어떠한 

방식으로 처리할지 명시적
코멘트 또는 이모지를 남긴다. 그 후 완료되었는지 서로 확인한다. 모든 리뷰가 끝나면 테스트를 거쳐 배포한다.

 

code review 를 하는 우리의 태도 

 Reviewer

- 온라인 상에서의 커뮤니케이션은 의도와 다르게 공격적으로 보일 수 있습니다. 키보드와 모니터 너머에 동료가 있다는 걸 인지하고 리뷰를 작성한다.
- 리뷰도 업무의 일부라고 생각하고 되도록이면 빠르게 처리한다. 할당된 리뷰는 최대 3일 안에 답변을 남겨서 Reviewee 의 개발 컨디션을 유지시켜 주도록 한다.
- 의미하는 바가 명확하게 코멘트를 남깁니다. 비효율적인 소통으로 인한 낭비를 피하고 필요하다면 예시 코드도 적어 줍니다.
- 바보 같은 질문이란 없습니다. 부담을 갖지 말고 자유롭게 질문을 남긴다.
- Reviewee 에 대한 격려를 잊지 않는다. 문제점에 대한 지적은 잘해도 칭찬은 안 하는 경우가 많다. 동료가 보람을 느끼고 성취감을 느끼도록 적극 칭찬한다.

Reviewee

- 코드에 대한 코멘트를 나에 대한 공격으로 받아들이지 않는다. 자신의 코드에 자신을 투영하면 안된다. 
- 리뷰에 대한 반응을 빠르게 한다. 
- Reviewer 가 남긴 코멘트가 항상 정답은 아니다. 자신의 생각과 다르다면 그에 대한 코멘트를 달고 합의점에 도달할 수 있도록 한다.
- 이것도 몰라? 라는 생각은 지양합니다. 모든 코멘트에 넒은 마음으로 답변한다.

 

 

 

code review 는 정해진 템플릿을 활용하자

프로그래머스를 운영 중인 grepp 에서 활용하는 템플릿 예시

처음 코드리뷰를 도입할 때 중구난방으로 쏟아지는 리뷰들을 미연에 방지 할 수 있는 정해진 틀을 사용하는 것도

좋은 방법이다!!

그래서 !!

code review 얼마나 자주 해야 좋을까?
이론적으로 코드 리뷰는 매일 아침 출근하자마자 하는게 제일 좋다. 하지만 도입을 한 직후에는 업무의 효율을 저하시킬 우려가 있고 한 공간에 모여 있는 개발 조직의 경우에는
주 1회 로 시작하는게 적당할 것 같다.

 

 

참조

 

https://grepp.tistory.com/4

그렙 개발자들은 어떤 개발 문화를 만들고 있을까