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

信学技報
TECHNICAL REPORT OF IEICE.

Java プロジェクトの変更履歴に含まれる
本質的でない変更についての調査
前島葵†

肥後 芳樹†

松本淳之介†

楠本真二†† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{a-maejim,higo,j-matumt,kusumoto}@ist.osaka-u.ac.jp
あらまし ソースコードの変更には，プログラムの振る舞いを変える変更がある一方，振る舞いを変えない変更も存在する．本研究では，前者を本質的な変更とし，後者を本質的でない変更とする．本質的でない変更は，プログラ
ムの振る舞いに影響を与えないため，本質的な変更が行われた時と同様の費用をテストにかける必要がない．本質的でない変更の割合を調査することで，無駄となっているテストの費用を推定できる．本研究では，Java プロジェ
クトを対象とし，バイトコードの変化の有無による本質的な変更と本質的でない変更の分類方法を提案する．コンパイルによって失われる情報だけを含む変更は本質的でないとみなし，ソースコードを変更した際にバイトコードが変わらない変更を本質的でない変更とする．調査の結果 4 つの Java プロジェクトに含まれる Java ファイルの変
更がなされたコミットのうち，8.9%∼22.3% のコミットは本質的でない変更のみで構成されていた．
キーワード

ソフトウェアリポジトリマイニング，ソフトウェア進化

1. ま え が きが本質的でない変更であるという結果が報告された．しかしながら，調査の対象となった本質的ではない変更は彼らの定バージョン管理システムを利用したオープンソースソフト

義による主観的な分類である．そのため，彼らの調査で発見

ウェア開発が広がり，ソースコードの様々なバージョンが記されていない本質的でない変更が存在するのではないかと著録され，バージョン間の変更が追跡されている [1] ．変更履歴

者らは考えた．

に記録された変更をマイニングする多くの手法が存在し，マ本研究では，Java プロジェクトを対象とし，バイトコード

イニングされた変更の情報は，欠陥予測 [2], [3] ，コード間のの変化の有無による本質的な変更と本質的でない変更の分類

依存関係の検出 [4], [5] に利用されている．

方法を提案する．変更の情報がコンパイルによって失われる

ソースコードの変更には，新たな機能の実装や既存の機能の修正などのプログラムの振る舞いが変わる変更が存在する一か失われないのかで分類を行うため，分類者の主観が入らな
い分類が可能になる．

方で，コメントの変更やソースコードのフォーマット，変数名提案手法では，既存の Java プロジェクトリポジトリから，の変更などのプログラムの振る舞いに影響を与えない変更もJava ファイルとバイトコードを逆コンパイルしたファイルを存在する．これらの変更は可読性や保守性などの品質向上の持つリポジトリを作成する．作成されたリポジトリの変更履歴

ために行われ，プログラムの振る舞いは保持される．本研究を辿り Java ファイルの変更のみがなされているコミットを本では，プログラムの振る舞いが変わる変更を本質的とし，プロ

質的でない変更のみで構成されたコミットとして調査を行う．

グラムの振る舞いが変わらない変更を本質的ではないとする．

調査では以下に示す 2 つの Research Question に答えるこ

コミットごとに大きな費用を費やしてテストが行われていとを目的とする．

る．しかし，コミットの中には本質的な変更で構成されたコ

RQ 1

本質的でない変更がどの程度存在するか

ミットがある一方で，フォーマットやコメントの変更のみで

RQ 2

本質的でない変更にはどのような変更があるか構成されたコミットも存在する．本質的でない変更しかなさ

調査の結果，4 つの Java プロジェクトにおいて，Java ファ

れていないコミットは，本質的な変更がされているコミット

イルの変更がなされたコミットのうち，8.9%∼22.3% のコミッと同様の費用をかけてテストを行う必要がない．

トは本質的でない変更のみで構成されたコミットであること

Kawrykow らによって，本質的でない変更についての調査を確認した．また，先行研究と比較し新たに本質的でない変が行われた [6] ．彼らは本質的でない変更を，プログラムの振更と定義された変更として，アノテーションの変更や ﬁnal 修

る舞いが保持される変更であり，リポジトリマイニングにおい飾子の付与など 19 の変更が存在することを確認した．

