Critique - Googleが開発者満足度97%でコードレビューの苦痛を減らす方法

• 多くの元Google社員が懐かしむGoogleのコードレビューツール「Critique」
• Google社内での調査によると、開発者の97%がCritiqueに満足しているという

Googleのコードレビューガイドライン

• 完璧さよりも継続的な改善を推奨
• コードベースの状態を維持または改善
• スタイルガイドに従う
• 常に知識を共有する: コードレビューを通じて、言語機能、コードベース、およびその他の関連アーティファクトに関する知識共有を推奨
• 変更は小さく作成する（およそ200行程度）
• 迅速さに対する厳格な基準（24時間以内にコード変更をレビュー、できればレビュアーは1人）
• 丁寧さと専門性: 信頼と尊重の文化を維持することが重要

Critique: Googleのコードレビューツール

• エンジニアがコード変更を効率的にレビューし、提出できる
• 最近の論文 - Resolving code review comments with MLによれば、包括的なAIベースのコードレビューツールを使用中
  • レビュアーがコードにコメントを残すと、CritiqueでMLベースの編集提案が表示される
  • コードレビューの作成者は、ボタンを1回クリックするだけで、そのコメントに対応する修正をまとめて適用できる

コードレビューの流れ

• ステップ1: 変更を作成
  • CL（またはPull Request）はGoogleの社内コードエディタ Cider で作成される
  • Critiqueやその他の社内Googleツールと緊密に統合されており、開発者の生産性を高める
  • Prereviewツール: レビュー前に変更を整え、差分、ビルドとテスト結果、スタイルチェックを表示
  • Diff表示と可視化: 構文ハイライト、相互参照、インライン差分、空白無視、移動検出機能
  • 静的解析ツールの結果を表示して重要な結果を強調し、修正提案を提供。Critique内で実行される自動テスト「presubmits」も含む
• ステップ2: レビューを依頼
  • Pull Requestのレビュー準備ができたら、コード作成者はレビュアーを追加し、正式にレビューへ送る
  • レビューのためにPR/CLが送信されると、現在のコードスナップショットでまだ実行されていない場合は「Presubmits」が実行される。これにより、レビュー参加者全員がコードに問題があるかどうかを把握できる
  • コードレビューを匿名化して、コード作成者をレビュアーに対して匿名に保つこともできる。ただしGoogleは、匿名コードレビューと「通常の」コードレビューの間に有用な差は見いだせなかった
• ステップ3と4: 変更を理解してコメントする
  • 誰でも変更にコメントでき、レビューの進行状況を追跡し、コメントを解決できる機能を提供
  • 未解決コメントは、変更作成者が確実に対応すべき作業項目を示す。これらのコメントは、コード作成者がコメントに直接返信したときに「解決済み」と表示できる
  • 解決済みコメントには、変更作成者の対応が不要かもしれない任意のコメントや情報提供コメントが含まれる
  • レビュー状況を確認できるダッシュボードと、特定のコードレビューに参加した人たちが現在誰の対応待ちなのかを把握できる「Attention Set」がある
• ステップ5: 変更を承認
  • 上で述べたように、レビューを通すには少なくとも1人のレビュアーからLGTM（Looks Good To Me）を得る必要がある
  • コード作成者はコメント時に自分で解決済みとしてマークできるが、未解決コメントは0件でなければならない
  • さらに、コードが入るコードベース部分のオーナー承認と可読性承認が必要
  • これらすべてを1人のレビュアーが担うこともできる
• ステップ6: 変更をコミット
  • Critique自体の中で変更を提出し、コミットする
  • Critiqueは変更提出後も有用

  • 「Googleの研究者たちは、Critiqueの用途がコードレビュー以上に広がっている強力な証拠を見つけた。変更作成者はCritiqueを使ってDiffを確認し、解析ツールの結果を調べる。場合によっては、コードレビューは変更開発プロセスの一部として使われ、レビュアーは実装をどう完成させるかを決めるために未完成の変更を送ることができる。また開発者は、変更が承認された後でも、提出済み変更の履歴を確認するためにCritiqueを使う。」

Googleの最新コードレビュー統計

• 変更作成頻度:
  • 中央値: 週3回変更
  • 作成者の80%は毎週7件未満の変更
• レビュー頻度:
  • 中央値: 週4件の変更をレビュー
  • レビュアーの80%は毎週10件未満の変更を処理
