Windows 7開発時のリファクタリングを報告した論文

論文のタイトルはAn empirical study of refactoring challenges and benefits at microsoftです。2014年に発表された論文です。著者はマイクロソフト所属です。

Kim, M., Zimmermann, T., & Nagappan, N. (2014). An empirical study of refactoring challenges and benefits at Microsoft. IEEE Transactions on Software Engineering, 40(7), 633-649.

論文本体は学会のサイト(定期購読か購入が必要)、著者らのサイト(無料で参照可)

リファクタリングに関してアンケート、インタビュー、コードの分析を実施しています。この順番に紹介します。

アンケート
開発者がリファクタリングをどのように定義しているか、そのメリットやリスクについてどう認識しているか、そしてどのような状況でリファクタリングを実施しているのかを把握するために実施しています。

• 方法
  22の選択式および自由記述式の質問からなる調査票を送付し、得られた回答のトピックやキーワードを抽出してタグ付けする分類分析を行いました。主要な項目は原典 Table 1にあります。を確認してください。

• 対象者
  過去2年間のチェックイン（コミット）コメントに「refactor*（リファクタなど）」というキーワードを含めていた、Microsoftのソフトウェアエンジニア1290名に呼びかけています。最終的な有効回答数は328名です。

• 結果
  開発者の78%がリファクタリングを「可読性や保守性を向上させるコード変換」と定義しています。76%の開発者が「潜在的なバグ（リグレッション）を混入させるリスクがある」と懸念しています。大半の開発者（平均86%）はIDEの自動化ツールを使わず手動でリファクタリングを行っており、その主な理由は変更後のマージやコードレビューが困難になるからというものでした。長期的な保守性よりも、直近のバグ修正や機能追加の必要性によりリファクタリングを行う傾向が強いことがわかりました。なお、46%は「振る舞いの維持」には言及していませんでした。

インタビュー
アンケートと開発者の認識が現実とどの程度一致しているかを確かめ、大規模な組織においてシステム全体のリファクタリングがどのようなプロセスやツールを用いて実施されたかを詳細に調査することが目的です。

• 方法
  対象者と1対1のインタビューを実施し、リファクタリングの動機、意図するメリット、プロセス、ツールなどの観点からテキストを分類し、研究チーム内で解釈をすり合わせました。

• 対象者
  数年がかりでWindowsのシステム全体にわたるリファクタリングを主導した、専任チームの主要メンバー6名（アーキテクト、開発マネージャー、チームリード、開発者、研究者）です。

• 結果
  リファクタリングの主な動機は、モジュールレベルの複雑な依存関係を減らし、並行開発の効率化やテストの最適化を行うことでした。専任チームは、まずシステムの依存関係を分析してアーキテクチャの階層モデルを定義しました。実際の作業はトップダウンで行われ、依存関係分析ツールや、アーキテクチャ制約に違反するコードのコミットを防ぐ「品質ゲート」を導入しました。また、他のチームが新しいAPIへ安全に移行できるよう、スタブコードを生成する独自のサポートツール等も開発して、他の開発メンバーにも使えるようにしました。

定量評価
アンケートやインタビューから導き出された仮説を設定し、リファクタリングによって「バグの削減」「依存関係の削減」「ソースコードの複雑度やサイズの縮小」といった目に見える効果が実際に生じているかを対象ソースコードやコミット履歴から定量的に評価することが目的です。

• 方法
  通常のコード変更とリファクタリングの効果を区別するため、各モジュールの「通常のコミット順位」と「リファクタリングのコミット順位」の差分から「優先的リファクタリングの度合い」という指標を定義しました。この度合いが高い「上位5%のモジュール」と「下位95%のモジュール」を比較し、統計手法を用いてソフトウェアメトリクスへの影響を測定しました。リファクタリングコミット自体の特定するために、専用ブランチの抽出とコミットログのキーワード検索が使われました。

• 対象データ
  Windows VistaからWindows 7へのバージョンアップの際の履歴を対象にしています。具体的には、モジュール間の依存関係数、リリース後のバグ数、ソースコードの複雑度、ソースコード行数、テストカバレッジ、コードの変更頻度（Churn）、関与した開発者数などのメトリクスデータが対象です。

• 結果
  専任チームの最大の目的通り、優先的にリファクタリングされた上位5%のモジュールでは、依存関係の数が平均の変動に比べて0.85倍に減少しました。バグの数も減少していましたが、これはリファクタリング単独の効果ではなく、通常の変更や元のバグの多さなど複合的な要因と判断されました。また、特定の複雑度指標の低下は見られたものの、直感に反してコードのサイズ（LOC）や複数ファイルにまたがる横断的な変更は増加していました。結論として、リファクタリングの影響は多次元的であり、単一の指標ではなく様々なソフトウェアメトリクスを用いた包括的な測定が必要であることが示されました。

また、リファクタリングはアーキテクチャの依存関係や一部の複雑度を効果的に改善しますが、コードサイズや変更の広がりといった面では増加を招く副作用もあるため、多角的な視点での効果測定が不可欠という点にも言及しています。