先日、会社の同僚の方に勧められて Google Engineering Practices Documentation の Google’s Code Review Guidelinesを読んだ。
このドキュメントは、Googleが様々なプログラミング言語やプロジェクトで培ったベストプラクティスのまとめをオープンソースとして公開しているものである。Google’s Code Review Guidelinesはレビュアー用のガイドとレビュイー用のガイドに分かれている。
ちなみにこのドキュメントには非公式な日本語翻訳もある。自分は基本こっちを読みつつ、わかりにくいところは原著にあたるようにした。
google-engineering-practices.translation.shuuji3.xyz
それぞれ内容も多くなく、全体として数ページしかないのでサクッと読みやすかった。
また内容もコードレビューの基準、期待値、レビューの進め方、レビューのスピード、レビューコメントの書き方など多岐に渡っている。実際に明日から取り入れられるような具体的なHowも書いてあるので、理解しやすかった。またレビュー時の反対意見の書き方や不満が生まれてないような振る舞い方などにも触れている。経験に基づいた内容だと感じた。
明日からできることを考える
このガイドラインを守破離の守として、具体的に明日からのコードレビューでできそうなことをNext Actionとして積む。
- PR に対してシステムが今よりも良い状態になっているのであれば、Approveする。完璧を求めない
- PR を読むときは diff だけではなく、システム全体のコンテキストから妥当かを判断する。
- PR に何か優れたところがあったときには、コメントやチャットで伝える。
全部やるのは難しいので、適宜見返しつつやろうと思う。
感想
人間は知ったかぶりをしてしまう生き物だと自覚しておきたいなと思った。
PRを読んでいてなんとなく合ってそうでApproveするには一番避けたいし、ありがちなことだと思う。例えば、よくわからないアーキテクチャや知らないメソッドが出た場合は、その都度調べることができるので理解は進む。しかし、なんとなく知ってるメソッドだったり、他のリポジトリで使われているコードだったりすると、そもそも疑問が湧かない。なので特に調べずに、わかった気になってしまう（結果 Aprprove してしまうこともある）。
エンジニアリングの文脈ではないが、最近読んだ本にも似たような話が書かれていた。
一歩深いレビューをするためには、自分でもドキュメントを読んだり、実際に手元で動かしたり（動かしたログを読んだり）して、ある種批判的に見て行く必要があると感じた。抗いたい。
