MORCoRA: Multi-Objective Refactoring Recommendation Considering Review Availability

本論文は、コード品質の向上とレビュー担当者の専門性及び業務負荷を考慮したリファクタリング提案を行うための多目的探索手法「MORCoRA」を提案し、その有効性を複数のオープンソースリポジトリを用いて実証したものである。

要約

この論文は、**「MORCoRA」**という新しいソフトウェア開発の支援ツールについて書かれています。

これを一言で言うと、**「コードを綺麗にする提案を、誰がレビュー（チェック）できるかまで考えてくれる賢いアシスタント」**です。

難しい専門用語を使わず、日常の例え話を使って説明しますね。

---

🍳 料理の例え話：「美味しい料理」と「作る人」

Imagine you are running a busy restaurant (a software project).

1. 現状の問題点：
   以前は、シェフ（開発者）が「この料理を美味しくするレシピ（リファクタリング）」を見つけると、すぐに「さあ、作ろう！」と提案していました。
   しかし、実際にそのレシピを実行するには、**「味見をする人（レビュアー）」**が必要です。

   • 失敗例： 美味しいレシピが見つかったのに、味見をする人が「今、他の料理で手一杯！」だったり、「この料理の知識が浅い」だったりすると、そのレシピはそのまま棚上げされ、結局料理は改善されません。

2. MORCoRA の登場：
   MORCoRA は、ただ「美味しいレシピ（コード品質向上）」を見つけるだけでなく、**「今、味見をする時間と知識がある人」**まで一緒に探してくれる天才アシスタントです。

---

🧩 MORCoRA が考える「3 つの条件」

MORCoRA は、良い提案をするために、以下の 3 つのバランスを完璧に取ろうとします。

1. 料理を美味しくする（コード品質の向上）

• 意味： コードを整理して、バグが起きにくく、扱いやすくすること。
• 例え： 「このスパイスを加えれば、味が格段に良くなる！」という提案です。

2. 味が壊れないようにする（意味の保持）

• 意味： 料理の形を変えても、お客様が注文した味が変わってはいけません。
• 例え： 「ソースの入れ替えは OK。でも、メインの肉を野菜に変えちゃダメだよ！」というルールです。コードの動きが変わらないように注意します。

3. 味見できる人がいるか（レビューの可用性） ← これが今回の新発見！

• 意味： そのレシピを実行する前に、チェックしてくれる人が「知識があり、かつ暇な状態」でいるか確認します。
• 例え：
  • ❌ ダメな例： 知識があるベテランシェフ A さんが、今「10 個の注文を同時に処理中で、手が離せない」状態。
  • ✅ 良い例： 知識がある B さんが、今「少し休憩中で、余裕がある」状態。
  • MORCoRA は、「A さんには頼むな、B さんに頼め！」と提案します。

---

🔍 どうやって見つけるの？（魔法の検索エンジン）

MORCoRA は、**「進化的アルゴリズム」**という、生物の進化（自然淘汰）を模倣した仕組みを使います。

1. 大量の候補を作る： 「料理を良くするレシピ」を何千通りもランダムに作ります。
2. 選別する：
   • 「美味しいか？」
   • 「味が壊れていないか？」
   • 「今、味見できる人がいるか？」
     この 3 つの条件に合うものだけを生き残らせます。
3. 進化させる： 生き残った良いレシピ同士を掛け合わせたり、少し変えたりして、さらに良い組み合わせを探し出します。

最終的に、**「品質も良く、意味も正しく、かつすぐにレビューできる人が見つかる」**という「最高にバランスの取れた提案」をリストアップして開発者に渡します。

---

📊 実験の結果：どれくらいすごい？

研究者たちは、有名なオープンソースのプロジェクト（GitHub 上の 6 つの大きな倉庫）で実験を行いました。

• 結果： 従来のツールは「美味しいレシピ」は見つけましたが、「レビューできる人がいない」提案も多々ありました。
• MORCoRA の成果：
  • 従来のツールに比べ、「レビュー可能な提案」が約 4.3 倍も増えました！
  • 品質が少し落ちるかもしれませんが、「レビューできる人がいない」からといって提案がゴミ箱行きになるのを防ぎました。
  • 具体的には、「忙しすぎてレビューできない人」に頼む提案を避け、「余裕がある専門家」に頼む提案を優先しました。

---

💡 結論：なぜこれが重要なの？

ソフトウェア開発では、「コードを綺麗にしたい」という意欲があっても、**「レビューする人がいない（忙しすぎる）」**という現実的な壁にぶつかって、改善が止まってしまうことがよくあります。

MORCoRA は、「理想（コードを良くする）」と「現実（人のリソース）」のバランスを取ることを教えてくれました。

要約：
「美味しい料理（良いコード）」を作りたいなら、**「味見してくれる人が今、空いているか」**まで考えて提案しないと、結局その料理は完成しません。MORCoRA はその「現実的なチェック」までしてくれる、頼れるパートナーなのです。

技術概要

MORCoRA: 査読の可否を考慮した多目的リファクタリング推奨手法

技術的サマリー（日本語）

本論文は、検索ベースのリファクタリングにおいて、コード品質の向上だけでなく、**「推奨されたリファクタリングを迅速かつ適切にレビューできる開発者の存在（Review Availability）」**を考慮した新しい手法 MORCoRA を提案しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

---

1. 背景と問題定義

• 現状の課題: 検索ベースのリファクタリング手法は、コード品質の向上やコードスメールの除去を目的として推奨序列を生成しますが、実際の開発現場では、推奨された変更がマージされる前にコードレビューを経る必要があります。
• レビューのボトルネック:
  1. 専門性の欠如: 推薦されたリファクタリング対象のコードに精通していないレビュアーが選定されると、レビューが遅延したり、拒否されたりする。
  2. 過重労働: すでに多忙な開発者がレビュアーに選定されると、レビューが先送りされたり、無視されたりする。
