信学技報
TECHNICAL REPORT OF IEICE.

社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

リファクタリング実施履歴を用いた Code Smell の深刻度に関する調査
雜賀

翼†

崔

恩瀞††

吉田 則裕††† 春名 修介†

井上

克郎†

† 大阪大学 大学院情報科学研究科 〒 565-0871 大阪府吹田市山田丘 1 番 5 号†† 大阪大学 大学院国際公共政策研究科 〒 560-0043 大阪府豊中市待兼山町 1-31††† 名古屋大学 大学院情報科学研究科 〒 464-8601 名古屋市千種区不老町
E-mail: †{t-saika,haruna,inoue}@ist.osaka-u.ac.jp, ††ejchoi@osipp.osaka-u.ac.jp, †††yoshida@ertl.jp
あらましCode Smell とは，ソースコードの設計上の問題を示す指標であり，リファクタリングが推奨されている.

しかし,実際に開発者がリファクタリングするのはどのような Code Smell かは明らかにされていない. 本研究では,深刻度という問題の大きさの指標に着目して, Code Smell のメトリクスベースの深刻度とリファクタリングされる頻度の関係を調査した. 結果から, 長く複雑なソースコードを表す Code Smell である, Blob Class と Blob Operation について, 深刻度の高いクラス・メソッドほど頻繁にリファクタリングされることが分かった.
キーワード

リファクタリング, 不吉な匂い, ソフトウェア開発履歴, オブジェクト指向プログラミング，ソフトウェ

ア保守

An Empirical Study of the Severity of Code Smell Using a Refactoring
DatasetTsubasa SAIKA† , Eunjong CHOI†† , Norihiro YOSHIDA††† , Shusuke HARUNA† , and Katsuro
INOUE†† Graduate School of Information Science and Technology, Osaka University, Yamadaoka 1-5, Suita, Osaka
565-0871 Japan†† Osaka School of International Public Policy, Osaka University, Toyonaka, Osaka, 560-0043 Japan††† Graduate School of Information Science, Nagoya University, Furo-cho, Chikusa-ku, Nagoya, 464-8601,
Japan
E-mail: †{t-saika,haruna,inoue}@ist.osaka-u.ac.jp, ††ejchoi@osipp.osaka-u.ac.jp, †††yoshida@ertl.jp
Abstract Code smells are structures in the code that suggest the possibility of refactoring. To prioritize code
smells in large-scale source code, several tools for refactoring calculate the severity based on software metrics. Although several metrics are known as maintainability indicators, it is still unclear whether these severity indicators
are in line with developer’s perception. In this paper, we investigate whether developers focus on severe code smells.
The result shows that developers focus on only particular types of severe smells.
Key words Refactoring, Code Smell, Software development history, Object-oriented programming, Software maintenance

1. は じ め に

リファクタリングの実施には明確な基準は無く, 開発者はソースコードのどの部分にどの種類のリファクタリングを実施する

リファクタリングとは, ソフトウェアの外部から見た振る舞かを判断する必要がある. しかし, リファクタリングの実施にいを変えずに, 内部の構造を整理する作業のことである [1]. リ

かかるコストや, 保守性への効果を事前に予測することは難し

ファクタリングの主な目的は, ソースコードの可読性や保守性

く, リファクタリングの実施の判断は開発者の経験によるとこの向上である. また, リファクタリングを実施することで, 機能ろが大きい.

の追加や, バグの発見が容易になり, ソフトウェア開発の効率を向上させることができる [2].

この問題を解決するために, Fowler は, リファクタリングの実施の判断材料として Code Smell を提案した [1]. Code Smell—1—とは, ソースコードの設計上の問題を示す指標であり, Code

ついて, 深刻度の高いクラス・メソッドほど頻繁にリファクタ

Smell が存在するソースコードにはリファクタリングの実施がリングされることが分かった.

推奨されている. 例えば, God Class は責務の多すぎる巨大な•クラスレベルの Code Smell の Blob Class と, メソッド

クラスを表す Code Smell であり, 保守性を悪化させる要因とレベルの Code Smell の Blob Operation と Internal Duplica-

して知られている. この問題を解決するためには, 複数のクラtion について, リファクタリングによって深刻度が減少する傾スへ機能を分割するリファクタリングの実施が必要とされる.

