2025年10月18日
今週の活動
- メソッド単位のメトリクスの再検討
- 現在使用しているメトリクス
- メソッド単位
- 循環的複雑度の変化量
- コード行数の変化量
- トークン数の変化量
- メソッドに対する操作が「追加・変更・削除」のいずれのタイプであるかを表すラベル
- コミット単位
- 変更されたファイル数
- 変更前の総行数に対する、追加されたコード行数の割合
- 変更前の総行数に対する、削除されたコード行数の割合
- 1ファイル当たりの平均行数
- メソッド単位では主に変化量、コミット単位では主に変化率をメトリクスとして用いている
- メソッド単位での測定はコミット単位での測定よりも粒度が細かいため、変化率を採用すると特に小規模なメソッドにおいて値が不安定になり、予測精度に影響を与える可能性がある
- メソッド単位のメトリクスとして変化量の代わりに変化率を用いても精度向上は期待できない
- レビューの労力削減効果の分析手法の検討
- Cost-Benefit CurveとEffort-Aware Metricsがある
- Effort-Aware MetricsはCost-Benefit Curveの20%地点の値であるが、20%をしきい値とする根拠が弱い（先行研究では20%を基準としていたが、研究によってばらつきがある）
- Cost-Benefit Curveのグラフにおいて、全てのモデルの曲線を重ねて表示し、補足的に特定の労力レベル（10%、20%、30%地点）での性能を表で示せばいい
得られた成果
- メソッド単位のメトリクスで変化量を用いるのが妥当である理由
- 単一のメソッドを分析するため、スケールが比較的均一
- 小規模なメソッドの分析では、変化率が極端に大きかったり小さかったりするため、バグ予測においてノイズとなる
- 実際のコード変更の大きさに着目すると、「2行の追加」と「50行の追加」では明らかに後者の方がレビュイーとレビュアーの双方にとって作業の負荷が高く、欠陥発生率が高くなる傾向にある
- コミット単位のメトリクスで変化率を用いるのが妥当である理由
- 複数のファイル・メソッドが含まれることが多く、変更規模が多様
- 変化率を用いれば変更対象となるファイルに対する影響を測定できる
- 変化量を用いると大規模なコミットほどバグ修正コミットであると判定されやすくなるが、変化率を用いることで小規模だが予測精度に影響を与える欠陥混入や欠陥修正を検出しやすくなり、予測基準のバランスが良くなる
来週の計画