GitHub의 스태프 엔지니어가 자신의 업무 중 가장 중요한 일 중 하나가 코드 리뷰고 수년동안 코드리뷰를 해오면서 쌓은 경험을 정리한 글입니다.

GitHub에서는 PR에서 라벨을 많이 쓰는지 Slack에서도 /github subscribe your/repo pulls +label:"your-team-label" 명령어를 통해서 리뷰가 필요한 PR의 알림 설정을 한다고 합니다. 갠적으로는 회사에서는 라벨을 많이 쓰진 않아서(규칙이 많으면 관리가 어려운 느낌) 저는 이렇게 쓰고 있지 않은데 조직이 커지면 꽤 괜찮은 방법이라고 생각합니다.

그 외에도 GitHub의 검색 기능과 Owner를 사용해서 너무 많은 알림이 오지 않도록 관리하고 알림이 왔을때 검토를 빨리 해야겠다는 느낌을 줄 수 있게 관리하고 있다고 합니다.

코드 리뷰 자체에 대한 상세한 안내도 되어 있는데 가능한한 구체적으로 설명하고 개선을 요구하는 리뷰로 작성하는 것을 권장하며 리뷰를 받았을 때 뭘 해야할지 확실히 알수 있게 한다는 점이 좋았습니다. 코드 리뷰에서 질문을 하는 것을 아주 좋아하고 때로는 긍정적인 평가를 남기는 것도 협업에 큰도움이 된다고 합니다. 일에 집중하다보면 동료끼리 이런 점을 놓치기 쉬운데 칭찬댓글 하나씩 남기는건 꽤 좋다고 생각합니다.

병합이 너무 병목이 되지 않도록 승인하고 있고 Request changes는 강압적으로 보일 수 있어서 거의 사용하지 않는다고 합니다. 제가 있는 팀에서도 명확히 한다는 의미로 Request changes를 꽤 쓰다가 일부 사람에게는 이러한 요청이 부정적인 느낌으로 다가와서 논의후에 사용하지 않기로 했었기 때문에 이부분도 공감이 되었습니다.

https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/