向にあった.

現在, ソースコードから Code Smell を検出して開発者に提このことから, 開発者は特に Blob Class と Blob Operation

示することで, リファクタリングを実施するべきソースコードの深刻度の高いクラス・メソッドに対して深刻度を減少させるの特定を支援する Code Smell 検出ツールが数多く開発されてようにリファクタリングを実施していると考えられる.

いる (例: inFusion, PMD) [3]. しかし, 開発者がリファクタリ

以降, 2. では調査対象のデータセットと調査手順を説明する.

ングを実施する Code Smell の基準は明確にされていないため,

3. では調査結果と考察を述べる. そして, 4. では本研究に関連ツールが Code Smell を検出する基準と開発者がリファクタリする研究について述べる. 最後に, 5. では本研究のまとめと今ングを実施する基準が大きく異なると, ツールは開発者にとっ後の課題を述べる.

て有益なリファクタリング実施対象の候補を提示できない. この問題に対して, ツールが検出する Code Smell が, 開発者のリファクタリング実施対象になっているかを調べる必要がある.

2. 調 査 手 法
2. 1 調査対象のデータセット

この問題に関して, Bavota らは各種類の Code Smell がリ

本研究では Java で書かれた 3 つのオープンソースソフト

ファクタリングの実施に与える影響を明らかにするため, リウェア, Xerces-J, ArgoUML, Apache Ant, の合計 64 リリー

ファクタリングが Code Smell を含むクラスに実施される割合

スバージョンを調査対象とした. 本研究では, 各リリースバーと, リファクタリングによって Code Smell が完全に取り除か

ジョンのソースコードと, Bavota らの研究で検出されたリファ

れる割合を調査した [4]. その結果, 42%のリファクタリングはクタリングの一覧を調査対象とする [4]. データセットの概要を

Code Smell を含むクラスに対して実施されていた. しかし, リ

表 1 に示す.

ファクタリングの実施によって Code Smell が取り除かれたのBavota らは, Ref-Finder [5] というリファクタリング検出ツー

はそのうちわずか 7%であった. そのため彼らはリファクタリ

ルを用いて, リリースバージョン間のソースコードの変化からングの実施と Code Smell の間に明確な関係は見られなかった

リファクタリングを検出した. そして, Ref-Finder で検出されとしている.

たリファクタリングのうち, それが本当にリファクタリングでしかし, 彼らの研究では同種類の Code Smell の中で深刻度あるか確認出来たものを公開している. 本研究では彼らが正しの違いについて考慮されていなかった. Code Smell の深刻度とく検出されたと判断したリファクタリングのみを調査対象とす

は, Code Smell の示す問題の大きさを数値化したもので, Codeる. 検出されたリファクタリングの種類とそれぞれの検出数をSmell の検出に用いるメトリクス値を組み合わせて測定される.

表 2 に示す.

リファクタリングの実施にはコストがかかるため, Code Smell

2. 2 調 査 手 順を修正するコストと効果は, リファクタリングを実施するかの本研究では, Code Smell の深刻度がリファクタリングに与判断に影響すると推測できる. この推測が正しければ, 同種類

える影響を明らかにするため, リファクタリングされる Codeの Code Smell でも軽度なものと重度なものでは, リファクタ

Smell とリファクタリングされない Code Smell の間で, 深刻度

リングが実施されるかの傾向が異なると考えられる. そのため,について統計的な有意差があるかを調べる. 調査手順は図 1 に

Code Smell の深刻度について考慮して調査を行う必要がある.

示す通り, 4 つの手順から構成される. 手順 1 では, 調査対象のこのような問題に対して, 本研究では, Java で書かれた 3 つ各リリースバージョンについて, ソースコードから Code Smellのオープンソースソフトウェアのリファクタリング実施履歴をの検出を行なう. 手順 2 では, リリース間で Code Smell を比較

調査対象として, Code Smell 検出ツールが提示する深刻度といし, Code Smell の深刻度の増減を計測する. 手順 3 では, Codeう指標と, 開発中に実施されたリファクタリングの関係についSmell の検出されたクラスやメソッドに対してリファクタリン

