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

信学技報
TECHNICAL REPORT OF IEICE.

組み合わせて実施されたリファクタリングの調査
雜賀翼†

崔恩瀞†

後藤祥†

吉田 則裕††

井上克郎†† 大阪大学 大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1 番 5 号†† 名古屋大学 大学院情報科学研究科〒 464-8601 名古屋市千種区不老町
E-mail: †{t-saika,ejchoi,a-gotoh,inoue}@ist.osaka-u.ac.jp, ††yoshida@ertl.jp
あらまし

リファクタリングを支援するツールが研究されているが，組み合わせて実施されるリファクタリングについてはあまり研究されておらず, 既存ツールでは複数のリファクタリングをまとめて実施することができない. ソフト
ウェア開発履歴中のリファクタリングを対象に, 90 秒以内に連続して実施されたリファクタリングの組み合わせを調査した結果, ３つのパターン (Move, Rename),(Rename, Rename),(Extract, Move) の実施される頻度が高いことが分かった．さらに, それらの組み合わせがどのような作業を行っているかを, リファクタリングの実施履歴の詳細から調べ, その調査結果からリファクタリングの組み合わせをまとめて実施するための, Eclipse のリファクタリング機能の改善を考案した.
キーワード

リファクタリング, ソフトウェア開発履歴, 統合開発環境, オブジェクト指向プログラミング，利用履歴分析，ソフトウェア保守

An investigation of refactoring performed in combination
Tsubasa SAIKA† , Eunjong CHOI† , Akira GOTO† , Norihiro YOSHIDA†† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
Yamadaoka 1-5, Suita, Osaka 565-0871 Japan†† Graduate School of Information Science, Nagoya University
Furo-cho, Chikusa-ku, Nagoya, 464-8601, Japan
E-mail: †{t-saika,ejchoi,a-gotoh,inoue}@ist.osaka-u.ac.jp, ††yoshida@ertl.jp
Abstract Numerous tools that support refactoring have been proposed. However, existing refactoring support
tools do not support consecutively co-occurred refactoring. This study investigated frequency on refactoring thatwere occurred within 90 seconds by analyzing refactoring history of data set in software projects. As a result, itturns out that refactoring pairs (Move, Rename), (Rename, Rename) and (Extract, Move) were more frequently
occurred than other refactoring. Furthermore, this study investigated detailed co-occurred refactoring work and devised suggestions for improving Eclipse’s automated refactoring features in order to support co-occurred refactoring
based on the results of the investigation.
Key words Refactoring, Software development history, IDE, Object-oriented programming, Usage analysis, Software maintenance1. ま え が き向上させることができる [2]. しかし, 誤って実施されたリファクタリングによって, ソフトウェアに新たなバグを発生させる

リファクタリングとは, ソフトウェアの外部から見た振る舞場合がある. バグが発生しないようにリファクタリングを実施

いを変えずに, 内部の構造を整理する作業のことである [1]. リするために, 様々なリファクタリング支援ツールが提案されてファクタリングの主な目的は, ソースコードの可読性や保守性いる [3]〜[5].の向上である. また, リファクタリングを実施することで, 機能例えば, 利用者が多い統合開発環境の Eclipse にもリファクタの追加や, バグの発見が容易になり, ソフトウェア開発の効率をリング機能が備わっている. しかし, Murphy-Hill らの調査に—1—

よると, 実際のソフトウェア開発では約 9 割のリファクタリン善できることである. 設計の良し悪しは開発の効率にも関係すグがツールを使わずに行われている [6]. リファクタリングの種るが, リファクタリングによって設計を改善することで, ソフト類, プログラミング言語, 開発環境などによっては対応するツーウェア開発の効率を向上させることがある [1]. リファクタリン

ルが存在しない場合もあるが, 対応するツールがあるにも関わグによってソフトウェアの設計をいつでも改善できるため, 設らず, その利用率が低い原因としては, 既存のツールが実際の開計の完成を待たずにコーディングを開始することが出来る.

発者のリファクタリングに合っていないと考えられている.

また, プログラムは時間が経つことで劣化する. つまり, 機能開発者のリファクタリングに即したツールを開発するために,の追加やバグの修正などの保守作業によって, 本来の設計から複数の研究者達が開発者のリファクタリングの動向を調査して離れたプログラムになり, 理解が難しくなってしまう. リファ

