Googleのコードレビューガイドから学んだこと3選

要約

①コードは理解しやすさでレビューする

②コードレビューは迅速に行う

③レビューコメントでは、「なぜか」という理由を説明する

はじめに

最近、コードレビューの機会が増えてきました。コードレビューなかなか大変ですよね。何をどこまで確認すればいいのか、自分のタスクもある中で何も考えずにレビューをしていると、効率が落ちて自分のタスクを中々片付けられないことがありました😇

世の中のエンジニアは、どうやってレビューしているんだろうと調べた結果、Googleのコードレビューガイドに行きつきました。

今回は、Googleのコードレビューガイドから特に学びになった点を3つに絞って、具体的な学びやNextActionをまとめました。

①コードは理解しやすさでレビューする

一般に、ある CL が作業対象のシステムのコード全体の健全性を具体的に向上させる状態に一度でも達したならば、たとえその CL が完璧なものでなくても、レビュアは承認を賛成しなければならない。

CL は必要以上に複雑ではないでしょうか？ これは CL のあらゆるレベルで確認してください。1行1行、どの行も複雑ではないですか？ 「複雑すぎる」とは、通常「コードの読み手が素早く理解できない」という意味です。
また、「開発者がこのコードを呼び出したり修正しようとしたときにバグが入り込みやすい」と言うこともできます。

• 当初コードレビューにアサインされた時、コードを端から端まで眺めて気になった部分にコメントしていました。それだとレビューの抜け漏れが発生しやすく、また細かいところに気を留めすぎて重要な部分を疎かにしてしまうことがありました。
• 重要なのはコードの理解しやすさ であり、動作としては問題なく、スマートな書き方ではあるものの、複雑すぎる場合は指摘することも必要です。

💡 NextAction

• 改善点ではあるが、重要度が低い場合、Nit:(些細な点)などのキーワードをつける
• スタイルガイドに、書いていないコードには作者のスタイルに合わせる
  • チームとしての書き方として統一したい場合は、スタイルガイド・コードフォーマッターに追加する
• 複雑すぎる場合は、よりシンプルな実装を提案する

②コードレビューは迅速に行う

集中状態にあるタスクがない場合には、**レビュー対象のコードが来たすぐ後にコードレビューを行なわなければなりません。**コードレビューリクエストに対して、返事をするまでに掛けることが許される最大の時間は、1営業日です。 (つまり、最低でも翌日最初にするべきです。)

• コードレビューはチケット上で見えないということもあり、優先度として下がってしまいがちだと思います。当初は自分のタスクを行っている際にコードレビュー依頼が来たら、自分のタスクを片付けてからコードレビューを行っていました。
  • コードレビューも一回のやり取りで終わるものは少なく、何回か往復のやり取りを経てマージに持っていくと思います。そうすると、次のレビュー依頼が来てどんどんPRが溜まっていく状態になってしまい、なかなか片付かないという状況が生まれてしまっていました😢
• ベストはコードレビューは直ぐに行い、できるだけ早くPRをマージにまで持っていくことが大切です。コードレビューを最優先にすると、自分のタスクを片付けられないのでは、という懸念もありますが、結果的にはレビューをすぐに対応した方がチームとしても個人としても生産性が上がると思います。
  • コードレビューを優先的に行うメリットは以下の記事でも紹介されています。
    チームで1年間コードレビューを最優先に実施したら開発生産性に良い影響を与えてくれたかも

💡 NextAction

• コードレビューは1日以内に返す
• 中断するわけではなく自身の作業が一区切りついたタイミングで、レビューを行う
• コメントが分散しすぎてしまってり、複雑過ぎる場合は口頭で伝える
• レビューの修正自体も早めに対応してもらう様に依頼する

③レビューコメントでは、「なぜか」という理由を説明する

上の「よい」例で気がつくことの1つは、開発者が**「なぜか」という理由 (why)** を理解することをコメントが助けているという点です。あなたのレビューコメントに常にこの情報を加える必要はありませんが、あなたのコメントの意図、あなたが従っているベストプラクティス、あなたの提案でコードの健康状態がどのように改善するか、などの追加説明を加える方が適切なこともあります。

• 最後はより意識していきたいなと思ったポイントです。タスクに追われている中で、修正箇所を指摘して「こうした方がよさそうです」というコメントをさくっと打つ方がレビューとして早いと思いますが、それだとレビュイーは何が良いのか分からず、また同じ実装をしてしまう可能性があります。
• 「なぜか」をコメントに加えることで、レビュイーが同じ実装を繰り返すことを防いだり、レビュアーとしても、自分が当たり前だと思って特に考えていなかったプラクティスを言語化することで、何がいいことで、何が良く無いことなのかを改めて考える機会にもなると思います。
  • 相手に説明できる言語化能力、引き出しが広いのがジュニアエンジニアとミドルエンジニアの壁なのかなと個人的には思っています。

💡 NextAction

• コメントでは「なぜか」という理由も加える
• コードを実際に書いて提案する
• 記事を引用して説明する

参考文献

How to do a code review

• ネット上で公開されているGoolgeのコードレビューガイド
  • 無料で読めるので読んだことのない方は、一度読んでみることをオススメします。

コードレビューの方法

• 日本語に翻訳いただいているバージョンもあります。