て分析の必要がない変更と定義した．また，その定義から本質的でない変更例を挙げた．コメントの変更や，変数名の変更などがあたる．調査の結果，メソッドの変更の最大で 15.5%

2. 研 究 背 景Kawrykow らは本質的でない変更について調査を行い，メ—1—

ソッドの変更の最大で 15.5% が本質的でない変更であるという結果を報告した [6] ．

既存Javaプロジェクトリポジトリ
コミット

彼らは，本質的ではない変更の定義を，以下の 3 項目を満たす変更と定義した．
• 表面的な変更である•プログラムの振る舞いが保持される•

変更箇所の役割や関係から，意味のある情報を得られリポジトリを過去の状態に戻す

.java

ビルド

そうにない

.class

これらの定義から本質的でない変更を以下の 6 つとした．
詳しい内容については 6. で述べる．
• 完全限定名から単純名への変更•

一時変数への式の抽出•

名前の変更およびその参照箇所の変更•

些細なキーワードの更新•

ローカル変数名の変更•

空白文字およびコメントの更新

しかしながら，これらの 6 つの変更は彼らの定義による主観的な分類である．そのため，彼らの調査で発見されていない

逆コンパイル.rjava

追加
.java

コミット
新規Javaプロジェクトリポジトリ

本質的でない変更が存在するのではないかと著者らは考えた．

3. 調 査 方 法
3. 1

分 類 法

本研究では本質的な変更と本質的ではない変更を，バイトコードの変化の有無で分類する．
バイトコードとは，Java ソースコードのコンパイル時に生.rjava

図1 調査方法

れる Git リポジトリである．
Step 1

リポジトリを特定のコミットの状態に復元

Step 2

ビルド

Step 3

逆コンパイル

Step 4Java, rJava ファイルを新規リポジトリに追加

以降，各 Step について説明する．

成される中間コードのことである．バイトコードの変化の有

Step1 ではリポジトリを特定のコミットの状態に復元する．

無で分類することで，ソースコードがコンパイルされる際にStep2 ではビルドを行いバイトコードであるクラスファイル

失われるコメントやフォーマットなどの情報は本質的ではなの作成を行う．対象のプロジェクトごとにビルドツールは異い情報と定義できる．

なっており，本研究では Gradle および Ant を用いた．Step3

ソースコードの変更にともないバイトコードも変化する変ではクラスファイルを逆コンパイルする．逆コンパイルの結更は本質的な変更とし，ソースコードが変化したにも関わら果 rJava ファイルが作成される．Step4 では Java ファイルとずバイトコードが変化しなかった変更は本質的ではない変更

rJava ファイルを対応付け，新規リポジトリに追加する．

とする．

3. 3

3. 2 rJava ファイル
本研究では，バイトコードを逆コンパイルした結果得られるファイルを rJava ファイルと呼ぶ．

調査方法

作成された変換リポジトリの変更履歴を調べ，Java ファイ
ルが変更された全てのコミットを調査する．Java ファイルの変更にともない rJava ファイルが変更されていれば本質的な逆コンパイルには，javap -p -c [file] コマンドを用い変更がなされたコミット，rJava ファイルが変更されていなけた．オプションには，-p -c を指定した．-p オプションによれば本質的でない変更のみで構成されたコミットであると分り，プライベートメソッドも含めすべてのメソッド，フィール類する．

ドを逆コンパイルの対象と指定する．-c オプションにより，メソッドごとに，逆コンパイルされたすべてのバイトコード

4.

命令を出力する．

本研究では，Java プロジェクトリポジトリにどの程度本質

3. 2. 1

変換リポジトリの作成方法

Research Question

的でない変更が存在するかを調査する．調査を行うにあたり調査を行うにあたって，前準備として既存の Java プロジェ

以下に示す 2 つの Research Question を設定した．

クトリポジトリから，Java ファイルと rJava ファイルを持つ

RQ1: 本質的でない変更がどの程度存在するか

リポジトリを作成する．変換リポジトリの作成方法の概要をJava プロジェクトのコミットの何割が本質的でない変更の

図 1 に示す．変換リポジトリの作成方法の入力は，Java ソー