きた [6]〜[8]. Murphy-Hill らは同じ種類のリファクタリングがクタリングはコードを読みやすくし, 設計を改善することで, 機連続して実施されることが多いことを明らかにした [6]. このよ

能の追加などやバグの修正などの保守作業の効率を向上させる

うにリファクタリングは一度にまとめて実施されることが多い

ため, リファクタリングによってプログラムの劣化を防ぐこと

一方で, 既存のツールではリファクタリングを１つ１つ実施しができる [1].

なくてはならない. これが Eclipse のリファクタリング機能が2. 2 Eclipse のリファクタリング機能あまり利用されない理由の１つであり, 連続して複数のリファ

Eclipse はリファクタリング実施を支援する機能を提供しクタリングを実施可能なツールを開発するべきと彼らは主張している．この章では, Eclipse のリファクタリング機能のうち,ている.

Rename, Move, Extract について紹介する. これらのリファク一方, 異なる種類のリファクタリングがまとめて実施される頻度も高く, シームレスな移行が可能なようにツールを改善する必要がある. しかし, どの種類のリファクタリングの組み合タリングは実施される頻度が高いものである [10].

Eclipse のリファクタリング機能では, 基本的には個々のリファクタリングが連携していない.

わせが頻繁に実施されているかはまだ知られいない. 本研究でa ) Rename

は, 一度にまとめて実施される異なる種類のリファクタリング

メソッド, フィールド, ローカル変数, パッケージ, クラスなについて, どの種類の組み合わせが実施されるのかと, その頻度どの識別子の名前変更を行うリファクタリングで, それに合わを明らかにする. そのために, Eclipse の利用履歴と Mylyn プせてその識別子に対する全ての参照も修正する必要がある.

ロジェクトの開発履歴を用いて, リファクタリング履歴の調査を行った. まず, 連続して実施されたリファクタリングを判別し, そして, 連続して実施された異なる種類のリファクタリング

Eclipse の Rename のリファクタリング機能では, 名前の変更と同時に全ての参照を自動的に更新するかを選択できる.

b ) Moveの組み合わせを調査した. それから, 実施された頻度の高いリ

静的なメソッドやフィールド, パッケージ, クラスなどを別のファクタリングの組み合わせについて, どのような目的で連続パッケージまたはクラスに移動するリファクタリングで, それしたリファクタリングが実施されたのかを調査した.に合わせてそれらに対する全ての参照も修正する必要がある.

調査の結果, 実施された頻度が高いリファクタリングの組み

Eclipse の Move のリファクタリング機能では, 移動先を選択

合わせは, Rename と Move と Extract の組み合わせだというするダイアログが表示され, そこで同時に全ての参照を自動的ことが分かった. これらのリファクタリングを連続して実施でに更新するかを選択できる.

きるようなツールを作成することで, 開発者はより効率良くリc ) Extract

ファクタリングを実施できると考えられる.

コードの一部を抽出して, 新しいメソッドやローカル変数, 定以降,2 節では本研究の背景を説明し, 3 節では調査対象のデー数フィールド, インタフェース, クラスなどとして作成するリタセットと調査手順を説明する. 4 節ではその調査結果を説明

ファクタリングである. 抽出するコードの種類によって作業がし, 5 節でそれに対する考察を行う. 6 節では本研究のまとめと大きく異なるために, 別々な種類のリファクタリングとされる今後の課題を述べる.

ことが多い.

2. 背景

例えばインタフェースを抽出するＥｃｌｉｐｓｅのリファクタリング機能では, 抽出するコードを選択するためのダイアロ

2. 1 リファクタリング

グを表示し, その設定に基づいてインタフェースの作成や参照

リファクタリングとは, ソフトウェアの外部から見た振る舞による置き換えなどを自動的に行う.

いを変えずに, 内部の構造を整理する作業のことである [1]. つ

2. 3 関 連 研 究

