Zenn
🪄

Google コードレビュー・ガイドライン要約【コードレビューの進め方編】

2024/11/04に公開
コードレビュー
tech

はじめに

本記事は「Google コードレビュー・ガイドライン要約」シリーズの【コードレビューの進め方編】です。
Google Engineering Practices Documentation (日本語訳) の要約になります。

未読の方は、はじめに 本記事のポジションと用語 をお読みください。

https://zenn.dev/hiroto_ohira/articles/32f50da373ca06

シリーズ構成

※リンクが貼られていない箇所は未要約です

コードレビューの進め方

Step1: 変更を広く眺める

  • 大まかな把握
    • CL のディスクリプションを読み、CL が大まかに何をしているかを確認する
    • この変更は機能しているか、確認する
  • 必要性の判断
    • [OSS] そもそもこの変更が行ってはならないものであれば、その理由を添えてすぐに返信する
      • まず、CL 提出への感謝を伝える
      • 変更を却下する場合、代わりに何をすべきかを開発者に提案するのは良い
    • [OSS] 例えば、このように伝えることができる

      良い仕事をしたようですね、ありがとう！
      しかし、実はあなたがここで修正しようとしているFooWidgetシステムは削除する方向で進んでいます。
      その代わりに、新しいBarWidgetクラスをリファクタリングするのはどうでしょうか？

Step2: 主要部分を調べる

  • イシューから始める
    • CL の「メイン」になっているファイルを見つける
      • よくあるのは、ロジック上の変更が最も多いファイル
    • CL が巨大なとき
      • 開発者にどこを最初に見るべきか質問してもよい
      • CL を複数の CL に分割するように依頼してもよい
  • 重大な問題を見つけたとき
    • 主要部分に設計上の重大な問題が見つかれば、すぐにコメントを残す
      • 残りの部分をレビューする時間があっても、コメントを送るのが先である
    • 実際、残りの部分をレビューしても時間の無駄になることもある
      • 設計上の問題が重大なものであれば、レビュー対象の他のコードは消されることになり、見ても見なくても関係なくなる
  • 問いかけリスト
    • 全体として CL に設計上の重大な問題がないことが確認できましたか？

Step3: 残りを適切な順序で見る

  • 処理順序の把握
    • 全ファイルを一通り見て、論理的な順序を理解する
  • 処理内容の把握
    • 実装の前に、まずテストを読むことが効果的な場合もある

おわりに

主要部分から見て、早い段階フィードバックすることで、全体の手戻りを少なくする手法が学びでした。
Google のようなレビュー環境とは異なる部分がありますが、ぜひ取り入れたいと思いました。

参考文献

Discussion