みで構成されているか調査する．コメントの変更やフォーマッ

スコードを含む Git リポジトリである．出力は，Git リポジト

トの変更のような本質的でない変更しかなされないコミット

リに含まれる全てのコミットに対して以下の 4 つのステップ

が実際に存在するのか，またその割合を調査する．本質的でを適用し作成された Java ファイルと rJava ファイルで構成さ—2—

ない変更のみで構成されたコミットは，プログラムのテスト–+

java.util.List list = new ArrayList<>;
List list = new ArrayList<>;を行う必要がないため，どの程度のテストの費用が削減でき
図2

るかの推定に繋がる．

6. 考

RQ2: 本質的でない変更にはどのような変更があるか
バイトコードの変化の有無で分類することで，どういった変更が本質的でない変更に分類されるか調査する．先行研究
では，Kawrykow らによって本質的でない変更の定義がなされていたが，バイトコードによる分類法を用いることで，本質的でないと定義できる変更の範囲がどの程度広がるのか調査
を行う．

5.

RQ1 ，RQ2 の調査

察

本章では，本質的でない変更を以下の 3 種類に分類し，述べる．また先行研究と差が生じた割合についても述べる．
• 先行研究と同様に本質的でないと定義された変更•先行研究では本質的であるが提案手法では本質的でないと定義された変更• 先行研究では本質的でないが提案手法では本質的と定義された変更

本章では，バイトコードの変化の有無による分類法を用いて行った調査と，その結果について述べる．
5. 1

完全限定名から単純名への置換

6. 1

先行研究と同様に本質的でないと定義された変更

コメントの変更 コメントの変更には，1 行，もしくは複数行に渡るコメント，および Javadoc の変更が挙げられる．これ

調査対象

調査対象は Java ソースコードを含む Java プロジェクトのリポジトリである．本研究では，著者らの所属している研究室で開発されている Java プロジェクトである kGenProg，先行研究が対象にしたプロジェクト（Apache ant, Azureus, Hibernate, JDT-Core, JDT-UI, Spring Framework, Xerces） の
うち，Java のバージョンの違いなどの理由によりビルドに失敗したプロジェクトを除いたプロジェクト（Apache ant,
Hibernate, Spring Framework) を加えた 4 つのプロジェクト
で調査を行った．
調査対象のプロジェクト，調査の対象期間を表 1 に示す．ただし，テストコードは対象となるソフトウェアを構成しない
ため，調査対象に含まなかった．

らはコンパイル時に情報が失われるため，バイトコードに変化を与えない．調査の結果，Apache ant，Spring Framework
Core では本質的でない変更の半分がコメントの変更であった．
フォーマットの変更 フォーマットには，インデントの調整，
等号や括弧の前後のスペースの挿入削除，中括弧後の改行の調整，行の折り返しの調整などが存在した．コメントと同様に可読性や保守性を高めるフォーマットの変更であるが，バ
イトコードに変化を与えない．コメントに次いで割合が多く，12.2%-31.0% を占めた．
完全限定名から単純名への置換 例を図 2 に示す．パッケー
ジ名を指定してクラスを呼び出す完全限定名の記述から，import 文にパッケージ名を記述しクラス名のみを用いて呼び出しを行う単純名の記述への変更はバイトコードに変化を与え

5. 2 RQ1 の調査結果
調査結果を表 2 に示す．4 つの Java プロジェクトにおいて，
Java ファイルの変更がなされたコミットのうち，8.9%∼22.3%のコミットは本質的でない変更のみで構成されたコミットであることを確認した．

ない．割合としては少なく，0.0%-1.7% ほどであった．
ローカル変数名の変更 ローカル変数名の変更，および変更にともなう参照箇所の変更は，バイトコードに変化を与えなかった．ローカル変数名の変更は，変更によって与えらえる影響がそのメソッド内で閉じている．そのため，他のクラス

5. 3 RQ2 の調査結果
また，4 つのプロジェクトで本質的でない変更と分類された結果全てに対して目視確認を行った．本質的ではない変更の分類，その割合を表 3 に示す．先行研究と比較し新たに本質的でない変更と定義された変更として，アノテーションの変
更や ﬁnal 修飾子の付与など 19 の変更が存在することを確認した．本質的ではない変更の中で最も多かったものは，コメントの変更であり続いてフォーマットであった．