まり, リファクタリングではソフトウェアの機能そのものは変Murphy-Hill らは, 利用率の低いリファクタリング支援ツー更せず, コードを理解しやすいようにソフトウェアの構造を変ルを改善することを目的として, 開発者が Eclipse のリファク化させる. 本研究で対象としている言語は Java だが, それ以外タリング機能を使って実施したリファクタリングの詳細履歴をにもオブジェクト指向言語ならばリファクタリングを実施する

調査し, 同じ種類のリファクタリングが連続して実施されるこことができ, オブジェクト指向の利点であるコードの再利用性とを明らかにした [6]. 彼らの研究では, 60 秒以内に実施されたを高めることが出来る [9].
リファクタリングの利点の一つは, ソフトウェアの設計を改リファクタリングを, 連続して実施されたリファクタリングと見なしていた. この 60 秒という時間間隔は彼らの経験から導—2—かれたものである.

グの種類と, それぞれの実施された回数と割合を示す.

彼らの研究は, 同じ種類のリファクタリングが連続して実施

3. 1. 2 Mylyn データセットされることを明らかにしたが, 互いに異なる種類のリファクタ

Mylyn データセットは, Mylyn という Eclipce のタスク管理リングが連続して実施されるかどうかは調査されていない. 異プラグインを開発している, Mylyn プロジェクトの保守履歴でなる種類のリファクタリングが連続して実施される割合も高いある. Mylyn プロジェクトでは Mylyn プラグインを使って保守のであれば, 実施される頻度の高い組み合わせについて調査す作業を記録している. また, Mylyn の開発者はリファクタリンるべきである.

グの専門家とは限らないが, 開発しているものがタスク管理プラグインであり Eclipse の機能には詳しく, 一般的な開発者よりも3. 調 査 手 法リファクタリングについては詳しいと推測できる. Murphy-Hill

3. 1 調査対象のデータセット

らはこのリファクタリングの実施履歴がデータベースにまとめ

本研究は Users と Mylyn のデータセットを調査した. 本研

た [6]. このデータベースには, 実施されたリファクタリング毎究で調査した２つのデータセットは, それぞれ異なる開発者をに, 種類と実施された日時, そしてリファクタリングの対象など

対象にこの Mylyn プラグインを使って記録された, Eclipse のの詳細情報が含まれている. 本研究ではこのデータベースを使リファクタリング機能の使用履歴である. Mylyn とは Eclipce用した.のタスク管理プラグインで, 2009 年 11 月の機能変更までは, この Mylyn プラグインを使ってプログラマのリファクタリング

表 3 に, Mylyn データセットに実施履歴が含まれるリファクタリングの種類と実施された回数と割合を示す.の履歴を, リファクタリングを実施した時間を含めて正確に記

3. 2 調 査 手 順録することが出来た. 表 1 はそれぞれのデータセットの概要でUsers と Mylyn の２つのデータセットのリファクタリング実ある. Users データセットは, 2005 年 7 月から 2005 年 9 月ま

施履歴を対象として, 連続して実施された頻度の高い互いに異での 41 人のリファクタリング実施記録である. リファクタリ

なるリファクタリングの組み合わせを明らかにするため, 以下ングの総実施回数は 3494 回で, リファクタリングの種類は 22の手順で調査を行った.

種類である. Mylyn データセットは, 2006 年 2 月から 2009 年（ 1 ） 連続して実施されたリファクタリングを判断する

8 月までの 8 人のリファクタリング実施記録である. リファク（ 2 ） 連続して実施された互いに異なるリファクタリングのタリングの総実施回数は 4637 回で, リファクタリングの種類は組み合わせを調査する

19 種類である. 以降, それぞれのデータセットについて詳しく（ 3 ） 実施された頻度の高いリファクタリングの組み合わせ説明する.

についてその作業内容を調査する

3. 1. 1 Users データセット
Users データセットは, Eclipce の利用者である 41 人の開発

表 2 Users に含まれるリファクタリングの種類と実施回数者の, リファクタリング履歴である. このデータセットは Gail

リファクタリングの種類

Murphy らが, 職業や所属組織が異なる開発者を対象に, ソフトウェア開発履歴を収集したものである [10].
このデータセットが対象とした 41 人の開発者は様々な背景を持っており, リファクタリングの専門家ではないため, 一般的なソフトウェア開発の傾向が調査できると考えられる.