て調査を分析した. Code Smell の深刻度がリファクタリング

グが実施されたかどうかでグループ分けを行なう. 手順 4 では,の推薦に有用であるかを調べるため, 本研究では以下のリサー

2 つのグループ間で RQ に対応した有意差検定を行なう. 以降,

チクエスチョン (RQ) を設定している:

手順 1 から手順 4 について順番に説明する.

RQ1 深刻度の高い Code Smell がよりリファクタリングされ（ 1 ） Code Smell の検出

るか？

調査対象の各リリースバージョンのソースコードから inFusion

RQ2 リファクタリングは Code Smell の深刻度を減少させを利用して Code Smell の検出した. そして, 検出した Code

るか？

Smell のうちクラス単位またはメソッド単位の Code Smell を,

調査の結果得られた, RQ への回答は以下の通りである:

検出元のクラス毎やメソッド毎に各種類の Code Smell の深刻•度をまとめた.

クラスレベルの Code Smell の Blob Class と, メソッド

レベルの Code SmellBlob Operation と Sibling Duplication に—2—

表 1 調査対象のデータセットの概要
プロジェクト

対象期間

対象リリース

リリース数

クラス数

リファクタリング数

リファクタリングの種類数

Xerces-J

2003 年 10 月-2006 年 11 月 1.0.0-2.9.0

34

19,567

6,052

43

ArgoUML

2002 年 10 月-2011 年 4 月

0.10.1-0.32.2 12

43,6863,423

43

Apache Ant

2003 年 8 月-2010 年 12 月

1.1-1.8.2

18

22,768

1,493

31

全体

-

-

64

86,021

10,96852

各リリースバージョンのソースコード

1. コードスメルの検出

inFusion
コードスメルの深刻度

2. コードスメルの深刻度の増減の計測

コードスメルの深刻度の増減

3. リファクタリングによるグループ分けリファクタリングの一覧

リファクタリングされなかった
コードスメル

リファクタリングされた
コードスメル

4. ２グループ間での有意差検定

RQ1: 深刻度の高さについて
RQ2: 深刻度の増減について
図 1 手順全体図

2. 3 Code Smell の検出方法（ 2 ） Code Smell の深刻度の増減の計測

本研究では inFusion という商用の Code Smell の検出ツー

RQ2 について, 連続するリリースバージョン間での Code Smell

ルを利用し, 調査対象の各リリースバージョンのソースコードの深刻度の増減を計測した. 連続するリリースバージョン間で,（注 1）. inFusion は Code Smell を同じクラスの同じメソッド, 同じ種類の Code Smell を比較し,

ソースコードのメトリクス値の特徴に基づいて抽出し, 24 種類

Code Smell の深刻度の増減を得た. Code Smell の深刻度の増の Code Smell を検出することが可能である. また, 検出された

減には, 増加または減少, 変化なしの 3 パターンがあり, 増加

Code Smell には深刻度という, 1 から 10 までの整数値が付けと減少については深刻度が変化した量も記録した. また, Codeられる.

Smell がない状態の深刻度は 0 とし, Code Smell が除去されたから Code Smell を検出した

inFusion を選択した理由は, 検出可能な Code Smell の種類

場合は深刻度の減少として扱う.

の豊富なことと, 厳密な検出規則が定められていて検出の適合（ 3 ） リファクタリングによるグループ分け

率の高いこと, そして深刻度によって Code Smell の重要さが有意差検定を行なうための準備として, Code Smell 検出された表現されることである. また, inFusion は実際に企業等のソフ

クラスおよびメソッドを, リファクタリングが実施された群とトウェア開発現場で利用された実績があり, Yamashita らの研

リファクタリングが実施されなかった群に分けた. 本研究では究でも利用されている [6].

Code Smell とは無関係に実施されたリファクタリングを除外

本研究では inFusion の検出できる Code Smell のうち, 表 3

するために, リファクタリングを Code Smell に対応するものに示す 9 種類の Code Smell を調査対象とする. 各種類の Codeに限定した. 本研究で扱う Code Smell を定義した Fowler [1]Smell の詳細な説明と検出規則は, inFusion のマニュアルに掲と Lanza [7] が, 各種類の Code Smell に対応するとしているリ

載されている.

