Do Static Analysis Tools Affect Software Quality when Using Test-driven Development?
アブストラクト
- テスト駆動開発 (TDD) はアジャイルソフトウェア開発の実践であり、開発者がテストに合格するために「迅速で汚い」プロダクションコードを作成し、「クリーンな」コードにリファクタリングを適用することを奨励する
- しかし、これまでの研究では、リファクタリングはTDDプロセスが必要とするほど頻繁に適用されず、ソフトウェアの品質に影響を与える可能性があることが分かっている
- 統合開発環境 (IDE) にインストールされた静的解析ツールをソフトウェアの品質に活用することの利点を、TDDを適用するときに調査した
- 参加者は、静的解析ツールを使う場合と使わない場合に分かれ、TDDを適用して実装タスクを実施した
- 全体として、静的解析ツールの使用は参加者がソフトウェアの品質を大幅に改善するのに役立ったが、参加者はTDDを実行するのがより難しい認識していたことが分かった
はじめに
- テスト駆動開発 (TDD) はアジャイルソフトウェア開発の実践であり、プロダクションコードの前にユニットテストが記述される
- より詳細には、TDDはソフトウェア機能を段階的に実装するために、それぞれ3つのフェーズで構成される短いサイクルを促進
- レッドフェーズ
- まだ実装されていない機能の小さなかたまりに対してユニットテストを作成し、そのユニットテストが失敗するのを監視
- グリーンフェーズ
- ユニットテストにできるだけ早く合格させるために必要な技術的負債を考慮し、全てのユニットテストが合格するのを監視
- リファクタリングフェーズ
- コードをリファクタリングし、ユニットテストに合格するために作られた技術的負債を返済し、全てのユニットテストに合格するのを監視
- TDDでは、ソフトウェアの外部動作を維持しながら、ソフトウェアの品質を継続的に向上させることができるため、リファクタリングが重要な役割を果たしている
- それにもかかわらず、リファクタリングフェーズがしばしばスキップされることがある
- 例えば、RomanoらはリファクタリングはTDDが必要とするほど頻繁に実行されず、リファクタリングフェーズが他の2つよりも重要ではないと誤って認識されていることを観察した
- リファクタリングフェーズをスキップすることは、リファクタリングの機会がない場合にのみ問題ない
- その他の場合には、このフェーズをスキップすることは、ソフトウェアの品質に悪影響を及ぼす
- 本論文では、TDDを使用してソフトウェアを開発する際に、静的解析ツールを使用することがソフトウェアの品質に及ぼす影響を研究
- 参加者は、TDDを適用してJavaで実装タスクを実行する必要がある2つの実験を実施
- 参加者は、Eclipse IDEのプラグインの1つとして、静的解析ツールであるSonarLintを使用し、コーディング中にコードの臭いを強調するように構成されたグループと、SonarLintを使用しないグループの2つのグループに分けられた
- 最初の実験 (Exp1) にはコンピューターサイエンス (CS) の学士課程の3年生68人が参加し、タスクを実行するために3時間半を費やした
- 2番目の実験 (Exp2) では、CSの修士課程の1年生24人を対象に、参加者に固定された時間制限を与えずに実施
- SonarLintの使用が、ソフトウェアの品質に関連する指標に関して、重要な違いを生み出すかどうかを測定
- 全体として、SonarLintの使用は、開発者がコードの臭いの削減、技術的負債の削減、コードの理解しやすさの向上という観点からコードの品質を大幅に改善するのに役立つことが分かった
- しかし、参加者は、SonarLintを使用するとTDDがより困難になることを発見した
計画と設計
- Jedlitschkaらの研究に基づくテンプレートを使用して実験の計画を報告
- 実験を計画し、実行する際には、JuristoとMoreno、およびWohlinらのガイドラインに従った
目標
- Javaでソフトウェアを開発するCSの学士課程および修士課程の学生の観点から、ソフトウェアの品質に関してTDDプロセスにおける静的解析ツールの効果を評価する目的で静的解析ツールの使用を分析
- 目標に従って、次のリサーチクエスチョン (RQ) を策定
- RQ: TDDを適用する場合に、静的解析ツールを使用する場合と使用しない場合でソフトウェアの品質に違いはあるか？
実験概要
- 実験への参加は任意かつ無料であり、実験が組み込まれたコースの最終成績に2つのボーナスポイントを与えた
- 学生に対して、以下の情報を伝えた
- 実験の成績に関係なくボーナスを受け取る
- 否定的に評価されることなく、いつでも実験から離脱できる
- 実験に参加しなくてもコースの最高点に達することができる
- 収集されたデータは機密として扱われ、研究目的のみに匿名で共有される
- Exp1
- 参加者はBari大学のCSの学士3年生
- 参加者は1年から9年の開発経験と、0年から8年のJava開発経験を持っていた
- Exp2
- 参加者はSannio大学のCSの修士1年生
- 参加者は2年から13年の開発経験と、2年から6年のJava開発経験を持っていた
実験材料
- Exp1とExp2の両方において、参加者は惑星上でローバーを移動させるためにMRA (Mars Rover API) という名前のAPIを実装する必要があった
- MRAはプログラミング演習で使用される人気のテーマである
実験タスク
- MRAの機能を11個のユーザーストーリーに分解した
変数、測定、仮説
- Exp1とExp2の両方において、参加者は静的解析ツールを使って、あるいは使わずに実験タスクを実行するように求められた
- 静的解析ツールを使う参加者はリファクタリングフェーズ中に静的解析ツールを用いてTDDに従う必要があった
- 静的解析ツールを使わない参加者は静的解析ツールのサポートなしでMRAを開発し、リファクタリングフェーズではコードをリファクタリングするためにTDDに従う必要があった
- SonarLintはコーディング中にコードの臭いを強調表示するが、開発者がその警告を無視するか対処するかを自由に選択できるため、SonarLintはTDDプロセスでの使用に適している
- 開発者はRedフェーズやGreenフェーズでの警告を無視し、リファクタリングフェーズで警告に対処できる
- ソフトウェアの品質を定量化するために考慮した指標
- Smell
- それぞれの参加者が開発したMRAコードベースでSonarQubeによって検出されたコードの臭いの数
- コードの臭いは、ソフトウェアの品質を向上されるためのリファクタリングの機会を示す指標
- SqaleIndex
- SQALE (Software Quality Assessment Based on Lifecycle Expectations) メソッドに基づいて、コードベースから全てのコードの臭いを除去するための推定時間として測定される技術的負債の推定値
- この指標はSonarQube, SQuORE, NDependなどを含む多くの静的解析ツールで使用されている
- WMC (Weighed Methods per Class)
- クラス内のメソッドの複雑化を測定する指標
- WMCはクラス内のメソッドの循環的複雑度の合計
- CognCompl (Cognitive Complexity)
- 認知的複雑度とも呼ばれ、コードの分かりやすさを表す
- ネストされた制御構造、条件分岐、ループなどの複雑さに基づいている
- BW (Buse-Weimer)
- CBO (Coupling Between Objects)
- クラス間の結合度を測定する指標
- あるクラスが他のクラスに依存している数を表す
- 値が大きいほど、そのクラスは多くの他クラスに依存していることを示し、モジュール性が低くなる
- RFC (Response For a Class)
- クラスの応答性を測定する指標
- クラスが直接または間接的に呼び出せる他クラスのメソッド数の合計を表す
- 値が大きいほど、テストの複雑さと潜在的なバグの可能性が増加
- LCOM (Lack of COhesion in Method)
- クラス内のメソッド間の凝集度の欠如を測定する指標
- メソッド間で共有される属性 (インスタンス変数) の少なさを表す
- 値が大きいほど、クラスの凝集度が低く、特定のクラスが複数の責務を持っている可能性が高い
- LOC (Lines of Code)
- コード量を測定する指標
- 物理的なコード行数やロジック行数 (コメントや空行を除く行数) などがある
- 値が大きいほど、コードの規模が大きいことを示す
- 値が大きいからといって必ずしも悪い訳ではないが、大きすぎる場合は複雑さや保守性の問題を引き起こす
研究デザイン
- 有効性への脅威に対処するために、Exp1とExp2の両方で、参加者を介入群 (静的解析ツールを使うグループ) と対照群 (静的解析ツールを使わないグループ) に分けた
手順
操作
- 参加者はTDDを適用してMRAの機能を共同作業なしで実装するように求められた
- 実験の開始時には、それぞれの参加者に11個のユーザーストーリーで構成されたMRAの機能、GitリモートリポジトリでホストされたEclipseのプロジェクトテンプレートが提供された
- 参加者は、テストスイートが合格するたびにコミットするように指示された
- タスクの最後に、参加者はローカルのコミットをリモートリポジトリに送信し、次にリモートリポジトリへのリンクを提供し、5段階のリッカート尺度でユーザーストーリーの理解、タスクのしやすさ、TDDのしやすさ、リファクタリングのしやすさ、リファクタリングの有用性についての認識に関する質問に答えた
- 参加者がコードをリファクタリングする必要があるときに、時間制限が影響を与えるかどうかを観察するために、Exp1では実験タスクを完了するために3時間半の時間制限を設定し、Exp2では参加者に時間制限を与えなかった
分析手順
- 収集したデータを以下の手順に基づいて分析した
- 個別分析
- それぞれの実験と処理について、記述統計を計算し、それぞれの中従属変数の値の分布を表す箱ひげ図を作成した
- 次に、それぞれの実験において帰無仮説を検定した
- 集計分析
- 2つの統計的手法を使用し、2つの実験間の共同結論を提示した
- 集計データ
- 標準化平均差 (Standardized Mean Difference)
- 2つの群間の平均値の差を標準偏差で割って標準化した指標
結果
個別分析結果
- Smell, SqaleIndex, WMC, CognComplに関しては、SonarLintの箱がNoSonarLintの箱よりも低い
- Exp1では、SonarLintを使用している参加者のコードベースは、SonarLintを使用していない参加者のものと比較して、コードの臭いが少なく、技術的負債の推定値が低く、複雑でなく、理解しやすい
- Exp2でも同様の傾向が確認されているが、SonarLintとNoSonerLintの違いは、WMCを除いてあまり顕著ではない
- BWに関しては、SonarLintとNoSonarLintの箱は両方の実験でほとんど重複しており、2つの実験グループ間でコードの読みやすさに大きな違いはないことを示唆している
集計分析結果
- Q検定とI2統計量を用いて、SonarLintの使用の有無による違いの有意性を測定した
- 最もよく使用される有意水準は0.1であるため、Q検定のp値が0.1未満の場合は有意であると仮定した
- I2統計量は、Q検定のp値が固定有意水準未満の場合に、実験間の違いの程度を測定するために使用される
- Smell, SqaleIndex, CognComplに関しては、NoSonarLintとSonarLintの間に統計的に有意な差がある
- WMCとBWに関しては、統計的に有意な差はない
その他の結果
- Exp1では、SonarLintを使用するとリファクタリングの数がわずかに多くなる
- Exp2では、リファクタリングの数は両方の実験グループで同じ
- Exp2でSonarLintを使用した参加者は、Greenフェーズでコードの臭いをリアルタイムで修正したと推測している
実験後のアンケート
- どちらの実験では、参加者の大多数が実装されるユーザーストーリーの分かりやすさについて合意していた
- 参加者の認識に基づけば、ユーザーストーリーの分かりやすさは実験に脅威をもたらさなかったと言える
- タスクのしやすさに関しては、合意の割合が比較的低く、特にExp1では参加者の半数がタスクのしやすさを中立的であると認識していた
- 参加者は、SonarLintが使用されていない場合にTDDがしやすいと考えており、その差はデータセット全体で統計的に有意である
妥当性に対する脅威
- ボランティアは全ての集団よりも動機付けられているため、選択の脅威が結果に影響を与えた可能性がある
- 実験タスクの実行中にExp2の参加者を監視できなかったため、拡散/治療模倣の脅威がある可能性がある
- SonanrLintを使用することでソフトウェア品質にプラスの効果があることが分かったが、考慮されていない構成要素にはSonarLintによる副作用がある可能性がある (一般化可能性が制限される脅威)
- ガイドラインの提供と参加者の監視をしても、参加者が増分コミットを行わずにリファクタリングを実行し、検出ツールに見えないようにした可能性を排除できない
議論
- TDDプロセスで静的解析ツールを使用することは、コードの臭いの削減、技術的負債の削減、コードの分かりやすさの向上という観点においてソフトウェアの品質にプラスの影響を与えることが分かった
関連研究
TDDに関する研究
- TDDは、開発者の生産性を向上させながら、外部品質と内部品質の両方の観点から、より高品質なソフトウェアを提供するのに役立つと主張されている
結論と今後の研究
- 実験の結果から、静的解析ツールの使用はコードの臭いの数を削減するのに役立つだけでなく、推定される技術的負債を削減し、技術的負債を削減し、コードの分かりやすさを向上させることが示唆される
引用情報
- 著者: Simone Romano, Fiorella Zampetti, Maria Teresa Baldassarre, Massimiliano Di Penta, Giuseppe Scanniello
- タイトル: Do Static Analysis Tools Affect Software Quality when Using Test-driven Development?
- 雑誌 / 会議名: Proceedings of the 16th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement
- ページ: pp. 80–91
- 出版日: September 2022
- DOI: https://doi.org/10.1145/3544902.3546233