• 具体的な事例: 論文では、オープンソースプロジェクト「Mockito」のプルリクエストを例に挙げ、レビュアーの過重労働によりリファクタリングのレビューが延期され、結果としてコード品質の改善が実現しなかったケースを示しています。
• 解決すべき課題: 検索アルゴリズムは、単に「品質向上」や「意味的整合性」だけでなく、**「適切な専門知識を持ち、かつ現在の負荷が低いレビュアーが存在する」**という条件を満たすリファクタリング序列を推薦する必要があります。

2. 提案手法：MORCoRA

MORCoRA は、NSGA-II（非支配ソート遺伝的アルゴリズム第 2 版）を用いた多目的探索ベースの手法です。以下の 3 つの目的関数を同時に最適化します。

1. コード品質の向上 (Improving Code Quality):
   • QMOOD モデル（再利用性、柔軟性、理解性など）に基づき、リファクタリング前後の設計メトリクスの変化を評価し、品質向上度（Qual）を最大化します。
2. 意味的整合性の維持 (Preserving Semantic Coherence):
   • リファクタリング（例：メソッド移動）を行う際、移動元のクラスと移動先のクラスが意味的に類似していることを保証します。
   • 語彙ベースの類似度（VS）と依存関係ベースの類似度（DS）を組み合わせ、整合性スコア（Sem）を最大化します。
3. 高いレビュー可用性の確保 (Possessing High Review Availability):
   • これが本論文の核心です。リファクタリング対象ファイルに対して、以下の条件を満たすレビュアーが存在するかどうかを評価します。
     • 専門性 (Expertise): ファイルへのコミット頻度と「最近性（Recency）」に基づいて算出。
     • 負荷 (Workload): 現在進行中のプルリクエストやイシューの参加数に基づいて算出。
   • これらを統合した指標 Review Availability (RA) を最大化します。

技術的詳細:

• 静的解析: JxPlatform2 を使用し、抽象表現（クラス構造）と呼び出しグラフを抽出。
• 専門性評価: 単なるコミット数だけでなく、最近のコミットに重み付けを行うことで、開発者の現在の知識レベルを正確に推定します。
• 負荷評価: 特定の期間（7 日）内の PR/Issue 参加数で開発者の忙しさを判定し、負荷が高い開発者をレビュアー候補から除外します。
• 探索アルゴリズム: NSGA-II を採用し、パレート最適解（3 つの目的のトレードオフを考慮した解の集合）を生成します。

3. 主要な貢献

1. MORCoRA の提案: レビュー可用性を考慮した多目的リファクタリング推奨手法の提案。
2. レビュー可用性メトリクスの設計: 専門性と負荷を定量化し、リファクタリングの実行可能性を評価する新しい指標の設計。
3. 実証評価: 6 つのオープンソース Java リポジトリ（Auto, Lottie-android, Mockito など）を用いた大規模な評価。
4. アルゴリズム比較: 5 つの探索アルゴリズム（NSGA-II, SPEA2, MOCell, IBEA, Random Search）を比較し、NSGA-II が最も優れていることを実証。
5. 既存手法との比較: レビュー可用性を考慮しない既存手法（Ouni et al. [5]）と比較し、MORCoRA の優位性を示しました。

4. 評価結果

• 定量的分析:
  • レビュー可能性の劇的向上: 既存手法（RA-）と比較して、MORCoRA（RA+）はレビュー可能な解の比率を平均 3.27 倍（リポジトリによっては 5 倍以上）向上させました。
  • トレードオフの許容: レビュー可能性を重視した結果、コード品質（Qual）と意味的整合性（Sem）のスコアは既存手法より若干低下しましたが（それぞれ約 25%、33% 低下）、レビュー可能性（RA）は 433.8% 向上しました。これは「実行不可能な高品質なリファクタリング」ではなく、「実行可能な実用的なリファクタリング」を提供できることを意味します。
  • アルゴリズム性能: NSGA-II が全体的に最も優れた性能を示し、SPEA2 がそれに次ぎました。ランダムサーチや IBEA は性能が劣りました。
• 定性的分析:
  • 人間による評価（60 件のランダム抽出）において、58.3% の解が「意味があり、レビュー可能で、かつコードスメールを除去する」ものでした。
  • 既存手法は専門性がなく過重労働のレビュアーしかいないリファクタリングを推奨するケースがありましたが、MORCoRA はそのような「実行不可能な提案」を回避し、適切なレビュアー（専門性が高く、余裕がある開発者）を伴うリファクタリングを推薦することが確認されました。

5. 意義と結論

• 実用性の向上: 検索ベースのリファクタリングツールを現実の開発現場に導入する際、単なるコードの「良さ」だけでなく、**「誰が、いつ、レビューできるか」**という人的リソースの制約を考慮することが不可欠であることを示しました。
• 開発プロセスへの統合: MORCoRA は、CI（継続的インテグレーション）環境などでリファクタリングを提案する際、レビューの遅延や拒否リスクを事前に低減し、ソフトウェア品質の改善サイクルを加速させる可能性があります。
• 今後の展望: 開発者の複数プロジェクトへの関与や非プログラミング業務の負荷を考慮すること、および実際の開発者による人間評価（ヒューマンスタディ）の実施が今後の課題として挙げられています。

結論:
MORCoRA は、コード品質の向上とレビューの実現可能性の両立を図ることで、検索ベースのリファクタリングの現実適用性を大幅に高める有効な手法です。開発者はリファクタリングを推奨する際、品質改善効果だけでなく、レビューに必要な開発者リソースも同時に考慮すべきであるという提言がなされています。