コードスメルの深刻度がリファクタリング の実施に与える影響の実証的研究 井上研究室 雜賀 翼 1 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University リファクタリング • ソフトウェアの外部から見た動作を変えずに, ソースコードを整理する作業[1] – クラスやメソッドなどのプログラム要素が対象 外部から見た動作は同じ リファクタリング 理解しにくい ソースコード 理解しやすい ソースコード 開発者 機能の追加, バグの修正 がしやすい [1] M. Fowler. Refactoring:Improving the Design of Existing Code. Addison Wesley，1999. Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 2 コードスメル • 設計上の問題を持ち, 保守性を悪化させてバグ の原因になりやすいクラスやメソッドの特徴 • 開発者がリファクタリングを実施するべきソース コードの指標として提案された[1] コードスメルの例 コードスメル 説明 推奨されるリファクタリング Blob Class コードが長く複雑なクラス クラスの抽出など Blob Operation コードが長く複雑なメソッド メソッドの抽出など [1] M. Fowler. Refactoring:Improving the Design of Existing Code. Addison Wesley，1999. Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 3 コードスメルの例 • Blob Classを含むクラスについて, 推奨され るクラス抽出リファクタリングを実施する例 クラスC クラスC 長さ クラスB 新クラス クラスB クラス抽出 クラスA クラスを新しく作成し, フィールドとメソッドを移動 クラスA Blob Class コードの行数が大きく, 複雑で理解しにくい 機能を他のクラスに分割することで, コードの理解がしやすくなる 4 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University コードスメル検出ツール • リファクタリングを実施するべきソースコードの箇所 を特定することを目的として利用される • コードスメルを自動検出し開発者に提示する • 多くのツールは主にメトリクスを用いて検出する 例） Blob Classの検出手法[2] LOC(行数)が非常に高い WMC(複雑度)が非常に高い AND Blob Class TCC(凝集度)が低い 2つ以上のBlob operationを含む 高い低いの基準はツールにより異なる [2] M. Lanza and R. Marinescu. Object-Oriented Metrics in Practice. Springer, 2006. Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 5 コードスメルの深刻度 • 数値化されたコードスメルの示す問題の大きさ – 同じBlob Classでも500行と1000行とでは, 開発者のリファクタリ ング実施に差があると推測される • 各種類のコードスメルについて, 検出に用いるメトリクス値 を組み合わせて深刻度は1～10の10段階で測定される – 深刻度1が最も軽微で, 深刻度10が最悪 – 深刻度はメトリクスに求められるWeyukerの性質[3]をCKメトリク スと同様に満足する[4] • メトリクス値の大きさからリファクタリング実施対象のソー スコードを特定することが行なわれている[5] [3] E. J. Weyuker. Evaluating software complexity measures. IEEE Tans Softw Eng., 1988. [4] S.R. Chidamber et al. A Metrics Suite for Object Oriented Design”, IEEE Trans Softw Eng., 1994. [5] F. Simon et al. Metrics based refactoring. In Proc of CSMR, 2001 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 6 研究動機 • 開発者がリファクタリング実施するコードスメルの 基準は明確にされていない • 検出ツールと開発者でコードスメルの基準が大き く異なると, 有用なコードスメルを提示できない • ツールが検出するコードスメルが, 開発者のリファ クタリング実施対象になるか調べる必要がある 7 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Bavotaらの研究[6] • リファクタリングがコードスメルのあるクラスを対 象に実施されるかを調査 – ３つのオープンソースソフトウェア(OSS)の開発履歴 を用いて調査 • リファクタリングとコードスメルの間に明確な関係 は見られなかった – リファクタリングがコードスメルのあるクラスに実施さ れた割合は42% – リファクタリングがコードスメルを除去した割合は7% [6] G. Bavota et al. An Experimental investigation on the Innate Relationship between Quality and Refactoring. Journal of Systems and Software, 2015. Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 8 既存研究の問題点 • 同種類のコードスメルの中での深刻度の違いにつ いて考慮されていない • リファクタリングの実施にはコストがかかるので, 全 てのコードスメルを除去することは困難である – 同種類のコードスメルでも, 深刻度の高いものが優先し てリファクタリングされやすいと推測される – コードスメルを完全に除去せず, 深刻度を和らげる程度 にしかリファクタリングしない可能性もある 9 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 調査概要 • コードスメルの深刻度とリファクタリング実施の関 係について, 3つのOSSの開発履歴を調査 • リサーチクエスチョン(RQ) – RQ1 深刻度の高いコードスメルを含むクラス・メソッドがよりリファ クタリングされるか？ – RQ2 リファクタリングはコードスメルの深刻度を減少させるか？ 10 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 調査対象のシステム • 調査対象はJavaで書かれた３つのＯＳＳ – Bavotaらの研究[6]と同じシステム – 彼らが検出したリファクタリングの一覧も利用, 検出 結果は目視で正解か確認されたので信頼できる 各システムの概要 システム データの収集期間 リリースの数 リリース毎の リファクタリング クラス数 の総数 Xerces-J 1999年11月～2010年11月 34 181～776 6052 ArgoUML 2002年10月～2011年12月 12 777～1,519 3423 Apache Ant 2000年1月～2010年12月 18 87～1,191 1493 [6] G. Bavota et al. “An Experimental investigation on the Innate Relationship between Quality and Refactoring.” Journal of Systems and Software, 2015. Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 11 調査手順 各リリースバージョン のソースコード 1. コードスメルの検出 inFusion コードスメルの深刻度 2. コードスメルの 深刻度の増減の計測 コードスメルの深刻度の増減 3. リファクタリングによる グループ分け リファクタリングの一覧 リファクタリングされた コードスメルのあるクラス 4. ２グループ間での有意差検定 リファクタリングされなかった コードスメルのあるクラス RQ1: 深刻度の高さについて RQ2: 深刻度の増減について Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 12 コードスメルの検出 • メトリクスの値の特徴に基づいてコードスメルを 自動検出するツールInFusion*1を利用した – コードスメルの深刻度を1～10の数値で評価する • 深刻度1が最も軽微で, 深刻度10が最悪である 例）Blob Classの検出 1. メトリクスを計測 LOC(行数) クラスA WMC(複雑度) inFusion 2. 種類の判定 3. 深刻度の判定 Blob Classの メトリクス値の特徴 と一致すると判定 メトリクス値から 深刻度を判定 TCC(凝集度) 検出ツールの出力結果 *1http://www.intooitus.com/products/infusion クラス 種類 深刻度 クラスA Blob Class 4 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 13 調査手順 各リリースバージョン のソースコード 1. コードスメルの検出 inFusion コードスメルの深刻度 2. コードスメルの 深刻度の増減の計測 コードスメルの深刻度の増減 3. リファクタリングによる グループ分け リファクタリングの一覧 リファクタリングされた コードスメルのあるクラス 4. ２グループ間での有意差検定 リファクタリングされなかった コードスメルのあるクラス RQ1: 深刻度の高さについて RQ2: 深刻度の増減について Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 14 コードスメルの深刻度の増減の計測 • 連続するリリースバージョン間で各コードスメルの 深刻度を比較し, 深刻度の増減を計測する リリース1のコードスメル リリース2のコードスメル クラスAのコードスメル クラスAのコードスメル クラスレベル クラスレベル 種類 深刻度 種類 深刻度 Blob Class 4 Blob Class 4 メソッドレベル 変化なし 0 メソッドレベル 増加 メソッド 種類 深刻度 メソッド 種類 深刻度 m1() Blob Operation 5 m1() Blob Operation 6 m2() Blob Operation 1 m2() - 0 コードスメルがなければ深刻度0とする Department of Computer Science, Graduate School of Information Science and Technology, Osaka University +1 減少 -1 15 調査手順 各リリースバージョン のソースコード 1. コードスメルの検出 inFusion コードスメルの深刻度 2. コードスメルの 深刻度の増減の計測 コードスメルの深刻度の増減 3. リファクタリングによる グループ分け リファクタリングの一覧 リファクタリングされた コードスメル 4. ２グループ間での有意差検定 リファクタリングされなかった コードスメル RQ1: 深刻度の高さについて RQ2: 深刻度の増減について Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 16 調査手順 各リリースバージョン のソースコード 1. コードスメルの検出 inFusion コードスメルの深刻度 2. コードスメルの 深刻度の増減の計測 コードスメルの深刻度の増減 3. リファクタリングによる グループ分け リファクタリングの一覧 リファクタリングされた コードスメル 4. ２グループ間での有意差検定 リファクタリングされなかった コードスメル RQ1: 深刻度の高さについて RQ2: 深刻度の増減について Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 17 ＲＱ１のための有意差検定 RQ1： 深刻度の高いコードスメルを含むクラス・メソッドがよりリファ クタリングされるか？ リファクタリングされたクラス・メソッドは, そうでない ものに比べて, 深刻度が有意に高いかを調べた – マン・ホイットニーのU検定という, ノンパラメトリック な有意差検定の一つを用いて片側検定を行なった リファクタリングされたBlob Class リリース クラス リファクタリングされなかったBlob Class 深刻度 1 クラスA 4 1 クラスD 10 2 クラスA 4 リリース クラス 同じ種類のコードスメル 1 クラスB 4 1 クラスC 2 2 クラスB 8 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University … … 深刻度の大きさの 順位を比較する 深刻度 18 RQ1の回答 コードスメルの種類 RQ1 Blob Class Data Class God Class Tradition Breaker Blob Operation External Duplication Feature Envy Internal Duplication Sibling Duplication ○ ○ ○ ○：有意差あり(p<0.05), 空欄：有意差なし, n/a：検定不可 19 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University ＲＱ２のための有意差検定 RQ2： リファクタリングはコードスメルの深刻度を減少させるか？ リファクタリングされたクラス・メソッドは, そうでないも のに比べて, 深刻度の増減が有意に低いか調べた – RQ1と同様にマン・ホイットニーのU検定を用いた リファクタリングされたBlob Class リリース クラス 深刻度 の増減 1→2 クラスA 0 1→2 クラスD -4 2→3 クラスA -2 リファクタリングされなかったBlob Class リリース クラス 同じ種類のコードスメル 深刻度の増減の 順位を比較する 深刻度 の増減 1→2 クラスB 4 1→2 クラスC -1 2→3 クラスB 1 … … Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 20 ＲＱ２の回答 コードスメルの種類 RQ2 Blob Class Data Class God Class Tradition Breaker Blob Operation External Duplication Feature Envy Internal Duplication Sibling Duplication ○ n/a n/a ○ ○ ○：有意差あり(p<0.05), 空欄：有意差なし, n/a：検定不可 21 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 検定結果についての考察 • RQ1とRQ2で共通して有意差があるコードスメ ルはBlob ClassとBlob Operation – それぞれ深刻度の高いクラス・メソッドが優先してリ ファクタリングされ, 深刻度が減少する傾向にある • 他の種類のコードスメルでは, 深刻度はリファク タリングの実施の指標として有用ではない Blob ClassとBlob Operationについては, 深刻度の高い コードスメルを開発者に優先的に提示することが有用である 22 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University まとめと今後の課題 • まとめ – コードスメルの深刻度とリファクタリングの関係につ いて3つのOSSを調査した – Blob ClassとBlob Operationについては, 深刻度が 高いほどリファクタリングされやすい傾向があった • 今後の課題 – 調査対象のシステムを増やす 23 Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
© Copyright 2024 ExpyDoc