実施回数

実施割合

Rename

1992

57.0%

Extract Local Variable

449

12.9%

Extract Method

305

8.7%

Move

180

5.2%

Inline174

5.0%

Promote Local Variable

95

2.7%

この Eclipse の利用履歴のデータの形式は, Mylyn のプラグ

Extract Constant591.7%

インによってコミット毎に分けて作成された XML ファイルでModify Parameters401.1%ある. この中には, 開発環境の設定の変更や, エディタでの編集

Pull Up

361.0%

履歴, その他のコマンドの実施履歴などが残されている. リファ

Convert Local To Field

290.8%

Convert Anonymous To Nested

290.8%

Introduce Parameter

250.7%

Extract Interface

240.7%の種類がリファクタリングと判断できるものを抽出した. 表 2

Change Method Signature

160.5%で, Users データセットに実施履歴が含まれるリファクタリン

Move Static Member

120.3%

Convert Member Type to Top Level

80.2%

Encapsulate Field

80.2%Use Supertype

60.2%

Externalize Strings

40.1%

Change Type

10.0%

Generalize Type

10.0%

クタリングの実施履歴はコマンドの実施履歴に含まれる.
本研究では, Users の全てのコマンド実施履歴から, コマンド

表 1 データセットの概要
データセット

開発者数

Users

41

Mylyn

8期間
2005 年 7 月〜2005 年 9 月
2006 年 2 月〜2009 年 8 月

リファクタリング リファクタリング
総実施回数
種類数

3494

224637

19

Infer Type Arguments
合計

10.0%

3494

100.0%—3—まず, 本研究ではデータセットから得られる限られた情報の中，リファクタリングが実施された時間に基づいて, 連続して4. 調 査 結 果実施されたリファクタリングを判別した．従って, あるリファ

4.1 節では２つのデータセットについて, 連続して実施されたクタリングが実施されてから, 90 秒以内に次のリファクタリン

頻度の高い, 互いに異なる種類のリファクタリングの組み合わグが実施されれば, それらは連続して実施されたと判断した. 本せを調査した結果を示す. 4.2 節では Mylyn データセットに含研究で定めた一定時間内で行われたリファクタリングが, 開発

まれるリファクタリングの詳細な履歴から, 頻度の高いリファ者が一つの作業として実施したリファクタリングであるとは限クタリングの組み合わせについて支援方法を考察するために,らない. この問題に対しては, 実施された頻度の高いリファクリファクタリングの組み合わせの作業内容について調査した結タリングの組み合わせについて, 実行履歴の詳細を確認し, それ果を示す.

らが関連性のあるものかを調べることで対応する.

4. 1 頻度の高い異なる種類のリファクタリングの組み合わせ

次に, 連続して実施される異なる種類のリファクタリングの

表 4 が Users の調査結果で, 表 5 が Mylyn の調査結果であ組み合わせの調査を行った. 全ての連続して実施されたリファる. 表には実施されたものを回数の多い順に 10 組のリファククタリングについて, 組み合わせ毎に実施された回数を調査しタリングを示している. また, この表の欄のリファクタリングた. ただし, 同じ種類の組み合わせでも実施された順序が異な

１は組み合わせの中で先に実施されたリファクタリングを表し,れば別の組み合わせとした. そして, 頻度の高いリファクタリ

リファクタリング２がその次に実施されるリファクタリングをングの組み合わせについて, 支援方法を考察するために, 詳細表している. 3 種類以上のリファクタリングが連続して実施さな作業内容を調査した. ただし, Users のリファクタリングの実れる回数は 5 回未満であった.

施履歴にはリファクタリングの対象などの情報が含まれていな

Rename, Move, Extract は実施される頻度の多いリファクタかったため, 作業内容の調査は Mylyn のリファクタリング履歴

リングで, それらの種類のリファクタリングを含めた組み合わに対してのみ行った. 具体的な調査方法は, 実施される頻度のせが多いことが分かる.

高い上位 10 個のリファクタリングの組み合わせについて, 実施