ファクタリングの種類を表 5 に示す.

表 4 に調査対象の各システムについて Code Smell の検出数

（ 4 ） 2 グループ間での有意差検定

を種類毎に示す. 1 つのクラスまたはメソッドからは複数種類

リファクタリングが実施されたクラス群と, リファクタリングさの Code Smell が検出されることがあるため, Code Smell を含れなかったクラス群との間で, Code Smell の Code Smell の深むクラスの数と Code Smell を含まないクラスの数をそれぞれ刻度に有意差があるかどうかをマン・ホイットニーの U 検定で示す.

調べた. 検定のためのツールとしては, 統計分析ソフト R（注 2）を（注 1）：http://www.intooitus.com/products/infusion（注 2）：https://cran.r-project.org

—3—

表3

調査対象の Code Smell の種類の説明

Code Smell の種類

検出単位 説明Blob Classクラス

コードの量が多く複雑なクラス

Data Class

クラス

フィールドと getter, setter 以外の機能を持たないクラス

God Class

クラス

他のクラスと比べて責務の多過ぎるクラス

Tradition Breakerクラス

親クラスの提供する機能を打ち消してしまうサブクラス

Blob Operation

メソッド コードの量が多く複雑なメソッド

External Duplication メソッド 他のクラスの複数のメソッドと著しく重複するメソッド
Feature Envy

メソッド 所属するクラスとは違うクラスのデータを多く用いるメソッド

Internal Duplication

メソッド 同じクラスの複数の他のメソッドと著しく重複するメソッド

Sibling Duplication

メソッド 継承階層で兄弟関係にあるクラスに重複するコードがあるメソッド
表 4 検出された Code Smell の数

Code Smell の種類

Xerces-J ArgoUML Apache Ant

全体

Blob Class

665

83

87

835

Data Class

71

3

28

102

God Class

952

160

143

1,255

Tradition Breaker

99

3

0

102

Blob Operation

2,428

545

413

3,386

External Duplication

713

269

46

1,028

Feature Envy

723

110

220

1,053

Internal Duplication

701

160

85

946

Sibling Duplication

927

545

131

1,603

Code Smell があるクラス数

3,907

1,992

897

6,796

Code Smell がないクラス数

15,66041,69421871 79,225

総クラス数

19,567

43,686

22,768 86,021

用いた. RQ1 については, リファクタリングされるクラスまたはメソッドの方が各種類の Code Smell 深刻度が有意に高いかb ) RQ2：リファクタリングは Code Smell の深刻度を減少させるか？

を知るために, マン・ホイットニーの U 検定を片側検定で行RQ2 に対するマン・ホイットニーの U 検定の結果を表 7 になった. RQ2 については, リファクタリングされるクラスまた示す. チェックマークは有意差 (p < .05) を示している. n/a とはメソッドの方が各種類の Code Smell 深刻度が有意に減少す表記している部分は, その種類の Code Smell についてはリファるかを知るために, マン・ホイットニーの U 検定を片側検定でクタリングの実施前後で深刻度が変化しなかったことを示して行なった.

3. 調 査 結 果a ) RQ1：深刻度の高い Code Smell がよりリファクタリン
グされるか？

RQ1 に対するマン・ホイットニーの U 検定の結果を表 6 にいる. また, 有意差以外の指標として効果量 r を載せている. 効
果量はサンプルサイズによらない２グループの実施的な差を示すもので, 効果量 r の基準は r=0.1 なら効果量小, r=0.3 なら効
果量中, r=0.5 なら効果量大とされている. この検定結果では,有意差の出ている種類については全て効果量も小以上である.
結果から, クラスレベルの Code Smell の Blob Class と, メ示す. チェックマークは有意差 (p < .05) を示している. n/a とソッドレベルの Code Smell の Blob Operation と Internal Du-

表記している部分は, その種類の Code Smell が検出されなかっplication について, リファクタリングされた Code Smell の深た場合も含めて, その種類の Code Smell のあるクラスまたは刻度が減少する, またはリファクタリングされない場合と比べメソッドに対してリファクタリングが実行されなかったものでて増加の幅が小さい傾向にあることが分かった.

ある. また, 有意差以外の指標として効果量 r を載せている. 効