パラメータ名の変更 パラメータ名の変更，および変更にともなう参照箇所の変更は，ローカル変数名の変更と同じくバ
イトコードに変化を与えなかった．
this の付与，削除 this の付与例を図 3 に示す．this の付与，削除についてはバイトコードが変化しないことが調査対象のプロジェクトから確認できた．
return 文の付与，削除 return 文の付与例を図 4 に示す．戻表 1 調査対象プロジェクト，対象期間
プロジェクト名やメソッドに影響を及ぼすことのない変更だといえる．

り値が void 型であるメソッドでは，メソッドの処理の最後に

調査開始

調査終了

kGenProg 2018-04-09

2019-11-04

Apache ant 2017-01-01

2019-05-22

トコード中では return 文のない記述に統一される．
super() の付与，削除

Spring Framework Core

2016-08-15

2019-11-13

Hibernate ORM Core

2016-12-16

2019-07-05

return 文を記述しても記述しなくても良い．これらは，バイsuper() によるスーパークラスの引数

表2 調査結果
プロジェクト名 Java ファイルの変更回数

rJava ファイルの変更回数

本質的でない変更の割合

kGenProg

808

651

19.4%

Apache ant

323

259

19.8%

Spring Framework Core

803

624

22.3%

Hibernate ORM Core

1,178

1.073

8.9%

—3—

–
+

+