また, ２つのデータセットで出現する回数の順位は異なっても,された履歴の詳細を各 10 個ずつ調査し, リファクタリングの対同じような組み合わせが多いことがわかる. 順位が異なるのは,象と, その前後に実施されたリファクタリングを調べた. そしどのリファクタリングが多く実施されるかが主に影響しているて, 対象が同じもの, 関連するもの, 関連がわからないものに分と考えている. 例えば, Users の方では Extract Local Variable,けた. 関係の有無については同じパッケージやクラスに属する

Extract Method, Inline などの実施回数が多く, Mylyn の方でか, 対象の名前が類似しているかで判断した.

は Move, Extract Interface, Extract Constant などの実施回数が多い.
表 6 は, Mylyn について Rename を対象の種類で分けた場合の, 連続して実施される頻度の高い異なる種類のリファクタリングの組み合わせである. 表には実施されたものを回数の多い

表 3 Mylyn のリファクタリングの種類と実施回数順に 10 組のリファクタリングを示している. 対称の種類によ

実施回数

実施割合

る分類とはつまり, Move をクラスやパッケージの移動, Move

Rename

2401

51.8%

Static Member を静的なフィールドの移動と分けている. また,

Move

691

14.9%

Rename もローカル変数, フィールド, メソッドなどに対象で分Extract Method

305

6.6%

けている. Rename Type というのはクラスの名前変更である.

Extract Local Variable

254

5.5%

ここでは, 異なる種類の対象への Rename と Rename の組み合

Extract Constant

245

5.3%

Move Static Member

235

5.1%

Change Method Signature

191

4.1%

リファクタリングの種類

わせを, 異なる種類のリファクタリングとして扱っている. 表

6 から, Rename は対象の要素の種類に関係なく, 関連する要素にまとめて実施される場合が多いことがわかる.

Inline1102.4%

Convert Member Type to Top Level

440.9%

Infer Type Arguments

300.6%

Mylyn データセットで, 連続して実施された回数が多い順に,Extract Interface

290.6%

10 個の互いに異なる種類のリファクタリングの組み合わせにつEncapsulate Field

290.6%いて, その作業内容をリファクタリング実施履歴の詳細から調Convert Anonymous To Nested

230.5%

Extract Superclass

160.3%

Promote Local Variable

150.3%

Pull Up

140.3%

うかを示したものである. ただし, 組み合わせの順序を無視し,Push Down

30.1%

Move と Rename を対称の種類で分類した場合とする.

Use Supertype

10.0%

実施回数はその組み合わせが実施された数を, 調査数はリファ

Introduce Parameter

10.0%

クタリングの実施履歴の詳細を調べた数を表している. 同じ対4637

100.0%

象とは, 調査数のうちリファクタリングの対象が同じであった

合計

4. 2 頻度の高いリファクタリングの組み合わせの作業内容査した. 表 7 は, 作業内容を調査したリファクタリングの組み合わせと, それぞれのリファクタリングが互いに関連するかど—4—

表 7 頻度の高いリファクタリングの組み合わせの作業内容
リファクタリング１

リファクタリング２

Move

Rename Type

実施回数

58

調査数 同じ対象

104

関係あり

1

Rename Field

Rename Method

481005Rename Type

Rename Method

32

1004Move

Rename Package

291017Rename Type

Rename Field

26

1003Move Static Member

Rename Field151060

Extract Interface

Move141071Rename Local Variable Rename Field

121006Move

Move Static Member

121002MoveRename Field

121000数である. 当然, リファクタリングの対象の種類が異なる場合

ジ, クラス, フィールドなどを移動した後に, その移動した要素には, 同じ対象になることはない. 関係ありとは, リファクタリの名前を変更していた. また, Move と Rename の対象が関係ングの対象に関係がありそうなものの数である. 関係の有無にする場合だと, クラス, フィールド, メソッドなどの移動の後に,ついては同じパッケージやクラスに属するか, 名前が類似してその宛先のパッケージやクラスの名前を変更していた.

いるかで判断した.

（ 2 ） (Rename, Rename) の作業内容

以降, 各リファクタリングの組み合わせについてその作業内異なる種類の要素を対象とした, Rename と Rename の組み合容を説明する.

わせの作業内容から, Rename は対象の種類に関係なく, 関連（ 1 ） (Move, Rename) の作業内容する要素を対象に連続して実施される場合が多いことが判明しMove と Rename の組み合わせの作業内容から, ある要素を移た. また, 連続して変更される名前は単語が共通するなど類似