以降, 調査結果から, Code Smell 検出ツールが開発者に優先

果量はサンプルサイズによらない２グループの実施的な差を示的に提示するべき Code Smell についての考察を述べる. RQ1

すもので, 効果量 r の基準は r=0.1 なら効果量小, r=0.3 なら効と RQ2 の両方で有意差が出た Code Smell の種類は, クラス

果量中, r=0.5 なら効果量大とされている. この検定結果では,レベルの Code Smell の Blob Class とメソッドレベルの Code

有意差の出ている種類については全て効果量も小以上である.

Smell の Blob Operation である. このことから, 開発者は特に結果から, クラスレベルの Code Smell の Blob Class と, メ

Blob Class と Blob Operation の深刻度の高いクラス・メソッド

ソッドレベルの Code SmellBlob Operation と Sibling Dupli-に対して深刻度を減少させるようにリファクタリングを実施しcation について, 深刻度の高いクラスほどリファクタリングさていると考えられる. そのため, Blob Class と Blob Operation

れる頻度が高い傾向にあることが分かった.

の深刻度の高いクラス・メソッドを優先して提示するべきだと—4—

表 2 調査対象のリファクタリングの数
リファクタリングの種類
Add Parameter
Change Bidirectional Association To Undirectional
Change Undirectional Association To Bidirectional
Collapse Hierarchy
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Decompose Conditional
Encapsulate Field
Extract Hierarchy
Extract Interface
Extract Method
Extract Subclass
Extract Superclass
Form Template Method
Hide Delegate
Hide Method
Inline Class
Inline Method
Inline Temp
Introduce Assertion
Introduce Explaining Variable
Introduce Local Extension
Introduce Null Object
Introduce Parameter Object
Move Field
Move Method
Parameterize Method
Preserve Whole Object
Pull Up Constructor Body
Pull Up Field
Pull Up Method
Push Down Field
Push Down Method
Remove Assignment To Parameters
Remove Control Flag
Remove Middle Man
Remove Parameter
Rename Method
Replace Conditional With Polymorphism
Replace Constructor With Factory Method
Replace Data With Object
Replace Delegation With Inheritance
Replace Eerror Code With Exception
Replace Exception With Test
Replace Magic Number With Constant
Replace Method With Method Object
Replace Nested Conditional With Guard Clauses
Replace Parameter with Explicit Methods
Replace Parameter With Method
Replace Temp With Query
Self Encapsulate Field
Separate Query From Modifier
リファクタリングの総検出数

Xerces
665
3
6
3
171
422
0
0
3
78
166
6
2
0
1
0
1
74
86
0
165
25
35
16
920
747
2
3
0
6
11
52
44
73
136
0
496
714
6
5
32
1
1
38
516
170
124
3
0
0
7
17
6052

Argo
511
2
0
1
45
103
2
1
4
40
135
4
13
10
0
9
0
22
98
14
104
18
25
0
399
349
1
0
5
4
0
0
1
40
147
1
442
262
4
5
10
0
0
18
158
374
33
1
3
1
2
2
3423

表 5 Fowler または Lanza により Code Smell に対応付けられたリ
Ant
133
0
0
0
32
73
1
0
0
10
73
0
3
0
0
0
1
25
55
23
115
3
2
0
67
96
1
0
1
2
4
0
0
49
26
0
114
182
0
1
6
0
0
18
327
36
13
0
0
0
0
1
1493

全体
1309
5
6
4
248
598
3
1
7
128
374
10
18
10
1
9
2
121
239
37
384
46
62
16
1386
1192
4
3
6
12
15
52
45
162
309
1
1052
1158
10
11
48
1
1
74
1001
580
170
4
3
1
9
20
10968

ファクタリングの種類
Code Smell の種類
Blob Class

Data ClassGod Class

Tradition Breaker

Blob Operation

External Duplication

Feature Envy

Internal Duplication

Sibling Duplication