hoge();
this.hoge();void hoge(int fuga){
void hoge(final int fuga){(a) メソッド引数への ﬁnal 修飾子付与

図 3 this の付与–+-

void hoge() {};void hoge() { return; };

図4
–
+

+

} catch (Exception e) {} catch (final Exception e) {(b) catch 節への ﬁnal 修飾子付与

return の挿入-

void hoge() {};void hoge() { super(); };+for(int hoge : list){for(final int hoge : list){(c) 拡張 for 文の要素への ﬁnal 修飾子付与

図 5 super() の挿入

なしコンストラクタの呼び出しの有無について．super() の付+

List<String> list= new ArrayList<>;
final List<String> list= new ArrayList<>;(d) ローカル変数の ArrayList への ﬁnal 修飾子の付与

与例を図 4 に示す．サブクラスでは，自動的にスーパークラ
スの引数なしコンストラクタの呼び出しがコンパイラによって行われる．そのため，super() を記述する必要がない．
6. 2

図6

ﬁnal 修飾子付与の本質的でない変更なかった．今回の調査対象プロジェクトの中では，kGenProg

先行研究では本質的であるが提案手法では本質的でなのみ ﬁnal 修飾子を多用していた．

いと定義された変更

import 文の並び替え，削除 先行研究では，メソッド単位でバイトコードの変化の有無による分類によって，先行研究

本質的ではない変更が調査されていたためメソッド外の文はに対し新たに本質的ではない変更と定義される例が存在した．

注目されていなかった．しかし，変更の中には，import 文の

ﬁnal 修飾子の付与，削除 ﬁnal 修飾子は変数の代入を無効

並べ換えを行う変更や，未使用の import 文を削除する変更もにするために使用されるが，ﬁnal 修飾子を付与してもバイト

存在し，これらの変更はバイトコードに変化を与えなかった．

コードが変化しない例が存在した．メソッド引数への ﬁnal 修

また，調査対象 4 つのプロジェクト全てにおいて import 文の飾子の付与例を図 6(a) に，catch 節への ﬁnal 修飾子の付与例

変更は行われ，5.2%-11.1% 存在した．

を図 6(b) に，拡張 for 文の要素への ﬁnal 修飾子の付与例を図

アノテーションの変更 アノテーションには，コンパイル時

6(c) に，ローカル変数の ArrayList への ﬁnal 修飾子の付与例に情報が残るアノテーションと，残らないアノテーションがを図 6(d) に示す．これらはいずれもバイトコードに変化を与存在する．バイトコードが変化しないとされたアノテーショ

えなかった．また，ArrayList の宣言のように，参照型のローンの例を図 7 に載せる．先行研究に対し新たに本質的ではな

カル変数への ﬁnal 修飾子の付与はバイトコードに変化を与え

い変更と定義された変更の中で最も割合が高く，7.8%-16.3%

表3 調査結果
本質的ではない変更例

kGenProg Apache ant Spring Framework Core

コメントの挿入，変更，削除

56 (34.6%)

42 (54.5%)

124 (54.1%)

53 (41.1%)

フォーマットの変更

26 (16.0%)

16 (20.8%)

28 (12.2%)

40 (31.0%)

完全限定文，単純名間の変更

2 ( 1.2%)

1 ( 1.3%)

4 ( 1.7%)

ローカル変数名の変更

10 ( 6.2%)

1 ( 1.3%)

4 ( 1.7%)

パラメータ名の変更

3 ( 1.9%)1 ( 1.3%)

2 ( 0.9%)

this の挿入，削除

2 ( 1.2%)

ﬁnal 修飾子の付与

17 (10.5%)

import 文の挿入，削除，並べ替え

18 (11.1%)

5 ( 6.5%)

12 ( 5.2%)

8 ( 6.2%)

アノテーションの挿入，削除，編集

25 (15.4%)

6 ( 7.8%)30 (13.1%)

21 (16.3%)

1 ( 0.8%)

4 ( 1.7%)
1 ( 0.4%)

インターフェース中のメソッドの public 修飾子の削除

1 ( 0.6%)

キャストの挿入，削除

1 ( 0.6%)

1 ( 0.4%)

空文の削除

1 ( 0.6%)

1 ( 0.4%)

2 ( 1.6%)

条件式の書き換え

1 ( 0.4%)

括弧の挿入，削除

8 ( 3.5%)

if 文のブロックの挿入，削除
if 文の連結

Hibernate ORM Core

1 ( 0.4%)

1 ( 0.8%)2 ( 1.6%)

1 ( 1.3%)

else if 文から if 文への書き換え

1 ( 0.4%)

総称型と Object 型

1 ( 1.3%)

総称型のワイルドカードの挿入削除

1 ( 1.3%)

総称型の型宣言の挿入削除

1 ( 1.3%)

ダイヤモンド演算子の使用

1 ( 1.3%)

3 ( 1.3%)

配列宣言の変更

1 ( 0.4%)

修飾子の入れ替え

1 ( 0.4%)

newFactory, newInstance の書き換え

1 ( 0.5%)

呼び出しのないフィールド変数の初期化の変更

1 ( 0.5%)

1 ( 0.8%)

—4—

+
+
+
+
+
+

@Override@Deprecated@Expose@SuppressWarnings("unused")@Incubating@Target({ FIELD, METHOD })++if(hoge){if(fuga){
continue;}if(hoge && fuga){continue;}

図 7 アノテーションの変更+

final ProductSourcePath path =(ProductSourcePath) ast.getProductSourcePath();//getProductSourcePath()はProductSourcePath型を返す
final ProductSourcePath path =ast.getProductSourcePath();

図 8 キャストの削除+

図 13 else if 文から if 文への書き換え+

if( hoge==null && fuga ){if( (hoge==null) && fuga ){+}図 10 括弧の挿入
+
+
+

+

if(hoge){return;}else if(fuga){if(fuga){if(!hoge || !fuga){if(!(hoge && fuga)){

図 9 条件式の書き換え+

図 12 if 文の連結

protected <T> T hoge() {Class<?> c;
T rv = (T) c.newInstance();Object rv = c.newInstance();......
return rv;
return (T) rv;

elsehoge();

図 14 総称型と Object 型

else {
hoge();+}Class<?> superclass = ((Class) element).getSuperclass();
Class<?> superclass = ((Class<?>) element).getSuperclass();

図 11 if 文のブロックの挿入

図 15 総称型のワイルドカードの挿入

存在した．
インターフェース中のメソッドの public 修飾子の削除

イン+

List<String> list = new ArrayList<String>();List<String> list = new ArrayList<>();

ターフェースでは，メソッドは暗黙的に public メドッドになるため，メソッド宣言において public 修飾子が取り除かれてもバイトコードが変化しない．

図 16 ダイヤモンド演算子の使用+

public final static int hoge = 0;
public static final int hoge = 0;

キャストの削除 例を図 8 に示す．キャストの挿入や削除によって，バイトコードが変わらない例が存在した．
空文の削除 セミコロンのみが記述された空文は命令を実行

図 17 修飾子の入れ替え+

char chars[] = new char[5];char[] chars = new char[5];しないため削除されてもバイトコードが変化しない．

図 18 配列宣言の変更

条件式の書き換え 例 を 図 9 に 示 す ．調 査 対 象 の Spring
Framework Core において変更が確認された．ド・モルガンの後の else if 文が if 文に変更されてもバイトコードは変化しな法則に従って OR 演算子を AND 演算子で書き換えた条件式

かった．

はバイトコードに変化を与えなかった．また，バイトコード

総称型と Object 型 例を図 14 に示す．コンパイル時に総称

中では OR 演算子を用いた記述に統一されていた．

型は Object 型としてコンパイルされるため，総称型を Object

括弧の挿入．削除 例を図 10 に示す．可読性の向上のため，型に書き換えてもバイトコードは変化しなかった．

括弧を用いて数式や条件式を括り出す変更や，括弧を取り除

総称型のワイルドカードの挿入削除

く変更が存在した．これらの括弧の挿入削除はバイトコード型のワイルドカードの挿入削除はバイトコードに変化を与えに変化を与えなかった．

なかった．

例を図 15 に示す．総称

if 文のブロックの挿入，削除 例を図 11 に示す．調査対象の

ダイヤモンド演算子 例を図 16 に示す．ダイヤモンド演算子

Spring Framework Core において変更が確認された．if 文およは Java 7 から導入された記述であり，インスタンス生成時にび else 文の後に 1 行で命令を記述する形式から，ブロックを型推論が行われるため，リスト宣言の右側のデータ型名の省略用いる記述への変更はバイトコードに変化を与えなかった．

が可能になる．ダイヤモンド演算子を導入してもバイトコー

if 文の連結 例を図 12 に示す．調査対象の Apache ant におドは変化しない．

いて変更が確認された．if 文の中で二重に if 文を記述する形

修飾子の入れ替え式から，二つの条件を AND 演算子で結合し，if 文を一つにま飾子を入れ替えてもバイトコードが変化しない例が存在した．

例を図 17 に示す．ﬁnal 修飾子と static 修

とめた記述への変更はバイトコードに変化を与えなかった．
else if 文から if 文への書き換え 例を図 13 に示す．調査対

配列宣言の変更 例を図 18 に示す．char 型修飾子と，char 型

象の Spring Framework Core において変更が確認された．直配列修飾子を入れ替えてもバイトコードが変化しない例が存

前の if 文の処理に return 文が記述されていたならば，その直

在した．

—5—

+

return hoge(XMLInputFactory::newFactory);
return hoge(XMLInputFactory::newInstance);

図 19
+
+

ない変更を，ソースコードが変更された際にバイトコードが変化しない変更とした．しかし，プログラムの振る舞いが保持され，ソースコードが変更された際にバイトコードが変化

newFactory, newInstance の書き換え

する変更が存在する．先行研究において本質的でない変更とhoge(list.size());
int size = list.size();hoge(size);

されていたクラス名，メソッド名の変更とそれにともなう参照箇所の変更や，一時変数の導入は，本研究の分類方法ではバ
イトコードが変化するため本質的な変更と分類されてしまう．

図 20 一時変数の導入

newFactory, newInstance の書き換え 例を図 19 に示す．

また，メソッドの移動についてもバイトコード中の命令の順

newFactory, newInstance は共に XMLInputFactory クラスの序が変わってしまうため，本研究の分類方法では本質的な変メソッドであり，どちらも新しいインスタンスを作成する処更と判定されてしまう．このように，バイトコードが変化す

理を行う命令として実装されているため，バイトコードが変るが，プログラムの振る舞いは保持される変更が存在する．

化しなかった．

8. あ と が き

呼び出しのないフィールド変数の初期化の変更 呼 び 出 し の行われないフィールド変数が初期化された場合には，バイトコードが変化しない．
6. 3

本研究では，バイトコードの変化の有無によって本質的な変更と本質的でない変更を分類する手法を提案し，調査を行っ先行研究では本質的でないが提案手法では本質的と定た．調査の結果，4 つの Java プロジェクトにおいて，Java義された変更ファイルの変更が行われたコミットのうち，8.9%∼22.3% の一時変数の導入 例を図 20 に示す．一時変数を導入し，後続

コミットは本質的でない変更のみで構成されていることを確のプログラムで式の代わりに一時変数を参照する変更はコー

認した．また，先行研究と比較し新たに 19 の変更が本質的でドの可読性を向上させる．しかし，先行研究では本質的ではない変更と定義された．

ない変更とされていたが，本研究では一時変数の作成はバイ

今後の課題としては，本質的でない変更のみがなされていトコードが変化してしまうため本質的な変更と判定された．

るコミットのテストを削減することで，テスト時間がどの程

名前の変更と参照箇所の変更 クラス名，フィールド名，メ

度短縮されるか推測を行うことや，先行研究と比較し新たに

ソッド名の変更は，それにともなう参照箇所の変更も引き起

本質的ではない変更とみなせる例が本論文で挙げた他に存在

こす．ローカル変数名や，パラメータ名，それにともなう参照

しないかの調査が挙げられる．
文

箇所の変更はバイトコードに変化を与えなかったが，クラス
名，フィールド名，メソッド名は，バイトコードが変化してし[1]

まうため本質的な変更と判定された．
6. 4

[2]

先行研究との差異

バイトコードの変化の有無で分類することにより先行研究に比べ，新たに本質的でないと定義された変更の割合を表 4に示す．すべての対象プロジェクトにおいて，先行研究と比[3]

較し新たに本質的でないと定義できる変更が存在した．さらに，アノテーションの変更や ﬁnal 修飾子の付与など新たに 19の変更が本質的でない変更と定義された．また，ﬁnal 修飾子の付与やアノテーションの変更が多く存在した kGenProg は，[4]

他のプロジェクトに比べ新たに本質的でないと定義された変更の割合が多くなっていた．対して，本質的でない変更のうち[5]

コメントやフォーマットの変更が大部分を占めた Apache ant
は新たに本質的でないと定義された変更の割合が低くなった．
[6]

7. 妥当性への脅威
本研究では本質的でない変更をプログラムの振る舞いを変

献M.J. Rochkind, “The source code control system,” IEEE
Transactions on Software Engineering, vol.SE-1, no.4,
pp.364–370, Dec. 1975.
T.L. Graves, A.F. Karr, J.S. Marron, and H. Siy, “Predicting
fault incidence using software change history,” IEEE Transactions on Software Engineering, vol.26, no.7, pp.653–661,
July 2000.
N. Nagappan and T. Ball, “Use of relative code churnmeasures to predict system defect density,” Proceedings ofthe 27th International Conference on Software Engineering,pp.284–292, ICSE ’05, ACM, New York, NY, USA, 2005.
http://doi.acm.org/10.1145/1062455.1062514
H. Gall, M. Jazayeri, and J. Krajewski, “Cvs release history data for detecting logical couplings,” Sixth International
Workshop on Principles of Software Evolution, 2003. Proceedings., pp.13–23, Sep. 2003.
A.T.T. Ying, G.C. Murphy, R. Ng, and M.C. Chu-Carroll,“Predicting source code changes by mining change history,”
IEEE Transactions on Software Engineering, vol.30, no.9,
pp.574–586, Sep. 2004.
D. Kawrykow and M.P. Robillard, “Non-essential changes
in version histories,” 2011 33rd International Conference on
Software Engineering (ICSE), pp.351–360, May 2011.

えない変更と定義した．また，プログラムの振る舞いを変え
表 4 新たに本質的ではない変更と定義された変更の割合
プロジェクト名 本質的でない変更の数

先行研究同様に本質的でないと新たに本質的でないと新たに本質的でないと定義された変更の数定義された変更の数定義された変更の割合

kGenProg

162

99

63

38.9%

Apache ant

77

61

16

20.8%

Spring Framework Core

229

166

63

27.5%

Hibernate ORM Core

129

94

35

27.1%

—6—