動したとき, それに合わせて名前を変更する場合が多いことがしていることが多い. 例えば, ローカル変数名とフィールド名判明した. Move と Rename の対象が同じ場合だと, パッケーの Rename では, コンストラクタや getter, setter のローカル変数名と, それに対応するフィールドの名前を連続して変更し

表 4 Users の連続して実施された頻度の高い互いに異なる種類のリファクタリングの組み合わせ.

ていた.
（ 3 ） (Extract Interface, Move) の作業内容

リファクタリングの種類

Extract と Move の組み合わせの作業内容から, インタフェー

リファクタリング１

リファクタリング２

Extract Method

Rename

実施回数35Extract Local Variable Rename

22

Extract Local Variable Extract Method

19Rename

Extract Method

17Rename

Move

15

本調査の結果, 連続して実施される互いに異なる種類のリファ

Extract Method

スを抽出した後に、それを適当なパッケージに移動することが多いことが判明した.

5. 考察Inline

14

クタリングのうち, 実施される頻度の高い組み合わせがわかっ

Extract Local Variable Inline

14

た. これらの頻度の高い組み合わせに対して行った作業内容のInline

Extract Local Variable

14

調査をもとに, 連続して実施されるリファクタリングの支援方

Extract Local Variable Promote Local Variable

12Move12Rename

表 6 Move と Rename を対称の種類で分類した場合の, Mylyn の連表 5 Mylyn の連続して実施された頻度の高い互いに異なる種類のリファクタリングの組み合わせ.

続して実施された頻度の高い互いに異なる種類のリファクタリ
ングの組み合わせ.
リファクタリングの種類

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

MoveRename
Extract Interface

リファクタリング２

Rename
Move
Move

実施回数

88
62
12

Extract ConstantRename11

Extract Constant

Move

10

Extract Method
Extract Method

RenameExtract Local Variable

Extract Local Variable Rename

966Rename

Change Method Signature

5InlineRename5

リファクタリング１

リファクタリング２

Rename Type

Move

実施回数

30

Move

Rename Type28

Rename Field

Rename Method

26

Rename Method

Rename Field

22

Move

Rename Package

19

Rename TypeRename Method

16

Rename Method

Rename Type16

Rename Type

Rename Field

13

Rename Field

Rename Type13

Extract Interface

Move

12—5—

法を考える.
以降, 現状の Eclipse のリファクタリング機能の仕様上の, 連が, 連続して実施されるリファクタリングの数を増加させるかどうかを明らかにしたい. また, ソフトウェア産業でのリファ続して実施する際の問題点を解消する支援方法を考案する.

クタリングの実態調査 [13] で, どのようなリファクタリングが（ 1 ） (Move, Rename) の支援連続して実施されるかにも興味がある. そして, 本研究の考案

現状の Eclipse のリファクタリング機能の仕様では, Move とに基づいてリファクタリング支援ツールを開発する予定である.

Rename のリファクタリングは連携していないため, それぞ謝辞 本稿の執筆に際して，貴重なご意見をくださった大阪

れ別々に実施するとダイアログが２回も表示されることにな

大学 大学院情報科学研究科 春名 修介 特任教授に感謝いたしまる. この組み合わせに対する支援方法としては, まず Move とす．本研究は JSPS 科研費 25220003 の助成を受けたものです．

Rename の対象が同じ場合には, Move のダイアログに新しい名前を入力する項目を追加して, まとめて実施できるようにすることが考えらる. また Move と Rename の対象が関係する場
合には, Move の後に, 関係する要素へ Rename を推薦することが考えられる. ただし, 一度に複数のクラスを Move するときがあるので, その場合にはそれぞれのクラスに対して個別に名前を変更できるようにするべきである.
（ 2 ） (Rename, Rename) の支援
この組み合わせに対する支援方法としては, ある要素を Renameするとき, 名前が類似した要素をまとめて Rename できるようにすることが考えられる. 現状の Eclipse のリファクタリング機
能の仕様では, クラスを対象とした Rename のダイアログでは,類似の名前の要素をまとめて Rename できる. しかし, フィールドやメソッドなどの Rename にはそのような支援がないため, 同様に類似の名前の Rename をまとめてできるようにすることが考えられる.
（ 3 ） (Extract Interface, Move) の支援