対応するリファクタリングの種類
Extract Interface
Extract Subclass
Extract Class
Replace Data Value with Object
Move Method
Encapsulate Field
Encapsulate Collection
Extract Interface
Extract Subclass
Extract Class
Replace Data Value with Object
Extract Class
Pull Up Method
Pull Up Field
Extract Method
Replace Method with Method Object
Replace Temp with Query
Decompose Conditional
Extract Method
Extract Class
Pull Up Method
Form Template Method
Extract Method
Move Method
Pull Up Method
Move Field
Extract Method
Extract Class
Pull Up Method
Form Template Method
Extract Method
Extract Class
Pull Up Method
Form Template Method

表 6 リファクタリングを Code Smell に対応する種類に限定した場合における, RQ1 に対するマン・ホイットニーの U 検定結果

Code Smell の種類
Blob Class

有意差

効果量 r

✓

0.158

Data Class

0.020

God Class

0.021

Tradition Breaker

0.025
✓

Blob Operation

0.075

Feature Envy

0.004

Internal Duplication

考えられる.

4. 関 連 研 究

0.049

External Duplication

Sibling Duplication

0.053
✓

0.050

効果量 r の基準：r=0.1(効果量小), r=0.3(効果量中), r=0.5(効果量大)Code Smell がリファクタリングに与える影響についての既存研究の 1 つとして, Bavota らはリファクタリングが Code

い内容で, リファクタリングとソフトウェア品質メトリクスのSmell のあるクラスに実施される割合と, リファクタリングに関係について研究が行なわれている [8]〜[11]. 本研究で調査しよって Code Smell が完全に取り除かれる割合を調査した [4].

た Code Smell の検出規則にはメトリクス値の条件に含まれて彼らは Code Smell の種類毎にリファクタリングに与える影響いるため, Code Smell の深刻度がリファクタリングに影響するを分析し, リファクタリングと Code Smell の間に明確な関係

ように, メトリクス値の大小がリファクタリングに影響するこは見られなかったとしているが, Code Smell の深刻度についてとが予想できる.

は考慮されていなかった. Code Smell の修正にもコストがか

Szoke らの研究によると, 単一のリファクタリングは Code

かるので, 深刻でない Code Smell は修正されずに放置される

Smell などの保守性の問題をあまり改善しないが, 複数のリファやすいと推測できる. また, 深刻度の低い Code Smell が問題視

クタリングを連続して実施することで保守性が大きく向上する

されにくいとすると, 開発者は Code Smell を完全に取り除くことができる [10]. また, 雜賀らの研究によると一度に複数種類のではなく, 深刻度を和らげることを目標にして修正を行なうのリファクタリングが組み合わせて実施される [12]. そのため,と考えられる. そのため, 本研究では Code Smell の深刻度につCode Smell の存在するクラスに対してどのようなリファクタ

いて考慮して調査を行なった.

リングが実施されるかを調査する場合には, 単一のリファクタ

リファクタリングと Code Smell の関係についての研究と近リングではなくリファクタリングの組み合わせで調査するべき—5—

表 7 リファクタリングを Code Smell に対応する種類に限定した場合における, RQ2 に対するマン・ホイットニーの U 検定結果

Code Smell の種類

有意差 効果量 r

Blob Class✓

Data Classn/a

God Class

0.162
0.059

Tradition Breakern/aBlob Operation

✓

0.189

External Duplication

0.052

Feature Envy

0.110

Internal Duplication✓

Sibling Duplication

0.204
0.071

効果量 r の基準：r=0.1(効果量小), r=0.3(効果量中), r=0.5(効果
量大)だと考えられる.

Yamashita らの研究によると, 複数種類の Code Smell が集中することは, 保守性を低下させたりバグの要因となるとされている [13]. 本研究では各種類の Code Smell の深刻度とその中の最大値について個別に調査したが, 複数種類の Code Smellの集中がリファクタリングにどのように影響するかは, 今後の研究課題である.

Tufano らの研究によると, あるクラスに Code Smell の発生するタイミングは, そのクラスが作成されたときの場合がほとんどである [14]. また, Kim らの研究によると, リファクタリン
グはリリースの直前に集中して実施される [15]. したがって, リ
リースバージョンのソースコードから Code Smell を検出した
場合には, リリース間で発生した Code Smell の多くを見落としている可能性がある. 本研究ではリファクタリング検出の制限からリリースバージョン間に限定した調査を行なったが, 任意のリビジョンで調査可能なデータセットやリファクタリング
検出ツールを探して調査する必要がある.

