Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

ソフトウェアが真に完成することはありません。数十年にわたって有機的に成長する都市のように、コンピュータプログラムには、追加、パッチ、そして応急処置の層が積み重なっていきます。時間の経過とともに、この有機的な成長は、壁を補強せずに廊下を広げてしまった建物のように、構造的な弱体化を招くことがあります。ソフトウェア工学の世界では、こうした局所的な欠陥は「コードの臭い（コード・スメル）」と呼ばれます。これらはプログラムをクラッシュさせるエラーではなく、コードの理解、変更、または保守を困難にする設計の悪さを表すサインです。開発者がこれらの「臭い」を見つけると、多くの場合、「リファクタリング」を行います。これは、ソフトウェアが実際に行う動作を変えることなく、その構造を改善するためにコードを再編成する慎重なプロセスです。課題は、開発者が発見したすべての「臭い」を必ずしも修正するわけではないことであり、どの「臭い」が修正されるかを予測することは困難です。なぜなら、その決定は単なるコードそのものではなく、人間の意図や文脈に依存することが多いからです。

ミラノ・ビコッカ大学の研究チームは、機械がこうした人間の決定を学習できるかどうかを確かめるべく、調査を開始しました。彼らは、コンピュータがコードを見て、欠陥を特定し、開発者が最終的にそれをクリーンアップするかどうかを正確に推測できるのかを知りたいと考えました。これを行うために、彼らは2つの異なるコードの見方を組み合わせたシステムを構築しました。第一の方法は伝統的なもので、メソッドの長さや使用される変数の数といった特性をカウントすることです。第二の方法は、より現代的で複雑なものです。コードをその論理と挙動のマップへと変換し、そのマップをコンピュータが隠れたパターンを分析できる数学的な表現へと翻訳します。この組み合わせた情報を機械学習モデルに投入することで、研究者たちは、開発者がリファクタリングを選択する際に導きとなる微妙なルールを、コンピュータが学習できるかどうかをテストしました。

研究者たちは、79のオープンソースのJavaプロジェクトからデータを収集しました。これらは、長い年月をかけて多くの人々によって開発・維持されてきたソフトウェアの集合体です。彼らはこれらのプロジェクトの履歴を自動化ツールでスキャンし、コードの臭いが存在していた数千の事例を特定し、それらが変数の名前変更、メソッドの抽出による分割、あるいはパラメータの変更といった特定の型のリファクタリング操作を通じて、後にどのように修正されたかを追跡しました。そして、各コードに対してハイブリッドなデータセットを作成しました。このデータセットには、メソッド内の行数のような標準的な測定値に加え、2種類の異なる「エンベディング（埋め込み表現）」が含まれていました。一方のエンベディングは制御フローをマッピングし、命令が実行される順序を示します。もう一方は、より高度なタイプで、より深い意味的な関係性をマッピングし、データがプログラム内をどのように移動し、コードの各部分が互いにどのように依存しているかを捉え、コードの挙動に関する豊かで多次元的な肖像を効果的に作成するものです。

結果として、機械学習モデルは高い信頼性を持ってリファクタリングを予測できることが示されました。モデルを10種類の異なるリファクタリング操作に対してテストしたところ、AUCスコアは頻繁に0.70を大きく上回り、タスクによっては0.80を超えました。このことは、開発者のクリーンアップへの意図を示す、検出可能なパターンがコードの中に確かに存在することを示唆しています。しかし、研究は重要なニュアメント（微細な差異）を明らかにしました。すべてのコードの臭いが等しく扱われるわけではないということです。モデルは、メソッドへのパラメータの追加や変数の型の変更といった構造的な変更の予測には非常に優れていました。これらのアクションは、ステートメントの長さや計算の複雑さといった、明確で測定可能な要因によって駆動されることが多いものです。対照的に、モデルはメソッドの名前変更のような概念的な変更の予測には苦戦しました。名前変更は、開発者がコードの目的をどのように考えているかという主観的な決定に基づいていることが多く、数字や構造的なマップだけでは捉えることが難しい要素なのです。

おそらく最も重要な発見は、使用されたデータの表現形式に関するものでした。研究者たちは当初、コードの実行フローのより複雑なマップを追加するだけで予測が改善されると考えていました。しかし、実際には、ステートメントの順序を追跡する特定のフローマップが、モデルを混乱させるノイズを導入してしまうことが判明しました。このフローマップを伝統的な測定値と組み合わせると、コンピュータが無関係な詳細を無視できなくなるため、予測が悪化することがしばしばありました。しかし、研究者が構造的な依存関係と実際のテキストおよび論理を組み合わせた、より高度な表現に切り替えると、結果は劇的に変化しました。このより豊かな表現は、モデルが効果的に利用できる補完的な信号を提供しました。実際、いくつかのタスクにおいては、この高度な表現のみで学習されたモデルが、フルデータセットで学習されたモデルとほぼ同等の性能を発揮しており、コードの深い構造的かつ意味的な理解が、それ自体として強力な予測因子であることを証明しました。

この研究は、コードのみから予測できる限界についても浮き彫りにしました。モデルは、複雑さに起因する技術的な修正を確実に予測できますが、明快さのために名前を変更したり再編成したりするという人間の決定を容易に予見することはできませんでした。これは、機械はソフトウェアが技術的にメンテナンスの時期を迎えていることを特定することには長けているものの、リファクタリングを行う最終的な決定は、コードの外側に存在する開発者のビジョンや文脈に依存していることを示唆しています。研究の結論は、自動化されたソフトウェアメンテナンスの未来は、人間の判断を置き換えることではなく、これらの予測ツールを用いて、最も緊急性の高い構造的な負債を強調し、開発者が限られた時間を最も重要な変更に集中できるようにすることにあります。どの信号が強く、どの信号がノイズであるかを理解することで、私たちはデジタルインフラをより健全で持続可能なものにするための、より優れたツールを構築できるのです。