コード レビューは大規模なソフトウェア開発プロセスの重要な部分であり、コード コミッターやコード レビューアーにとってはかなりの時間がかかります。このプロセスでは、レビュー担当者がコードに問題がないかレビューし、作成者にコードの変更を求めるコメントを書きます。Google では、毎年何百万もの査読者のコメントを目にしており、作成者はコメントのテキストに基づいてコメントに応答し、コードの変更を提案するのに約 60 分を費やしています。私たちの調査によると、コード作成者がレビュー担当者のコメントに対処するために費やさなければならない作業時間は、コメントの数に応じてほぼ直線的に増加します。ただし、機械学習 (ML) の助けを借りて、コード レビュー プロセスを自動化および簡素化できます。たとえば、コード レビュー コメントに基づいてコード変更に自動的に対応します。
現在、Google の日々の開発ワークフローでコード レビュー コメントを自動的に解決するために、シーケンス モデルにおける最近の進歩を採用しています (近日公開予定)。今日の時点で、Google のエンジニアは、ML が提案した変更を適用することで、コードレビューアによる多数のレビュー提案に対処できるようになりました。これにより、Google は毎年何十万時間ものコードレビュー時間を節約できると推定しています。機械学習によって提案されたコードの変更により、Google 開発者の生産性が実際に向上し、より創造的で複雑なタスクに集中できるようになったという非常に肯定的なフィードバックを多くいただいています。
コードの変更を予測する
まず、コメントに対処するために必要なコード変更を予測するモデルをトレーニングしました。モデルは、さまざまなコーディング タスクおよび関連する開発者のアクティビティ (変数の名前変更、ビルド中のエラーの解決、ファイルの編集など) に関して事前トレーニングされています。次に、レビューされたコードの変更、レビュー担当者のコメント、およびそれらのコメントに対処するために作成者が実行した変更を使用して、モデルは特定のタスクに合わせて微調整されます。
これは、ML の推奨事項に基づいたコードのリファクタリングの例です。
Google は単一のウェアハウス(モノリポ) を使用しています。これはソース コード管理戦略であり、すべてのコードとリソースは複数のウェアハウスに分散されるのではなく、同じウェアハウスに保存されます。この戦略には、コードの共有と再利用、大規模なリファクタリング、コラボレーション、依存関係の管理など、多くの利点があります。これにより、Google の最新ソフトウェアとその以前のソフトウェアを構築するために使用された膨大な量のコードをトレーニング データセットに含めることができます。
モデルの品質を向上させるために、トレーニング データセットを継続的に反復します。たとえば、ファイルごとに 1 人のレビュー担当者のコメントを含むデータセットと、ファイルごとに複数のレビューを含むデータセットでのモデルのパフォーマンスを比較し、分類子を使用して厳選された小規模なデータセットに基づいてトレーニング データをクリーンアップし、オフラインで最高の精度を備えたモデルを選択します。メトリクスを思い出してください。
サービスインフラストラクチャとユーザーエクスペリエンス
私たちは、全体的なユーザー エクスペリエンスと開発者の効率に重点を置き、トレーニング済みモデルに基づいてこの機能を設計および実装しました。その一環として、私たちは一連のユーザー調査を通じて、さまざまなユーザー エクスペリエンス (UX) の代替案を検討しました。次に、ユーザーのフィードバック (提案された編集の横に「役に立ちました」ボタンを追加するなど) を含む、内部ベータ (つまり、開発中の機能のテスト) からの洞察に基づいて機能を改良します。
最終モデルは、目標精度50% に調整されます。つまり、評価データセット内で提案された変更の 50% が正しくなるようにモデルと推奨フィルターを調整しました。一般に、目標正解率を高くすると、表示される編集候補の数が減り、目標正解率を低くすると、誤って提案される編集が多くなります。誤って提案された編集は開発者の時間を奪い、機能に対する開発者の信頼を低下させます。ターゲット精度が 50% であればバランスが良いことがわかりました。
大まかに言うと、新しいレビュー担当者のコメントごとに、トレーニング用と同じ形式でモデル入力を生成し、モデルにクエリを実行し、提案されるコード変更を生成します。モデルの予測に自信があり、追加のヒューリスティック ルールが満たされている場合は、提案された変更を下流システムに送信します。下流システム、つまりコード レビュー フロント エンドと統合開発環境 (IDE) は、提案された編集をユーザーに提示し、イベントのプレビューや適用などのユーザー インタラクションを記録します。専用のパイプラインがこれらのログを収集し、このブログ投稿で報告されている全体的な受け入れ率などの集約された洞察を生成します。
ML が提案する編集 ( ML が提案する編集) は、インフラストラクチャのアーキテクチャを編集します。複数のサービスからコードとインフラストラクチャを処理し、モデル予測を取得して、それらをコード レビュー ツールと IDE に表示します。
開発者は、コード レビュー ツールや IDE で ML が提案する編集を操作します。ユーザー調査からの洞察に基づいて、コード レビュー ツールへの統合が、レビュー エクスペリエンスの合理化に最適です。IDE 統合は追加機能を提供し、レビューされたコード状態 (右の画像) でローカル変更が競合する場合に、ML が提案する編集 (左の画像) とマージ結果 (中央の画像) の 3 方向マージをサポートします。
IDE での 3 方向マージのデモ
結果
オフライン評価では、このモデルが 50% の目標精度でレビューの 52% を解決していることが示されています。ベータ版と完全な社内リリースのオンライン指標は、これらのオフライン指標を裏付けています。つまり、すべての関連するレビューア コメントの ~50% で、モデル提案の信頼度が目標モデルの信頼度を上回っていることがわかります。コード作成者は、プレビューされたすべての提案された編集の 40% ～ 50% を適用しました。
ベータ期間中、私たちは「役に立たない」フィードバックを活用して、モデルの一般的な障害モードを特定しました。これらをフィルタリングするためにサービス時間ヒューリスティックを実装し、表示される誤った予測の数を減らしました。これらの変化により、私たちは量ではなく質を交換し、現実世界での受け入れの増加を観察しました。ベータ版の公開では、潜在的な問題が明らかになりました。コード作成者は、生成されたすべての提案された編集の約 20% しかプレビューしていませんでした。レビューアーのコメントの横に目立つ「ML 編集を表示」ボタンを導入することでユーザー エクスペリエンスを最適化し (上の画像を参照)、起動時の合計プレビュー率が約 40% に増加しました。また、コード レビュー ツールで提案された編集は、レビュー プロセス中に作成者によって加えられた変更と矛盾するため、適用できないことが多いこともわかりました。この問題は、コード レビュー ツールでマージ ビューを開いて編集を提案するボタンを使用することで解決しました。現在、これらの 70% 以上がコード レビュー ツールに実装されており、IDE に実装されているのは 30% 未満であることがわかります。これらすべての変更により、ベータ版から完全な内部リリースまで、ML が提案する編集によって解決されたレビューアー コメントの全体的な割合が 3 倍に増加しました。At Google では、毎年数十万件のレビューを自動的に解決しています。
推奨フィルターファンネル
実稼働環境では、幅広いレビュー担当者のコメントに対処する ML 提案の編集が見られます。これには、前述のブログ投稿の例に示されているように、単純な局所的なリファクタリングと、コード全体に散在するリファクタリングが含まれます。この機能は、コードの生成、リファクタリング、インポートを必要とする、長く非公式な表現のコメントに対処します。
コード生成、リファクタリング、インポートを必要とする、より長いコードレビューの推奨事項の例
モデルは、複雑なコメントに応答し、大規模なコード変更を生成することもできます (以下を参照)。生成されたテスト ケースは、既存の単体テスト パターンに従いますが、コメントに記述されている詳細は変更されます。さらに、編集者は、テストのセマンティクスを反映する包括的なテスト名を提案しました。
複雑なコメントに応答し、大量のコード変更を生成するモデルの機能の例
結論と今後の取り組み
この投稿では、コードレビュー関連の変更に費やす時間を削減するための機械学習 (ML) 支援機能を紹介します。現在、Google が使用しているプログラミング言語の実用的なコード レビュー コメントの大部分は、ML が提案する編集を適用することで解決できます。すべての Google 開発者を対象に実施する 12 週間の A/B 実験では、開発者全体の生産性に対するこの機能の影響をさらに測定します。
私たちはテクノロジースタック全体を完全に最適化しています。これには、モデルの品質とリコールの向上、開発者にスムーズなエクスペリエンスを提供すること、エクスペリエンスを向上させるための検出機能の向上 (ユーザーがあまり時間をかけずに必要な機能をすぐに見つけられるようにする明確なインターフェイスとナビゲーションを提供すること) とエネルギーが含まれます。レビュープロセス全体の。この一環として、レビューアーがコメントの下書きを作成するときに ML が提案した編集を表示する機能に取り組んでいます。また、コード変更の作成者がレビューアーの説明の提案を受け取ったらすぐに ML のコード変更を取得できるように機能を IDE に統合することに取り組んでいます。 。
ありがとう
これは、Google のコア システムおよびエクスペリエンス チーム、Google Research、DeepMind の多くの人々による共同研究の結果です。私たちのコラボレーションをサポートしてくれた Peter Choy と、重要な貢献と有益なアドバイスをくれたチームのメンバー全員 (Marcus Revaj、Gabriela Surita、Maxim Tabachnyk、Jacob Austin、Nimesh Ghelani、Dan Zheng、Peter Josling、Mariana Stariolo、Chris を含む) に特に感謝します。ゴルゴレフスキー、サッシャ・ヴァルケヴィッサー、カーチャ・グリュンヴェデル、アルベルト・エリゾンド、トビアス・ウェルプ、ペイジ・ベイリー、ピエール＝アントワーヌ・マンザゴル、パスカル・ランブラン、チェンジ・グー、ペトロス・マニアティス、ヘンリク・ミハレフスキー、サラ・ウィルトバーガー、アンバー・ムリージョ、サティシュ・チャンドラ、マドゥラ・ドゥッド・ガオンカル、ニランジャン・トゥルプル、ズービン・ガラマニ、フアンジョ・カリン、ダニー・ターロウ、ケビン・ヴィレラ、ストヤン・ニコロフ、デヴィッド・タッターソール、ボリス・ボコウスキー、キャシー・ニックス、メディ・ギッサッシ、ルイス・C・コボ、ユジア・リー、デヴィッド・チョイ、クリストフ・モルナール、ヴァヒド・メイマンド、アミット・パテル、ブレット・ウィルシャー、ローラン・ル・ブラン、ミンパン・グオ、ヘルマン・ルース、ジョナス・マテス、サビニー・ダンクス。
元のリンク: https://ai.googleblog.com/2023/05/resolve-code-review-comments-with-ml.html