• 週あたりレビューに費やす時間:
  • 平均で週3.2時間
  • 中央値で週2.6時間
• 初回フィードバック待ち時間:
  • 小さな変更: 平均1時間未満
  • 非常に大きな変更: 約5時間
• レビュープロセス全体の時間:
  • すべてのコードサイズでの平均遅延時間: 4時間未満
  • 他社との比較:
    • AMD: 17.5時間（承認までにかかる時間の中央値）
    • Chrome OS: 15.7時間
    • Microsoftプロジェクト: 14.7時間、19.8時間、18.9時間
    • Microsoft（別研究）: 24時間

なぜCritiqueはGoogle社員に愛されるのか

• 静的解析: コードに対して実行可能なフィードバックを自動で提供するフル機能の静的解析ツール群を備える。これによりコード作成者もレビュアーも時間を節約でき、レビュアーは明らかな項目をいちいち指摘する必要がない
• 直近で変更されたファイルだけに集中: コードの最新「スナップショット」にだけ集中できる。以前のスナップショット、コミット、コード変更は表示されないため、UIがよりすっきりしている
• 馴染みやすいSide-by-Side Diffインターフェース: デフォルトで「前回レビューとの差分」を表示
• 機械学習ベースの提案: Googleの新しいMLベース提案機能によってコードレビュー速度が大幅に向上
• 他のGoogleツールとの緊密な統合: CritiqueはGoogleのIDEやバグトラッカーなど他の社内ツールと非常によく統合されており、生産性が向上する。コード、コメント、チケットの容易な関連付けも含まれる
• 「作業セット」の追跡: 次に誰が作業すべきかが分かる
• 満足感のあるゲーミフィケーション: Critiqueはゲーム化を意図して設計されたわけではないが、Google社員はCritiqueが「緑に変わって」PR提出の準備が整ったとき（すべてのテスト通過、レビュアーのLGTM承認）、楽しかったと語る
• Redditに付いたコメント
  • 膨大なコードを非常に効率よくレビューできる驚くべきキーボードショートカット
  • デフォルトで「前回レビューとの差分」を表示
  • 「コード移動検出」機能があり、コードの変更点に集中できる
  • レビュアーでも作成者でも、誰が対応すべきかを知らせる優れた機能を提供
  • Chrome拡張機能と一緒に使うと通知を簡単に受け取り、レビュー待ちキューを確認できる
  • 社内では誰でもコードレビューのデータに対してクエリを実行してインサイトを集められる
  • コードとコメントの自動リンク（チケットおよび移動/リンクを含む）
  • 複数ラウンドのコードを含むPRの進行状況をはるかに理解しやすくするため、PRの解析と履歴、コメントを表形式で見られる
  • 任意、参考などコメントの用語/タグが非常に一貫している

考えと示唆

• これらの機能の多くは今日では他のツールでも利用できるが、このツールが愛される理由は、Google固有のワークフローとコードベースに対するツールの緊密な統合と極度の「個別最適化」にあるのだと思う
• 同時に、すべての会社がCritiqueや関連ツールを正確に複製するのは現実的に不可能であることも意味する。たとえば一部のツールは、モノレポ構造によって生じる問題に特化している
• Critique自体はオープンソースとして提供されていないが、GerritはCritiqueに似たツールで、これもGoogleが作成し維持しているオープンソースのコードレビュー ツール
• それでもGoogleは開発者の生産性向上のために多大な努力と思考を重ねているのだと思う。彼らは自分たちの研究を自由に公開しており、そこから有用な示唆を得ることができる

[xguru]

Gerrit に ChatGPT を組み込もうとする試みはあるようですね
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

[kkweon]

いちばん大きく感じる点は、Critique では連続した一連の CL をレビューできることですね。GitHub では PR チェーンを直接サポートしていないのが不便です。そのため、1つの大きな PR にするか、前の PR がマージされるまで待たなければなりません。

[tested]

GitHub にも似たようなものがあるけど、いつ公開されるのか
> https://githubnext.com/projects/copilot-for-pull-requests

[winterjung]

静的解析やMLベースの提案はありませんが、記事を読むとGitHubのレビュー機能とかなり似ていますね。GitHubレビューをよく使う立場としては、Critiqueで提供されるほかの機能もさらに導入されるといいですね。

[xguru]

Googleのコードレビューガイド［韓国語訳］