Extract Interface のダイアログで Java ファイルを作る場所を指定できるようにすれば, 続けて Move する手間は無くなると考えられる. ただし, 現状の Eclipse のリファクタリング機能の仕様では, Java ファイルの Move はパッケージエクスプロー
ラーからドラッグ＆ドロップを用いて実施出来るため, この組み合わせについては現状の Eclipse の機能のみで十分な支援だ出来ているとも考えられる.

6. まとめと今後の課題
本研究では, 互いに異なる種類のリファクタリングが高い頻度で組み合わせて実施されると推測して, ソフトウェア開発履歴中の, 連続して実施された頻度の高いリファクタリングの組み合わせを調査した. ただし, リファクタリングが 90 秒以内に続けて実施された場合を連続と見なした. 調査の結果, 連続文

献[1] M. Fowler, Refactoring:Improving the Design of Existing
Code, Addison Wesley, 1999.
[2] G. Bavota, B.D. Carluccio, A.D. Lucia, M.D. Pentaand, R.
Oliveto, and O. Strollo, “When does a refactoring induce
bugs? an empirical study,” Proc. of SCAM, pp.104–113,
2012.
[3] S.R. Foster, W.G. Griswold, and S. Lerner, “Witchdoctor:IDE support for real-time auto-completion of refactorings,”
Proc. of ICSE, pp.222–232, 2012.
[4] X. Ge, Q.L. DuBose, and E. Murphy-Hill, “Reconciling
manual and automatic refactoring,” Proc. of ICSE, pp.211–221, 2012.
[5] R. Tairas and J. Gray, “Increasing clone maintenance support by unifying clone detection and refactoring activities,”
Inf. Softw. Technol., vol.54, no.12, pp.1297–1307, 2012.
[6] E. Murphy-Hill, C. Parnin, and A.P. Black, “How we refactor, and how we know it,” IEEE Trans. Softw. Eng., vol.38,no.1, pp.5–18, 2012.
[7] E. Choi, N. Yoshida, and K. Inoue, “An investigation into
the characteristics of merged code clones during software
evolution,” IEICE Trans. Inf. & Syst., vol.E97-D, no.5,
2014. to appear.
[8] E. Murphy-Hill and A.P. Black, “Breaking the barriers tosuccessful refactoring: observations and tools for extract
method,” Proc. of ICSE, pp.421–430, 2008.
[9] L. Tokuda and D. Batory, “Evolving object-oriented designs
with refactorings,” Proc. of ASE, vol.8, no.1, pp.89–120,
2001.
[10] G.C. Murphy, M. Kersten, and L. Findlater, “How are java
software developers using the Eclipse IDE?,” IEEE Softw.,
vol.23, no.4, pp.76–83, 2014.
[11] A. Yamashita and L. Moonen, “Exploring the impact ofinter-smell relations on software maintainability: an empirical study,” Proc. of ICSE, pp.682–691, 2013.
[12] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: amultilinguistic token-based code clone detection system forlarge scale source code,” IEEE Trans. Softw. Eng., vol.28,no.7, pp.654–670, 2002.
[13] M. Kim, T. Zimmermann, and N. Nagappan, “A field studyof refactoring challenges and benefits,” Proc. of FSE, pp.1–11, 2012.

して実施された頻度の高いリファクタリングの組み合わせは,(Move,Rename),(Rename,Rename),(Extract,Move) であることが判明した. そして, それらのリファクタリングの組み合わせについて, その作業内容を調査し, その結果から一度にまとめて実施するための Eclipse のリファクタリング機能の改善を考案した. 今後の課題としては, 多くの Bad-smell を含む古いソフトウェア・プロジェクトと良く保守されたソフトウェア・プロジェクトの間で, 連続して実施されるリファクタリングを比較する予定である. Bad-smell とは, リファクタリングを実施することが推奨されるコードの不吉な臭いのこと [1] であり,Bad-smell の組み合わせ [11], あるいはコードクローンの量 [12]—6—