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

信学技報
TECHNICAL REPORT OF IEICE.

プルリクエスト型開発への統合を目的とした
コードクローン修正支援システムの提案
中川

将†

肥後

芳樹†

楠本

真二†

† 大阪大学大学院情報科学研究科
大阪府吹田市山田丘 1-5
E-mail: †{t-nakagw,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし コードクローン（クローン）はソフトウェアの保守作業を困難にする要因として知られている．そのため，
ソフトウェア保守においてクローンに対する修正作業が重要である．既存研究では，クローンに対する効率的な修正作業を支援するために，クローンの変更情報を開発者に通知するシステムを提案している．しかし，既存システムは定期的な実行を前提としており，時間以外の外的要因に起因して実行できるようには設計されていない．そのため，
既存システムはソースコード修正やブランチのマージといった開発作業に合わせた実行が容易ではない．そこで本研
究では，この問題を解決するために，プルリクエスト（PR）型開発への統合を目的としたコードクローン修正支援シ
ステムを提案する．提案手法では，PR の作成時にクローンを追跡し，それらに行われた変更を分類することで，修正作業が必要なコード片を検出する．また，既存システムと比較してより正確にクローンの変更を検出できるように，
既存のクローン追跡方法に三つの改善を加えた．提案システムを評価するために，三つの OSS に対してクローンが同時修正されなかった PR の割合の調査及び提案システムと既存システムのクローン追跡結果の比較を行った．結果として，11.9% ∼ 30.4% の PR でクローンが同時に修正されていないことから，PR 型開発におけるクローンの修正支援に提案システムが有用であることが分かった．また，提案システムは既存システムと比較してより正確にクローンを追跡できることを確認した．
キーワード コードクローン，ソフトウェア保守，プルリクエスト型開発

1. は じ め に•一つ目の課題点は，ソースコードの変更などで修正対象のコード片が発生しても，すぐには通知されない点である．

コードクローン（以降，クローン）とはソースコード中に存

Clone Notiﬁer は定期実行されるため，一度実行されると次の実在する他のコード片と一致もしくは類似しているコード片を指行までに一日の間隔が開いてしまう．一方，この課題を解決す

す．クローンはソフトウェア開発の保守作業における問題の一るために実行間隔を短く設定した場合，ソースコードの変更がつとして指摘されている [1]．例えば，あるコード片にバグが行われていなくても頻繁にクローンの情報が開発者に通知され存在した場合，そのコード片のクローンにも同様のバグが存在るため，開発者の負担になる可能性がある．開発作業に合わせする可能性があるため，修正を検討しなければならない．そのたクローンの変更情報の通知が可能になると，ソースコードのため，クローンの同時修正支援やリファクタリング支援に関す変更などに合わせて修正すべきコード片が開発者に通知される

る研究が活発に行われている [2], [3]．

ため，開発者はそれらに対して迅速に対応できると考えられる．

これらの作業を効率化するために，既存研究ではクローン変•

二つ目の課題点は，開発者に対して一度に大量の通知が更管理システム Clone Notiﬁer を提案している [4]．Clone Notiﬁer

行われる可能性がある点である．Clone Notiﬁer のある実行と次は対象プロジェクトの二つのリビジョンを入力とし，そのリビの実行の間にソースコードが大量に変更され，多くのクローン

ジョン間で行われたクローンの変更情報を開発者に通知する．

が不適切に変更された結果，修正対象のコード片が大量に発生

Clone Notiﬁer は企業での利用を対象に設計されており [5]，一日した場合を考える．この場合，修正対象のコード片は，Clone

一回の定期実行を前提としている．一方，Clone Notiﬁer は時間

Notiﬁer の次の実行時に一度に通知される．したがって，開発者

以外の外的要因に起因して実行できるように設計されていない

は一度に大量の出力結果を確認しなければならず，見落としがため，ソースコードの修正やブランチのマージといった開発作

発生する可能性がある．開発作業に合わせたクローンの変更情業に合わせた実行が容易ではない．そのため，OSS 開発のよう報の通知が可能になると，大量のソースコード変更に合わせてな頻繁にソースコードの修正やブランチのマージが行われる開それぞれの変更が行われる度に修正対象のコード片が通知され発において Clone Notiﬁer の利用を考えた場合，以下のような課るため，開発者は修正対象のコード片の見落としを防げると考題があると著者らは考えた．

えられる．

—1—

•

三つ目の課題点は，バージョンコントロールシステム（以降，VCS）を用いた開発において，修正対象のコード片が主
流ブランチに入り込んでしまう可能性がある点である．このような開発では，主流ブランチはバグがなく，いつでもリリースできる状態が理想とされる．そのため，派生ブランチのマージ前に，バグを含んでいる可能性がある修正対象のコード片が存在しないか確認すべきである．しかし，Clone Notiﬁer は定期実行を前提としているため，ブランチのマージ前での修正対象のコード片の検出は難しい．開発作業に合わせたクローン変更情報の通知が可能になると，派生ブランチのマージ前に修正対象のコード片を検出できるため，バグが主流ブランチに入り込む可能性を減らせると考えられる．
そこで本研究では，このような課題を解決するために，開発作業への統合を目的としたクローン修正支援システム CLIONE を

core/src/main/java/org/jruby/RubyArray.java
private IRubyObject all_pBlockless(ThreadContext context) {for (int i = 0; i < realLength; i++) {if (!eltOk(i).isTrue()) return context.runtime.getFalse();}return context.runtime.getTrue();}- private IRubyObject any_pBlockless(ThreadContext context) {for (int i = 0; i < realLength; i++) {if (eltOk(i).isTrue()) return context.runtime.getTrue();}return context.runtime.getFalse();- }+ private IRubyObject any_pBlockless(ThreadContext context, IRubyObject[] args) {+IRubyObject pattern = args.length > 0 ? args[0] : null;+
if (pattern == null) {+for (int i = 0; i < realLength; i++) {+if (eltOk(i).isTrue()) return context.runtime.getTrue();+}+} else {+for (int i = 0; i < realLength; i++) {+if (pattern.callMethod(context, "===", eltOk(i)).isTrue())+
return context.runtime.getTrue();
+
}
+
}
+
+
return context.runtime.getFalse();+ }図 1: JRuby の二つのメソッド提案する．CLIONE はプルリクエスト（以降，PR）型開発への統合により，PR の作成毎にクローンの追跡を行い，クローンに行われた変更を分類することで修正対象のコード片を検出し，開発者に通知する．また，Clone Notiﬁer と比較してより正確なクローン追跡のために，Clone Notiﬁer のクローン追跡方法に三つの改善を加えた．現在，CLIONE は https://github.com/T45K/CLIONEにて公開している．
CLIONE の有用性を評価する実験として，三つの OSS に対して，CLIONE が開発者に通知する対象である，クローンが同時に修正されなかった PR の割合の調査と，CLIONE と Clone Notiﬁerのクローン追跡結果の比較を行なった．実験の結果，11.9% ∼30.4% の PR においてクローンが同時に修正されていないことから，開発者がそのような修正をブランチのマージ前に確認することに対して CLIONE が有用であることが分かった．また，Clone Notiﬁer と比較して，CLIONE はより正確にクローンを追跡できることを確認した．

2. 研 究 動 機
JRuby の二つのメソッドを図 1 に示す．この二つのメソッド
は互いにクローンとなっており，PR#50961 で両方のメソッドが同時に修正されるべきところを，any_pBlockless メソッドのみが修正された．その結果，Enumerable#all メソッドを引数付きで呼び出すとエラーが発生するバグが作り込まれた．開発者はこのバグに気付かないままこの修正を master ブランチにマージ
してしまい，バージョン 9.2.0.0 としてリリースしてしまった．
このバグは約三ヶ月後，PR#52982 にて修正された．
もし開発者が CLIONE を利用していれば，ブランチのマージ
前にこの非同時修正を検出できたため，このバグの master ブラ
ンチへの混入を防げたと考えられる．VCS を用いた開発では，

master ブランチは常にバグがない状態が理想なので，master ブ
ランチをバグがない状態に保つために開発作業へ統合可能なク
ローン修正支援が必要である．

3. 準

備

3. 1 コードクローン
クローンとは，ソースコード中の他のコード片と一致または類似しているコード片を指す．全てのコード片の組が一致または類似しているコード片の集合はクローンセットと呼ばれる．
クローンは，一般的にその類似度に基づいて以下の三種類に分類される．

Type-1 空白やコメントを除いて完全に一致するクローン
Type-2 変数名や関数名などが異なるクローン
Type-3 文の追加，削除や変更が行われたクローン
これまでに数多くのクローン検出手法が提案されている [6]．
本研究と関連する二つのクローン検出手法について説明する．
テキストベースの検出手法
テキストベースのクローン検出手法では，初めに変数の正規化やソースコードの整形といった一定のルールに従ってソース
コードを変形し，変形されたソースコード中のメソッドやブ
ロックといったコード片の比較によりクローンを検出する．代
表的なツールとして NiCad [7] が挙げられる．NiCad は TXL [8]を用いてソースコードの整形を行い，最長共通部分列検出アル
ゴリズムを用いて Type-3 クローンを検出する．
トークンベースの検出手法
トークンベースのクローン検出手法では，初めにソースコー
ドに対して字句解析を行い，得られた字句情報を用いてクローンを検出する．代表的なツールとして，CCFinder [9] とSourcererCC [10] が挙げられる．CCFinder は字句列の比較により Type-2 クローンを検出する．SourcererCC はトークンの種類
やその出現回数の類似度から Type-3 クローンを検出する．

3. 2 Clone Notiﬁer
Tokui らは開発者に対するクローン修正支援のために Clone
Notiﬁer を開発した [4]．Clone Notiﬁer は対象プロジェクトの二

つのリビジョンを入力として受け取り，そのリビジョン間で行われたソースコード変更に基づいてクローンセットを Stable，（注 1）：https://github.com/jruby/jruby/pull/5096

New，Deleted，Changed の四種類に分類する．

（注 2）：https://github.com/jruby/jruby/pull/5298—2—

旧リビジョン

新リビジョン…
11 void main() {12 int a = 0;
13 long b = 0;
14 String c = "";
15 }
…

…
11 void main() {12 int a = 0;
13 long d = 1;
14 String b = "";15 char e = '';16 }…

𝑜! = 11𝑜" = 15 − 1 = 14

GitHub

開発者

7. 結果の通知
2. PR作成
1. 登録

3. git-clone

プロジェクト6. コメント

クローンセット

修正対象の
コード⽚

4. 先頭コミットからクローン検出𝑛! = 11𝑛" = 16 − 2 = 14

クローンセット

図 2: クローン追跡の例
CLIONE

4. 分岐コミットからクローン検出5. クローンの追跡
分類

図 3: CLIONE の概要

Clone Notiﬁer は，初めに既存のクローン検出器 [9]〜[11] を用いて対象プロジェクトの各リビジョンからクローンを検出する．次に，既存研究 [12] で提案された位置重複関数を用いて検出されたクローンを追跡し対応づける．

4. 提案システム: CLIONE

位置重複関数とは，二つのコード片がどの程度位置的に重複し本研究では，開発作業への統合を目的としたクローン修正支ているかを計算する関数である．Clone Notiﬁer は対象の二つの援システム CLIONE を提案する．CLIONE は，PR の作成時にクリビジョンで同名ファイル中のクローンに対して位置重複関数

ローンを追跡し，クローンに行われた変更を分類することで修を計算する．旧リビジョンから検出されたクローンを 𝑐1，新リ

正対象のコード片を検出する．CLIONE はサーバサイドアプリ

ビジョンから検出されたクローンを 𝑐2 とした時，位置重複関数

ケーションとして実装されており，PR 作成時に GitHub から送𝐿𝑂 (𝑐1, 𝑐2) の計算式は以下の通りである（0 ≤ 𝐿𝑂 (𝑐1, 𝑐2) ≤ 1）．

信される HTTP リクエストを受け取る．

𝑚𝑖𝑛(𝑛𝑒 , 𝑜 𝑒 ) − 𝑚𝑎𝑥(𝑛𝑠 , 𝑜 𝑠 )𝐿𝑂 (𝑐1, 𝑐2) =𝑛𝑒 − 𝑛 𝑠(1)

4. 1 CLIONE の概要
CLIONE の概要を図 3 に示す．初めに，CLIONE を利用したい

ここで，𝑜 𝑠 と 𝑜 𝑒 はそれぞれ 𝑐1 での削除行を除いた開始行，終開発者は，CLIONE に対して自身の GitHub アカウントとリポジ了行を表し，𝑛 𝑠 と 𝑛𝑒 はそれぞれ 𝑐2 での追加行を除いた開始

トリを登録する．この登録以降，開発者が PR を作成する度に行，終了行を表す．𝑐1 と 𝑐2 に対する位置重複関数の計算結果

GitHub から CLIONE に HTTP リクエストが送信され CLIONEが 0.3 以上となった場合，Clone Notiﬁer はその二つのクローンが実行される．CLIONE は作成された PR の先頭コミットと，こを変更前後での対応するクローンとして追跡する．

の PR のブランチの分岐元となったコミット（以降，分岐コミッ

クローン追跡の例を図 2 に示す．図では，旧リビジョンと新ト）間のクローンを追跡する．

リビジョンの main メソッドを追跡している．main メソッドは，開発者が PR を作成すると，CLIONE は対象プロジェクトを

旧リビジョンでは 1 行の削除，新リビジョンでは 2 行の追加がローカル環境に git-clone する．次に，先頭コミットと分岐コ

行われている．削除，追加行を除くと，各リビジョンの main メ

ミットそれぞれからクローンを検出する．クローン検出には，ソッドの開始行，終了行はそれぞれ 𝑜 𝑠 = 11，𝑜 𝑒 = 15 − 1 = 14，

既存のクローン検出器である NiCad [7] と SourcererCC [10] を

𝑛𝑠 = 11，𝑛𝑒 = 16 − 2 = 14 となる．したがって，位置重複関数利用できる．これらのクローン検出器を選択した理由は，どちの計算結果は 1 となるため，このメソッドは追跡される．

らも高精度で Type-3 クローンを検出できるからである．

最後に，クローンの追跡結果に基づき各クローンセットを分

それぞれのコミットでのクローン検出が完了すると，CLIONE

類する．また，Clone Notiﬁer は対象プロジェクトに対して一日は次にその PR の先頭コミットと分岐コミット間でのクローン

一回の定期実行を想定して開発されている．

の追跡を行う．CLIONE では，Clone Notiﬁer と同様に，既存研

3. 3 プルリクエスト型開発

究 [12] で提案された位置重複関数を用いて二コミット間のクPR 型開発とは，GitHub の機能の一つである PR を用いて行

ローンを追跡する．

われる開発手法を指す．PR とは，あるブランチを他のブランクローンの追跡を行った後に，クローンに行われた変更から，

チにマージする前に，ソースコードの変更などの開発情報を他

修正対象のコード片として非同時修正クローンセットとリファの開発者に通知する機能である．PR 型開発では，開発者は主クタリング対象クローンセットを検出する．具体的には，変更

流ブランチではなく派生ブランチ上で作業を行う．作業が完了されたクローンと変更されなかったクローンが含まれているク

すると，開発者は PR を作成し変更内容を他の開発者に通知す

ローンセットを非同時修正，全てまたは一部のクローンが新しる．変更内容に問題がなければ，その派生ブランチは主流ブラく追加されたクローンセットをリファクタリング対象として扱

ンチにマージされる．

う．また，Clone Notiﬁer と比較してより正確にクローンの変更

PR 型開発は OSS 開発で広く採用されている [13]．また，既を検出できるように，CLIONE では Clone Notiﬁer のクローン追存のソースコード解析技術を PR 型開発に統合することでソフ

跡方法に三つの改善を加えている．詳細については 4. 2 にて述

トウェア開発を効率化する研究が行われている [14], [15]．

べる．

—3—

1 void main1() {2 int a = 0;
3 String b = "";4 }5
6 void main2() {7 int c = 0;
8 String d = "";9 }1 void main1() {2
int a = 0;
3
int c = 1;
4
String b = "";5 }6
7 void main2() {8
int c = 0;9String d = "";10 }分岐コミット

先頭コミット(a) クローンのみの追跡
1 void main1() {2 int a = 0;
3 String b = "";4 }5
6 void main2() {7 int c = 0;
8 String d = "";9 }1 void main1() {2
int a = 0;
3
int c = 1;
4
String b = "";5 }6
7 void main2() {8
int c = 0;9String d = "";10 }分岐コミット

先頭コミット(b) コード片の追跡
1 void main1() {2 int a = 0;
3 String b = "";4 }5
6 void main2() {7 int c = 0;
8 String d = "";9 }1 void main1() {2
int a = 0;
3
int c = 1;
4
String b = "";5 }6
7 void main2() {8
int c = 0;9String d = "";10 }分岐コミット

先頭コミット(c) 正確なクローンの追跡

図 5: クローン追跡の改善

4. 2 クローン追跡方法の改善
CLIONE では，Clone Notiﬁer のクローン追跡方法に一つの手法的改善，二つの実装的改善，計三つの改善を加えた．
図 4: 非同時修正クローンセットに対するコメントの例（ 1 ） コード片の追跡（ 2 ） ファイル名の変更検出（ 3 ） 字句列比較によるクローンの変更判定

最後に，CLIONE は修正対象のコード片を PR へのコメントの

コード片の追跡形式で開発者に通知する．非同時修正クローンセットの場合，

手法的な改善として，クローンではなく，コード片の追跡を行変更されたコード片と変更されなかったコード片が表示される．

うようにした．Clone Notiﬁer はクローンとして検出されたコー

リファクタリング対象クローンセットの場合，クローンセット

ド片を追跡の対象として扱う．そのため，あるコード片が片方に含まれる全てのコード片が表示される．非同時修正クローンのコミットではクローンとして検出され，もう片方のコミット

セットに対するコメントの例を図 4 に示す．図では，一番上にでクローンとして検出されなければ，Clone Notiﬁer はそのコー変更されたコード片の変更箇所が diﬀ 形式で表示され，真ん中ド片を追加あるいは削除されたと判定する．一方，クローンとに変更されたコード片全体が，その下に変更されていないコー

なっているコード片の片方に変更が加えられた結果，変更前はド片が表示される．PR へのコメントとして修正対象のコード

クローンとして検出されても，変更後は検出されなくなる場

片を通知することで，開発者に対して迅速なフィードバックが合がある．例として，図 5(a) のように，分岐コミットではク可能になる．

ローンだったメソッドの片方に変更が加えられた結果，先頭コ
ミットではクローンとして検出されなくなった場合を考える．

—4—

この場合，先頭コミットでクローンが検出されなくなったた
め，Clone Notiﬁer はこの二つのメソッドから構成されるクロー

5. 評 価 実 験

ンセットが削除されたと分類する．しかし，実際には main1 メ

CLIONE を評価するために，以下の二つの実験を行なった．

ソッドにのみ変更が加えられているため，この変更は非同時修

実正と分類されるべきである．

験1

実験 1 では，CLIONE が開発者に対して通知する対象である，

一方，CLIONE はクローンだけでなく，メソッドやブロック

クローンが同時に修正されなかった PR（以降，非同時修正 PR）

といったコード片も追跡の対象とする．そのため，片方のコの割合を調査した．この実験では，対象プロジェクトの PR に

ミットでクローンが検出されなくても，クローンだったコード

対して CLIONE を手動で実行し，各 PR 間でクローンが同時修

片さえ残っていればそのコード片を追跡できる．コード片の追

正されているかを確認した．

跡の例を図 5(b) に示す．この例では，CLIONE はメソッド自体

実

験

2

の追跡を行っている．したがって，メソッド自体の追跡結果か実験 2 では，CLIONE と Clone Notiﬁer のクローン追跡結果をら分岐コミットでクローンとなっているコード片を追跡できる

比較した．この実験では，対象プロジェクトの PR に対して

（図 5(c)）．結果として，CLIONE はコード片の追跡を行うこと

CLIONE と Clone Notiﬁer を実行し，クローンの追跡結果を目視で，このクローンを非同時修正と正しく分類できる．

で確認し，結果が異なる PR の個数を数えた．

ファイル名の変更検出

5. 1 実 験 対 象

実装的な改善として，ファイル名の変更を検出できるように

本研究では，三つの OSS を実験対象として選択した．表 1 にした．Clone Notiﬁer では，入力として受け取る二つのリビジョ

実験対象の OSS の名前，2020 年 7 月 20 日時点での総 PR 数，

ンにおいて，同名のファイル中に存在するクローンを追跡の対少なくとも 1 つの Java ファイルが変更された PR（以降，対象象とする．一方，ソフトウェア開発や保守において，ファイル

PR）数を示す．これらの OSS を実験対象として選んだ理由は，

名の変更はたびたび行われる．リビジョン間でファイル名が変クローンの研究において実験対象になることが多く [16]〜[18]，

更された場合，Clone Notiﬁer は旧リビジョンでファイルが削除

かつプルリクエスト型開発が行われているからである．

され，新リビジョンでファイルが追加されたと判定する．その5. 2 実験 1 の結果

ため，Clone Notiﬁer はファイル名が変更された場合，ファイル

実験 1 の結果を表 2 に示す．表から，全ての対象プロジェクの中身に変更がなくても，旧リビジョンでそのファイル中のクトにおいてクローンが同時に修正されなかった PR（以降，非ローンが削除され，新リビジョンでクローンが追加されたと同時修正 PR）が存在しており，その割合は 11.9% ∼ 30.4% で誤って分類してしまう．

あることが分かる．これらの非同時修正には 2. で紹介したよう

一方，CLIONE は Git のリネーム検出機能を用いることで，に，実際にバグが発生する場合もある．そのため，ブランチのファイル名の変更があった場合でも，そのファイルの内容の類

マージ前に開発者は非同時修正クローンを確認し，修正の必要

似度からファイルの追跡を行える．結果として，そのファイル性を判断することが重要である．仮にこれらのプロジェクトの中のコード片を追跡できるため，クローンの誤分類を減らせる．

開発者が CLIONE を利用していた場合，PR 作成毎に非同時修字句列比較によるコード片の変更判定

正クローンが通知されるため，非同時修正クローンに容易に対実装的な改善として，字句列の比較によりコード片が変更

応できる．以上から，CLIONE は PR 型開発におけるクローン

されたかどうかを判定するようにした．Clone Notiﬁer では，ク
ローンであるコード片内に対象のリビジョン間で追加あるいはの修正支援に有用であると考えられる．

5. 3 実験 2 の結果削除された行がある場合，そのクローンは変更されたと判定さ

CLIONE と Clone Notiﬁer のクローン追跡結果を比較した結果，れる．一方，この判定方法では，フォーマットやコメントの変合計 44 個，非同時修正 PR の 34% において，4. 2 で述べたク更といったプログラムに振る舞いを与えない変更であってもクローン追跡方法の改善によってクローン追跡結果が異なった．

ローンが変更されたと判定される．特にフォーマットの変更は，
表 1: 対象 OSS

変更がソースコード全体の広範囲に及ぶことがあるため，大量のクローンが変更されたと判定される場合がある．そのため，

名前

追加あるいは削除行の有無でクローンが変更されたかを判定す

jruby/jruby

2,248

292

ると，プログラムの振る舞いには影響を与えない変更であって

junit-team/junit4

848

236

google/gson

317

69

も，大量に変更情報が通知される場合があるため，開発者の確# 総 PR # 対象 PR

認に対して負担になる可能性がある．
表 2: 実験 1 の結果

一方，CLIONE は追跡したコード片を字句列に変換し，その字句列の比較によりコード片が変更されたかを判定する．したがって，フォーマットやコメントの変更といった振る舞いに影響を与えない変更を無視した上で，クローンが変更されたかを判定できる．これにより，開発者に対して確認する必要性が低

名前# 対象 PR # 非同時修正 PR

割合

jruby/jruby

292

89 30.4%

junit-team/junit4

236

28 11.9%

google/gson60

10 16.7%

合計588

127 21.5%

いクローンの変更を通知しないようにできる．

—5—

著者らが判断した限り，異なる追跡結果全てにおいて CLIONE検出のみでなく，そのコード片の修正方法を推薦できれば，よが正しかった．クローンの追跡結果が異なる要因となった改善

り有用なシステムになると考えられる．CLIONE に対するその方法の内訳を表 3 に示す．表 3 から，コード片の追跡によりクような機能の実装も今後の重要な課題である．

ローンの追跡結果が異なった PR の数が最も多いことが分かる．

謝辞

本研究は，日本学術振興科学研究費補助金基盤研究

一方，ファイル名の変更検出や字句列比較によるコード片の変（B）（課題番号:20H04166）の助成を得て行われた．

更判定は，追跡結果が改善した PR の数自体は少ない．しかし，

文

追跡結果が改善した PR において，ファイル名変更やフォーマッ
ト変更により Clone Notiﬁer が大量のクローンの変更を誤分類したのに対して，CLIONE は正しく分類できた．つまり，これらの改善は，改善した PR の個数は少ないが，その PR において確認する必要がないと考えられる大量のクローンの追跡結果を開発者に通知しないため，開発者の負担を大きく軽減できると考えられる．
したがって，この三つの改善により，CLIONE は Clone Notiﬁerに比べてより正確にクローンを追跡できるため，開発者により有益なクローン変更情報を提供できると考えられる．

6. お わ り に本研究では，PR 型開発への統合を目的としたクローン修正
支援システム CLIONE を提案した．提案手法では，PR の作成時にその PR の先頭コミットと派生コミット間でのクローン変
更により発生した修正対象のコード片を検出する．また，より正確にクローンを追跡するために，Clone Notiﬁer が利用しているクローンの追跡方法に三つの改善を行った．評価実験として，非同時修正 PR の割合調査と，CLIONE と Clone Notiﬁer のクローンの追跡及び変更分類結果の比較を行った．実験結果から，11.9% ∼ 30.4% の PR においてクローンが同時に修正されていないことから，CLIONE が PR 型開発におけるクローンの修正支援に有用であることが分かった．また，CLIONE は Clone
Notiﬁer と比較してより正確にクローンを追跡できることを確認した．
今後は以下の課題に取り組む予定である．
被験者実験
本研究では，二つの実験から CLIONE の有用性を評価した．
一方，CLIONE が開発者に対して実際に有用かどうかの評価を行なえていない．また，著者らは 1. にて，開発作業に合わせて修正対象のコード片を開発者に通知することで見落としを防げると主張しているが，実際に開発者の見落としに効果があるのかの評価も必要である．CLIONE を実開発に適用し，開発者に対する有用性を評価する実験は今後の重要な課題である．
修正方法の推薦
現在 CLIONE は，クローンの追跡によって修正対象のコード片を検出し，それらを開発者に通知するのみに止まっている．
表 3: 改善方法の内訳
改善方法# 追跡結果が異なった PR

コード片の追跡35

ファイル名の変更検出

3

字句列比較によるコード片の変更判定

6

合計

44

献

[1] M. Mondal, C.K. Roy, and K.A. Schneider, “Bug propagation throughcode cloning: An empirical study,” International Conference on Software Maintenance and Evolution, pp.227–237, 2017.
[2] Y. Higo, Y. Ueda, S. Kusumoto, and K. Inoue, “Simultaneous Modiﬁcation Support based on Code Clone Analysis,” Asia-Paciﬁc Software
Engineering Conference, pp.262–269, 2007.
[3] Y. Higo, T. Kamiya, S. Kusumoto, and K. Inoue, “Refactoring Support
Based on Code Clone Analysis,” Product Focused Software Process
Improvement, pp.220–233, 2004.
[4] S. Tokui, N. Yoshida, E. Choi, and K. Inoue, “Clone Notiﬁer: Developing and Improving the System to Notify Changes of CodeClones,” International Conference on Software Analysis, Evolution
and Reengineering, pp.642–646, 2020.
[5] Y. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T. Sano, “Applying
clone change notiﬁcation system into an industrial development process,” International Conference on Program Comprehension, pp.199–
206, 2013.
[6] A. Sheneamer and J.K. Kalita, “A Survey of Software Clone Detection Techniques,” International Journal of Computer Applications,pp.1–21, 2016.
[7] J.R. Cordy and C.K. Roy, “The NiCad Clone Detector,” International
Conference on Program Comprehension, pp.219–220, 2011.
[8] J. Cordy, “The TXL source transformation language,” Science ofComputer Programming, vol.61, pp.190–210, 08 2006.
[9] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: a multilinguistic token-based code clone detection system for large scale source
code,” Transactions on Software Engineering, vol.28, no.7, pp.654–
670, 2002.
[10] H. Sajnani, V. Saini, J. Svajlenko, C.K. Roy, and C.V. Lopes, “SourcererCC: Scaling Code Clone Detection to Big-Code,” International
Conference on Software Engineering, pp.1157–1168, 2016.
[11] K. Yokoi, E. Choi, N. Yoshida, and K. Inoue, “Investigating VectorBased Detection of Code Clones Using BigCloneBench,” Asia-Paciﬁc
Software Engineering Conference, pp.699–700, 2018.
[12] M. Kim, V. Sazawal, D. Notkin, and G. Murphy, “An Empirical Studyof Code Clone Genealogies,” International Symposium on Foundations of Software Engineering, p.187–196, 2005.
[13] Y. Yu, H. Wang, V. Filkov, P. Devanbu, and B. Vasilescu, “Wait for
It: Determinants of Pull Request Evaluation Latency on GitHub,”Working Conference on Mining Software Repositories, pp.367–371,
2015.
[14] V. Alizadeh, M.A. Ouali, M. Kessentini, and M. Chater, “RefBot:
Intelligent Software Refactoring Bot,” International Conference on
Automated Software Engineering, pp.823–834, 2019.
[15] A. Carvalho, W. Luz, D. Marcílio, R. Bonifácio, G. Pinto, and E. Dias
Canedo, “C-3PR: A Bot for Fixing Static Analysis Violations via Pull
Requests,” International Conference on Software Analysis, Evolution
and Reengineering, pp.161–171, 2020.
[16] T. Nakagawa, Y. Higo, J. Matsumoto, and S. Kusumoto, “How Compact Will My System Be? A Fully-Automated Way to Calculate LoC
Reduced by Clone Refactoring,” Asia-Paciﬁc Software Engineering
Conference, pp.284–291, 2019.
[17] C. Ragkhitwetsagul and J. Krinke, “Using compilation/decompilation
to enhance clone detection,” International Workshop on Software
Clones, pp.1–7, 2017.
[18] K. Uemura, A. Mori, E. Choi, and H. Iida, “Tracking method-levelclones and a case study,” International Workshop on Software Clones,
pp.27–33, 2019.

—6—