これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
前回に続いて、2024年に公開された論文「Productive Coverage: Improving the Actionability of Code Coverage」を紹介します。この論文では、テストコードの実行範囲を調べるコードカバレッジツールに、対応を検討した方がよさそうなポイントを自動で指摘する機能を追加した事例が紹介されています。今回は、この機能が実際のレビュープロセスに及ぼす効果について説明します。
この論文の主題はコードカバレッジツールの機能拡張ですが、論文内ではコードカバレッジツール自体の効果についても議論しています。レビューツールにコードカバレッジツールを組み込むことにより、テストされるコードの増加、および、レビュー時間の短縮という効果があるという仮説を立てて、これを実環境による実験で検証しています。具体的には、実験期間（3ヶ月間）において、コードカバレッジツールの実行結果の内、約半数を意図的に表示しないようにしました。図1の「Control」は通常通りに表示した件数で、「Experiment」は意図的に表示しなかった件数です。
図1 コードカバレッジツール自体の効果を調べるための調査方法（論文より抜粋）
また、レビュアーは、コードカバレッジツールの実行結果に対する詳細をログから確認することもできます。図の「No logs」と「Logs」は、レビュアーがログを確認しなかったケースと確認したケースに対応します。「Experiment（Logs）」は、コードカバレッジツールの結果が表示されないにもかかわらず、レビュアーがログの確認を試みたケースで、この場合は、「コードカバレッジツールの実験中でログは確認できない」という旨のメッセージが表示されます。ただし、ログが見れないとコードレビューに支障をきたすと判断した場合は、実験対象からオプトアウトしてログを確認することもできます。図の「Opt-out」はそのようなケースに対応します。
これらのケースを元にして、「Control」と「Experiment」でレビュー後のテストされるコードの増分に違いがあるか、あるいは、レビュー時間に違いがあるかをレビューツールのログなどから確認します。結論としては、テストされるコードの増分には有意差がなく、一方、レビュー時間には短縮効果が見られました。つまり、テストコードの不足については、コードカバレッジツールがなかったとしても、既存のレビュープロセスによって十分に発見されている一方、コードカバレッジツールの補助によりレビュアーの作業時間が短縮されるということです。
続いて、コードカバレッジツールの機能拡張に対する効果を紹介します。論文では、この機能拡張を「Productive coverage」と呼んでおり、図2は、Productive coverageの段階的なロールアウトの様子を示します。前回の記事で説明したように、Productive coverageは、テストされていないコードの中で、対応を検討した方がよさそうな部分をコメントするものですが、導入直後は、コメント対象と判定されたものの中でも、一部だけを実験的に表示しました。その後、ユーザーのフィードバックを見ながら、段階的に表示するコメントの割合を増加した様子が示されています。
図2 Productive coverageツールの段階的ロールアウト（論文より抜粋）
前回の記事の図2にあるように、レビュアーは、「Please fix」ボタンで開発者に対応を依頼するほか、Thumbs up / downボタンで明示的にフィードバックを返すことができます。次の図3は、「Please fix」もしくはThumbs upを押したものをPositive、Thumbs downを押したものをNegativeとして、フィードバックの変化を時系列に示したものです。「Mixed feedback」は複数のレビュアーが異なるフィードバックを返したものになります。ここでは、グラフの縦軸が対数スケールになっている点に注意してください。
図3 Productive coverageに対するフィードバックの変化（論文より抜粋）
この図を見ると、大部分はフィードバック無し（No feedback）ですが、PositiveとNegativeの割合を見ると、最終的には、PositiveはNegativeの10倍程度になっており、レビュアーの多くは、Productive coverageの機能に満足していることがわかります。また、Productive coverageの導入によって、レビュー時間がさらに短縮される効果も確認できたということです。
そして、Productive coverageの導入によって、実際にテストされるコードが増加するかどうかですが、これには有意な変化はありませんでした。前述のように、コードカバレッジツールの有無に関わらず、テストコードの不足は十分に発見されているため、コードカバレッジツールをさらに機能拡張してもそれ以上の変化はなかったということです。
ただし、Productive coverageで指摘されたコードの修正内容については、興味深い変化がありました。次の図4は、レビュー開始前とレビュー開始後で、Productive coverageで指摘された部分のコードがどのように変化したかをdiffツールで自動分析した結果になります。
図4 Productive coverageが指摘したコードの変化（論文より抜粋）
ここでは、先の図3で用いたフィードバックの種類ごとに分けて示されていますが、フィードバックがPositiveなものは、他に比べて「Removed（削除）」の割合が大きくなっています。これは、該当部分のコードが実際に削除された他に、diffツールではどのように変化したかが判別できないものも含まれます。そこで、Removedと判定されたもの中から200件をサンプリングして、実際の変化を確認したところ、該当のコードが不要と判断されて削除されたものの他に、diffツールでは判定できない形でリファクタリングされたものなどが含まれていました。言い換えると、Productive coverageの指摘によって、該当部分のコードをより詳細に確認する機会が得られて、コードの品質改善につながったものと考えられます。
今回は、2024年に公開された論文「Productive Coverage: Improving the Actionability of Code Coverage」に基づいて、コードカバレッジツールの機能拡張がレビュープロセスに与えた効果について説明しました。
次回からは、Cloud DatastoreからFirestore（Datastoreモード）へのデータマイグレーションに関する話題をお届けします。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