5. まとめと今後の課題
本研究では, 優先順位付きで開発者に Code Smell を提示するツールの開発のために, Code Smell の深刻度と開発者の実施するリファクタリングの関係を明らかにすることを目的として,3 つの Java のオープンソースソフトウェアの合計 64 リリース
バージョンを対象に調査を行なった.
調査の結果, クラスレベルの Code Smell の Blob Class と,文

献[1] M. Fowler, Refactoring: Improving the Design of Existing
Code, Addison Wesley, 1999.
[2] G. Bavota, B.D. Carluccio, A.D. Lucia, M.D. Penta, R.
Oliveto, and O. Strollo, “When does a refactoring induce
bugs? an empirical study,” Proc. of SCAM, pp.104–113,
2012.
[3] F.A. Fontana, P. Braione, and M. Zanoni, “Automatic detection of bad smells in code: An experimental assessment.,”
Journal of Object Technology, vol.11, no.2, pp.1–38, 2012.
[4] G. Bavota, A.D. Lucia, M.D. Penta, and R. Oliveto, “An experimental investigation on the innate relationship between
quality and refactoring,” Journal of Systems and Software,vol.107, pp.1–14, 2015.
[5] M. Kim, M. Gee, A. Loh, and N. Rachatasumrit, “RefFinder: a refactoring reconstruction tool based on logic
query templates,” Proc. of FSE, pp.371–372, 2010.
[6] A. Yamashita, M. Zanoni, F.A. Fontana, and B. Walter,“Inter-smell relations in industrial and open source systems:
A replication and comparative analysis,” Proc. of ICSME,
pp.121–130, 2015.
[7] M. Lanza and R. Marinescu, Object-Oriented Metrics inPractice, Springer-Verlag, 2006.
[8] K. Stroggylos and D. Spinellis, “Refactoring–does it improve software quality?,” Proc. of WoSQ, pp.1–6, 2007.
[9] G. Szoke, G. Antal, C. Nagy, R. Ferenc, and T. Gyimothy,“An empirical assessment of refactoring impact on software
quality using a hierarchical quality model,” International
Journal of Software Engineering and Its Applications, vol.5,
no.4, pp.127–150, 2011.
[10] G. Szoke, G. Antal, C. Nagy, R. Ferenc, and T. Gyimothy,“Bulk fixing coding issues and its eﬀects on software quality: Is it worth refactoring?,” Proc. of SCAM, pp.95–104,
2014.
[11] S.H. Kannangara and W.M.J.I. Wijayanake, “An empiricalevaluation of impact of refactoring on internal and externalmeasures of code quality,” International Journal of Software Engineering and Its Applications, vol.6, no.1, pp.51–
67, 2015.
[12] T. Saika, E. Choi, N. Yoshida, A. Goto, S. Haruna, andK. Inoue, “What kinds of refactorings are co-occurred? ananalysis of eclipse usage datasets,” Proc. of IWESEP, pp.31–
36, 2014.
[13] A. Yamashita and L. Moonenl, “Exploring the impact ofinter-smell relations on software maintainability: An empirical study,” Proc. of ICSE, pp.682–691, 2013.
[14] M. Tufano, F. Palomba, G. Bavota, and R. Oliveto, “Whenand why your code smell starts to smell bad,” Proc. of ICSE,
pp.403–414, 2015.
[15] M. Kim, D. Cai, and S. Kim, “An empirical investigation
into the role of api-level refactorings during software evolution,” Proc. of ICSE, pp.151–160, 2011.

メソッドレベルの Code Smell の Blob Operation について, 深刻度の高いクラスやメソッドほどリファクタリングされる頻度が有意に高く, リファクタリングによって Code Smell の深刻度が減少する傾向が見られた. よって, Blob Class と Blob

Operation の深刻度の高いクラス・メソッドを優先して提示するべきだと考えられる.
今後の課題としては, 調査対象のシステムを更にを増やして調査結果の信憑性を向上し, 調査結果に基づいた優先順位を付
けて Code Smell を提示するツールを開発する必要がある.
謝辞

本 研 究 は JSPS 科 研 費 25220003，26730036,

15H06344 の助成を受けたものです．

—6—