論文

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

将† a)

肥後 芳樹† b)

楠本

真二† c)

CLIONE: Code Clone Modification Support System
Aimed to Integrate into Pull Request Based Development∗
Tasuku NAKAGAWA† a) , Yoshiki HIGO† b) , and Shinji KUSUMOTO† c)

あらまし コードクローン（クローン）はソフトウェアの保守作業を困難にする要因として知られている．そのため，ソフトウェア保守においてクローンに対する修正作業が重要である．既存研究では，クローンに対する効率的な修正作業を支援するために，クローンの変更情報を開発者に通知するシステムを提案している．しかし，既存システムは定期的な実行を前提としており，時間以外の外的要因に起因して実行できるようには設計されていない．そのため，既存システムはソースコード修正やブランチのマージといった開発作業に合わせた実行が容易ではない．そこで本研究では，この問題を解決するために，プルリクエスト（PR）型開発への統合を目的としたコードクローン修正支援システム CLIONE を提案する．CLIONE は，PR の作成時にクローンを自動で対応付け，それらに行われた変更を分類することで，修正作業が必要なコード片を検出する．そして，四つの実験から
CLIONE の有用性を評価した．
キーワード

コードクローン，ソフトウェア保守，プルリクエスト型開発，GitHub

バージョンを入力とし，そのバージョン間で変更され

1. ま え が きたクローンの情報を開発者に通知する．Clone Notifier

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

は企業での利用を対象に設計されており [5]，一日一回中に存在する他のコード片と一致若しくは類似していの定期実行を前提としている．一方，Clone Notifier はるコード片を指す．クローンはソフトウェア開発の保時間以外の外的要因に起因して実行できるようには設守作業における問題の一つとして指摘されている [1]．

計されていないため，ソースコードの修正やブランチ

例えば，あるコード片にバグが存在した場合，そのコーのマージといった開発作業に合わせた実行が容易ではド片のクローンにも同様のバグが存在する可能性があない．そのため，OSS 開発 [6] のような，頻繁にソーるため，修正を検討しなければならない．そのため，スコードの修正やブランチのマージが行われる開発にクローンの同時修正支援や集約支援に関する研究が活おいて Clone Notifier を利用する際，以下のような課発に行われている [2], [3]．

題があると著者らは考えた．

これらの作業を効率化するために，既存研究では•一つ目の課題点は，ソースコードを変更した結クローン変更管理システム Clone Notifier を提案して果コード片に修正が必要になっても，すぐには通知さいる [4]．Clone Notifier は対象プロジェクトの二つのれない点である．Clone Notifier は定期実行されるため，一度実行されると次の実行までに一日の間隔が開† 大阪大学，吹田市

Osaka University, Suita-shi, 565–0871 Japana) E-mail: t-nakagw@ist.osaka-u.ac.jpb) E-mail: higo@ist.osaka-u.ac.jpc) E-mail: kusumoto@ist.osaka-u.ac.jp* 本論文は，システム開発論文である．
DOI:10.14923/transinfj.2020JDP7071

690

電子情報通信学会論文誌 D Vol. J104–D

いてしまう．この課題を解決するために実行間隔を短く設定した場合，ソースコードの変更が行われていな
くても頻繁にクローンの情報が開発者に通知されるため，開発者が煩わしく感じる可能性がある．ソース
コードの変更に合わせて修正すべきコード片が開発者
No. 9 pp. 690–701 © 一般社団法人電子情報通信学会 2021

論文／プルリクエスト型開発への統合を目的としたコードクローン修正支援システム CLIONEに通知されることにより，そのような煩わしさがなく行った．実験結果から，Java ファイルが変更された

なるとともに迅速に修正対象のコード片に対応できる．

PR の 16.3% においてクローンの同時修正が行われて二つ目の課題点は，開発者に対して一度に大量のいないことから，PR 型開発において CLIONE が有用•

通知が行われる可能性がある点である．Clone Notifierであることが分かった．次に，CLIONE の実行時間はのある実行と次の実行の間にソースコードが大量に変CI ツールと比較して短かったことから，PR 型開発へ更され，多くのクローンが不適切に変更された結果，CLIONE を導入する際の障壁は低いことを示した．加大量のコード片に修正が必要になった場合を考える．

えて，CLIONE を用いた開発者に対する修正の提示及

この場合，修正対象のコード片は全て一度に通知され

び CLIONE の通知に対する開発者のアンケート結果

る．したがって，開発者は一度に大量の出力結果を確から，CLIONE の開発者に対する有用性を確認した．

認しなければならない．開発作業に合わせたクローンの変更情報の通知が可能になると，ソースコードが変更されるたびに修正対象のコード片が通知される．

2. 研 究 動 機
JRuby の二つのメソッドを図 1 に示す．この二つ三つ目の課題点は，版管理システム（以降，VCS）のメソッドは互いにクローンであり，PR#5096（注 2）でを用いた開発において，修正対象のコード片が主流ブ両方のメソッドが同時に修正されるべきところを，ランチに入り込んでしまう点である．VCS を用いた

any_pBlockless メソッド（図 1 (a)）のみが修正された．

開発では，主流ブランチではバグが発生しておらず，

その結果，all_pBlockless メソッド（図 1 (b)）を JRuby

いつでもリリースできる状態が理想とされる．そのた内で呼び出す Ruby の API を実行するとエラーが発生

め，派生ブランチのマージ前に，バグを含んでいる可するバグが作り込まれた．開発者はこのバグに気付か能性がある修正対象のコード片の有無を確認すべきでないままこの修正を主流ブランチにマージしてしまい，ある．しかし，Clone Notifier は定期実行を前提としてバージョン 9.2.0.0 としてリリースしてしまった．こいるため，ブランチのマージ前に修正対象のコード片のバグは約三ヶ月後，PR#5298（注 3）にて修正された．

を検出することは難しい．開発作業に合わせたクロー

もし開発者が CLIONE を利用していれば，ブラン•ンの変更情報の通知により，派生ブランチのマージ前チのマージ前にこの同時に修正されなかったクローンに修正対象のコード片を検出できるため，バグが主流（以降，非同時修正クローン）を検出できたため，このブランチに入り込む可能性を減らすことができる．

バグの主流ブランチへの混入を防げたと考えられる．

そこで本研究では，このような課題を解決するために，開発作業の一環であるプルリクエスト（以降，PR）に着目し，PR 型開発への統合を目的としたクローン
修正支援手法を提案する（注 1）．提案手法は PR の作成
ごとに自動でクローンの対応付けを行い，クローンに行われた変更を分類することで修正対象のコード片を検出し，開発者に通知する．なお，本研究では，提案手法が検出した修正対象のコード片が実際に修正を必要とするかはその開発者が判断することを想定している．つまり，提案手法は修正が必要と考えられるコー
ド片をなるべく漏れなく開発者に通知するという形でクローン修正支援を行う．本研究では，提案手法を Git
リポジトリホスティングサービスの一つである GitHub
向けシステム CLIONE として実装した．CLIONE はhttps://github.com/T45K/CLIONE にて公開している．
CLIONE の有用性を評価するために，四つの実験を（注 1）：本論文は，著者らの論文 [7] に対し追加の実験を行い，フルペー
パーとしてまとめた論文である．

図 1 JRuby の二つのメソッド
Fig. 1 Two methods in JRuby.
（注 2）：https://github.com/jruby/jruby/pull/5096（注 3）：https://github.com/jruby/jruby/pull/5298691

電子情報通信学会論文誌 2021/9 Vol. J104–D No. 9

VCS を用いた開発では，主流ブランチは常にバグがな

New 全てのクローンが新バージョンで追加されたクい状態が理想である．そのため，主流ブランチをバグ

ローンセットがない状態に保つために開発作業へ統合可能なクロー

Deleted 全てのクローンが旧バージョンから削除されン修正支援が必要である．

たクローンセット3. 準

備

Clone Notifier は，初めに既存のクローン検出器 [10]〜[12] を用いて対象プロジェクトの各バージョンからク

3. 1 コードクローン

ローンを検出する．次に，既存研究 [13] で提案されクローンとは，ソースコード中の他のコード片と一た位置重複値を計算して検出されたクローンを対応付

致または類似しているコード片を指す．全てのコード

ける．

片の組が一致または類似しているコード片の集合はク

位置重複値とは，旧バージョンのあるコード片と新ローンセットと呼ばれる．クローンは，一般的にそのバージョンのあるコード片に対して，その二つのコー類似度に基づいて以下の三種類に分類される．

ド片以外の箇所が修正されなかったと仮定した上で，Type-1 空白やコメントを除いて一致するクローン

その二つのコード片の間で重複している行数の割合をType-2 変数名や関数名などが異なるクローン

表す．位置重複値は 0 から 1 の間の値を取る．二つのType-3 文の追加，削除や変更が行われたクローン

コード片の位置重複値が 1 の場合，そのコード片は二

これまでに数多くのクローン検出手法が提案されてつのバージョン間で完全に同一であり，0 の場合，そいる．本研究と関連する二つのクローン検出手法につれらは異なるコード片だと考えられる．Clone Notifier

いて説明する．

は対象の二つのバージョンで同名ファイル中のクロー

テキストベースの検出手法

ンに対して位置重複値を計算する．旧バージョンから

テキストベースのクローン検出手法では，初めに変検出されたクローンを co ，新バージョンから検出され数の正規化やソースコードの整形といったルールにたクローンを cn としたとき，位置重複値は以下の関従ってソースコードを変形し，変形されたソースコー

数 LO(co , cn ) で計算される．

ド中のメソッドやブロックといったコード片の比較によりクローンを検出する．代表的なツールとして

NiCad [8] が挙げられる．NiCad は TXL [9] を用いてLO(co , cn ) =min(ne , oe ) − max(ns , os )ne − n s(1)

整形したコード片を，最長共通部分列検出アルゴリズ

ここで，os は co の開始行から，その行までに co を含ムを用いて比較し Type-3 クローンを検出する．

むファイル中から削除された行数を引いた値を表し，字句ベースの検出手法

oe は co の終了行から，その行までに削除された行数

字句ベースのクローン検出手法では，初めにソースを引いた値を表す．ns と ne も同様に，それぞれ cn のコードに対して字句解析を行い，得られた字句情報を開始行と終了行までに cn を含むファイルに追加され用いてクローンを検出する．代表的なツールとして，た行数を引いた値を表す．co と cn に対する位置重複

SourcererCC [10] が挙げられる．SourcererCC は字句

値が 0.3 以上となった場合，Clone Notifier はその二つの出現頻度の類似度から Type-3 クローンを検出する．

のクローンを対応付ける．

3. 2 Clone Notifier

クローン対応付けの例を図 2 に示す．図では，main

Tokui らは開発者に対するクローン修正支援のために Clone Notifier を開発した [4]．Clone Notifier は対象
プロジェクトの二つのバージョンを入力として受け取り，そのバージョン間で行われたソースコード変更に基づいて二つのバージョンそれぞれで検出された全てのクローンセットを以下の四種類に分類する．

Stable 全てのクローンがバージョン間で変更されな
かったクローンセット

Changed 一部または全てのクローンがバージョン間で変更されたクローンセット692

図 2 クローン対応付けの例
Fig. 2 An example of clone mapping.

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

メソッドを対応付けている．旧バージョンにおける
main メソッドの開始行までの削除行は 1 行，終了行までの削除行は 2 行であり，新バージョンにおける main
メソッドの開始行までの追加行は 0 行，終了行までの追加行は 2 行となっている．そのため，os = 12 − 1 = 11，oe = 15 − 2 = 13，ns = 11，ne = 15 − 2 = 13 となる．
したがって，位置重複値は 1 となるため，このメソッドは対応付けられる．
最後に，クローンの対応付け結果に基づき各クロー
ンセットを Stable，Changed，New，Deleted の四種類に分類する．また，Clone Notifier は一日一回の定期実行を想定して開発されている [5]．

図 3 CLIONE の概要．青線は CLIONE の処理を表す
Fig. 3 An overview of CLIONE. Blue lines mean processes of
CLIONE.

3. 3 プルリクエスト型開発
PR 型開発とは，GitHub の機能の一つである PR を

HTTP リクエストが送信され CLIONE が実行される．

用いる開発手法を指す．PR とは，あるブランチを他

CLIONE は作成された PR の先頭コミットと，この PRのブランチにマージする前に，ソースコードの変更なのブランチの分岐元となったコミット（以降，分岐コ

どの開発情報を他の開発者に通知する機能である．PR

ミット）間のクローンを対応付ける．

型開発では，開発者は主流ブランチではなく派生ブラ

開発者が PR を作成すると，CLIONE は対象プロジェ

ンチ上で機能追加やリファクタリング，バグ修正を行

クトをローカル環境にダウンロード（git-clone）する．

う．作業が完了すると，開発者は PR を作成し変更内

次に，先頭コミットと分岐コミットそれぞれからク

容を他の開発者に通知する．変更内容に問題がなけれローンセットを検出する．クローン検出には，既存のば，その派生ブランチは主流ブランチにマージされる．

クローン検出器である NiCad [8] と SourcererCC [10]PR 型開発は OSS 開発で広く採用されている [14]．

が利用できる．これらのクローン検出器を選択した理

4. 提案システム: CLIONE

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

本研究では，開発作業への統合を目的としたクロー

クローンセット検出が完了すると，CLIONE は修正

ン修正支援手法を提案する．提案手法では，開発作業

対象のコード片を検出するために，先頭コミットと分の一環である PR に着目し，以下の仕組みを用いてク岐コミット間でクローンの対応付けを行う．CLIONE

ローン修正支援を PR 型開発へ統合する．

では，修正対象のコード片として非同時修正クローン•PR の作成を起因として，自動で修正対象のコード片を検出する．

•

検出結果を，PR へのコメントとして開発者にセットと新規追加クローンセットを検出する．
非同時修正クローンセットとは，分岐コミットで検出されたクローンセットの内，先頭コミットで一部の通知する．

クローンのみが変更されたクローンセットを指す．非提案手法では，修正対象のコード片を検出するために，同時修正クローンセット中の変更されなかったクロー

PR の二つのコミット間でクローンの対応付けを行い，ンと対応付けられる先頭コミットのコード片は修正漏

クローンセットに行われた変更を分類する．本研究でれの可能性がある．そのため，CLIONE は非同時修正

は，提案手法を GitHub 向けシステム CLIONE として

クローンセット中のクローンと対応付けられる先頭コ実装した．CLIONE はサーバサイドアプリケーション

ミットのコード片を修正対象のコード片として検出すとして実装されており，PR 作成時に GitHub から送信

る．以下の手順で CLIONE は分岐コミット中のそれされる HTTP リクエストを受け取る．

ぞれのクローンセットが非同時修正クローンセットでCLIONE の概要を図 3 に示す．CLIONE を利用しあるかを判定する．

たい開発者は，初めに CLIONE に自身の GitHub アカ（ 1 ） 分岐コミットのクローンセット中のクローン

ウントとリポジトリを登録する．この登録以降，開を，先頭コミットのコード片（クローンがメソッド単発者が PR を作成するたびに GitHub から CLIONE に位で検出されている場合はメソッド，ブロック単位の693電子情報通信学会論文誌 2021/9 Vol. J104–D No. 9

場合はブロック）と対応付ける．対応付けには，Clone

Notifier と同様に位置重複値 [13] を用いる．対象のクローンと先頭コミット中の全てのコード片との位置重複値を計算し，その値が 0.3 以上かつ最も高くなった
コード片をそのクローンと対応付ける．
（ 2 ） 対応付けられたコード片とそのクローンの間で変更があったかを判定する．CLIONE では，クローンが変更されたかを判定するために，対応付けられた
コード片とそのクローンをそれぞれ字句列に変換し，その字句列を比較する．
（ 3 ） クローンセット中に変更されたクローンと変更されなかったクローンが存在した場合，そのクロー
ンセットを非同時修正クローンセットと判定する．
新規追加クローンセットとは，先頭コミットで検出されたクローンセットの内，一部または全てのクロー
ンが先頭コミットで新しく追加されたクローンセットを指す．クローンはソフトウェアの保守性低下に繋がるため，なるべく早い段階で集約されることが望ましい．クローンセットが新規に追加されたタイミングは集約の良い機会の一つであると著者らは考える．そのため，CLIONE は新規追加クローンセットを修正対象のコード片として検出する．以下の手順で CLIONE は
先頭コミット中のそれぞれのクローンセットが新規追加クローンセットであるかを判定する．
（ 1 ） 非同時修正クローンセット検出と同様にして，
先頭コミットのクローンセット中のクローンを分岐コ
ミット中のコード片と対応付ける．
（ 2 ） あるクローンに対して，分岐コミット中に対応付けられるコード片が存在しなかった場合，そのク
ローンは先頭コミットで新たに追加されたクローンと判定する．
（ 3 ） 先頭コミットで追加されたクローンを含むク

図 4 非同時修正クローンセットへのコメントの例
Fig. 4 An example of CLIONE’s comment about a nonsimultaneously modified clone set.

ローンセットを新規追加クローンセットと判定する．
また，実行時間を抑えるために，変更が加わっていないファイル中に存在するクローンは対応付けを行わトとして修正対象のコード片を通知することで，開発ない．なぜなら，そのようなクローンは対応付けを行者に対して迅速なフィードバックが可能になる．

わなくても変更されていないと判定できるからである．
最後に，CLIONE は修正対象のコード片を PR への5. 評 価 実 験

コメントの形式で開発者に通知する．非同時修正ク

本研究では，四つの実験を通して，PR 型開発におローンセットに対するコメントの例を図 4 に示す．図

けるクローン修正支援に対する CLIONE の有用性をでは，一番上（図 4 中 a）に変更されたコード片の変評価した．

更箇所が diﬀ 形式で表示され，中央（図 4 中 b）に変•実験 1 では，PR 型開発への CLIONE の導入が更されたコード片全体が，その下（図 4 中 c）に変更

有用かを評価する．OSS の過去の PR に対して，クされていないコード片が表示される．PR へのコメン

ローンが同時に修正されなかった PR の割合を調査

694

論文／プルリクエスト型開発への統合を目的としたコードクローン修正支援システム CLIONEした．

•

これらの OSS を実験対象とした理由は，クローンの研実験 2 では，PR 型開発への CLIONE の導入が容易かを評価する．PR を作成してから CLIONE が結果を通知するまでの応答時間を測定し，CI ツールによるビルド時間と比較した．

究において実験対象になることが多く [15]〜[17]，かつ PR 型開発が行われているからである．
実験 1 の結果を表 2 に示す．表から，全ての対象

OSS においてクローンが同時に修正されなかった PR

実験 3 では，CLIONE の通知内容が開発者に有（以降，非同時修正 PR）が存在しており，その割合は用であるかを評価する．CLIONE を複数の OSS に適

9.4%〜18.8% であることが分かる．また，非同時修正

用し，著者らがその通知内容を元にソースコードを修PR の個数は同時修正 PR と比較して同程度またはよ正しその OSS の開発者に提示した．

り多いことが分かった．次に，非同時修正 PR または•

実験 4 では，同じく CLIONE の通知内容が開発同時修正 PR で発生した非同時修正クローンセットと者に有用であるかを評価する．CLIONE を著者らが開同時修正クローンセットの個数の箱ひげ図を図 5 に示発している OSS に適用し，その通知内容に関して開す．図から分かるように，PR 当たりの非同時修正ク

発者へのアンケートを行った．

ローンセットの個数は同時修正クローンセットと比較•

5. 1 実験

して多くなる傾向があることが分かった．これらの非1

実験 1 では，PR 型開発に CLIONE を導入する有用

同時修正クローンセットでは，2. で紹介したように実性を評価するために，クローンが同時に修正されな際にバグが発生する場合がある．そのため，開発者はかった PR（以降，非同時修正 PR）の割合を調査した．

ブランチのマージ前に，非同時修正クローンセットの

CLIONE は修正が必要と考えられるコード片をなるべ

修正の必要性を判断することが重要である．これらのく漏れなく開発者に通知することを目的としている．

プロジェクトの開発者が CLIONE を利用していた場

CLIONE は修正漏れの可能性がある非同時修正クロー合，PR の作成ごとに非同時修正クローンセットが通ンセットが発生した PR に対して通知を行う．非同時知されるため，非同時修正クローンセットに容易に対修正 PR の割合が多ければ，CLIONE を導入すること応できる．以上から，CLIONE は PR 型開発におけるでクローンの非同時修正による修正漏れを防ぎやすくクローンの修正支援に有用であると考えられる．

なる．そのため，CLIONE の PR 型開発への導入は有また，著者らはこの実験で検出された非同時修正 PR用であると考えられる．また，比較のために，クローの幾つかに対して，実際に修正を行い開発者に提示すンの同時修正が行われた PR（以降，同時修正 PR）の個数も併せて調査した（注 4）．この実験では，対象プロ

表 2 実験 1 の結果
Table 2 Results of experiment 1.

ジェクトのマージ済みの PR に対して CLIONE を手動で実行し，各 PR 間でクローンが同時修正されているかを確認した．
実験 1 では，三つの OSS を実験対象とした．表 1 にOSS の名前，2021 年 3 月 19 日時点での総 PR 数，Java

名前
JRuby
JUnit4
Gson
合計# 対象 PR
1,016
296
106
1,418

# 非同時修正 PR
192
28
12
232

割合
18.8%
9.4%
11.3%
16.3%

同時修正 PR
135
10
13
158

ファイルが変更された PR（以降，対象 PR）数を示す．

表 1 対 象 OSS
Table 1 Target OSS.
名前

# 総 PR# 対象 PR

JRuby（注 5）
JUnit4
Gson

2,404
856
326

1,016
296
106

（注 4）：非同時修正 PR と同時修正 PR は必ずしも排他的ではない．あるRP に非同時修正クローンセットと同時修正クローンセットが含まれていた場合，その PR は両方にカウントされる．
（注 5）：JRuby はマルチモジュールプロジェクトであり，本研究では core
プロジェクトのみを対象とした．

図5

非同時修正クローンセットと同時修正クローンセッ
トの個数の箱ひげ図
Fig. 5 A box plot of the number of non-simultaneously modified
and simultaneously modified clone sets.

695

電子情報通信学会論文誌 2021/9 Vol. J104–D No. 9
表 3 各 PR における処理時間
Table 3 Processing time of each PRs.
PR 番号
6424
6412
6410
6407
6406

CLIONE の応答時間
1 分 24 秒
1 分 16 秒
1 分 18 秒
1 分 17 秒
1 分 17 秒

Table 4CI ツールによるビルド時間
4 分 35 秒
14 分 35 秒
12 分 53 秒
4 分 20 秒
13 分 26 秒

表 4 CLIONE の応答時間の内訳
Breakdown of CLIONE’s processing time.
# クローン
実行時間（秒）
セット git-clone クローン検出 その他
5,664
3,174
46
34
4
5,679
3,176
47
28
1
5,679
3,175
46
29
3
5,665
3,175
47
27
3
5,173
2,925
47
26
4

PR 番号 # クローン
6424
6412
6410
6407
6406

ることで CLIONE の通知が有用であるかを評価する実験を行っている．実験内容の詳細及び結果は 5. 3 をの対応付けや分類などの CLIONE 特有の処理が占め参照されたい．

る割合は非常に小さいことが分かる．また，git-clone

5. 2 実験

が CLIONE の応答時間の大半を占めていることから，

2

実験 2 では，CLIONE が PR 型開発へ導入可能かを

CLIONE 実行時に毎回対象プロジェクトの git-clone を評価するために，PR 作成から CLIONE の通知結果が行うのではなく，差分のみをダウンロード（git-pull）す表示されるまでの応答時間を計測した（注 6）．また，PRるように CLIONE の実装を改善すれば，高速化を見込（注 7）型開発で広く採用されている CI ツール

の実行時間

める．

と比較した [14]．CLIONE の応答時間が CI ツールの加えて，CLIONE の応答時間の上限を見積もる実験

実行時間より短ければ，CLIONE を PR 型開発へ導入を行った．4. で述べたように，CLIONE は変更されなする際の障壁は低いといえる．

かったファイル中に存在するクローンは対応付けを行

この実験では，実験 1 で対象にした OSS の一つであわない．そのため，PR 内で変更されたファイルが多る JRuby の対象 PR に対し，その PR を著者らが手作

いほど，対応付け対象のクローンが増え，CLIONE の業で再現し，CLIONE の応答時間を計測した．JRuby

応答時間は増加する．つまり，プロジェクト中の全てを対象とした理由は，表 1 の三つの OSS の内，CI ツーの Java ファイルが変更されたとき，CLIONE の応答ルを利用しているのが JRuby のみだからである．本来時間は最も大きくなると考えられる．そこで，JRuby

なら，JRuby の対象 PR 全てに対して実験を行うべきの全ての Java ファイルの末尾に空行を追加する変更

だが，292 件の PR 全てを手作業で再現するのは困難を加えた PR を作成し，CLIONE の応答時間を測定しだと考えた．そのため，この実験では 2020 年 10 月 6た．この PR では全部で 1,459 個の Java ファイルが変日時点でマージ済みの PR の中から，Java ファイルが更された．この PR に対する CLIONE の応答時間は 3

一つ以上変更されている最新五つの PR を対象とした．

分 37 秒であり，表 3 中の応答時間と比べると増加し

実験 2 の結果を表 3 に示す．表から，全ての PR にたが，CI ツールによるビルド時間よりも短いという結

おいて CLIONE の応答時間は CI ツールによるビルド

果になった．

時間の半分以下と大幅に短いことが分かる．ここで，以上から，CLIONE は CI ツールによるビルドよりもCI ツールによるビルド時間が PR によって大きく異な

高速に修正対象のコード片の検出結果を通知できるこるのは，JRuby では PR の変更内容によって 2 種類のとから，PR 型開発へ容易に導入できると考えられる．

異なるビルドが行われるからである．各 PR でクロー

5. 3 実ンとして検出されたコード片の数とクローンセット数，

実験 3 では，開発者に対する CLIONE の有用性を

験

及び CLIONE の応答時間の内訳を表 4 に示す．本実

評価するために，CLIONE を用いて OSS の過去の PR

験ではクローン検出器として SourcererCC を利用し，から非同時修正クローンを検出し，著者らが修正をブロック単位でクローンを検出した．全ての PR 間で行った上でその OSS の開発者に PR として提示するクローンの追加，削除，及び変更は行われなかった．

実験を行った．PR がマージされた場合，その OSS が

この表から，CLIONE の応答時間における，クローン

CLIONE を利用していれば，PR 作成時に非同時修正

3

クローンに対応できたといえる．そのため，CLIONE（注 6）：CLIONE の実行環境は次のとおりである．CPU: Intel Xeon E5-2620，
メモリ: 32GB，OS: Ubuntu 18.04（注 7）：継続的インテグレーション（Continuous Integration）ツール．PR の作成やコミットのプッシュ時に自動でビルドやテストを行う．

696

は開発者に対して有用であると考えられる．
こ の 実 験 で は ，多 様 な OSS の 開 発 者 に 対 す る

CLIONE の有用性を確認するために，以下の条件を満論文／プルリクエスト型開発への統合を目的としたコードクローン修正支援システム CLIONE
表5
Table 5
名前
JRuby
JUnit4
fastjson
RxJavaJenkinsGuava
Glide
libGDX
checkstyle
druid
JRuby
Druid
Zuul
JacocoJackson

作成した PR 一覧
A list of PRs we made.
修正内容
利用している API の変更
変数の明示的なボクシング
コードの移動メソッド名の変更
メソッド抽出不要なコードの除去
コードの移動
エラーメッセージの修正
メソッド抽出利用している API の変更
不要なコードの除去
事前条件の追加
不要なコードの除去
コードの移動if 文の追加URL
https://github.com/jruby/jruby/pull/6360
https://github.com/junit-team/junit4/pull/1671
https://github.com/alibaba/fastjson/pull/3444
https://github.com/reactivex/Rxjava/pull/7080
https://github.com/jenkinsci/jenkins/pull/4945
https://github.com/google/guava/pull/4036
https://github.com/bumptech/glide/issues/4353
https://github.com/libgdx/libgdx/pull/6201
https://github.com/checkstyle/checkstyle/pull/8872
https://github.com/alibaba/druid/pull/3956
https://github.com/jruby/jruby/pull/6361
https://github.com/apache/druid/pull/10414
https://github.com/Netflix/zuul/pull/900
https://github.com/jacoco/jacoco/pull/1099
https://github.com/fasterXML/jackson-core/pull/642

たす OSS から非同時修正クローンを検出した．

•

GitHub 上で PR 型開発が行われている•

Java で記述されている•

GitHub のスター（注 8）数が 5,000 以上である

Table 6

表 6 アンケート対象の PR 一覧
A list of PRs that are targets of questionnaires.
PR 番号
40
76
154
442
449
482
491
496
633
663

Java で記述されている OSS を選択した理由は，著者らが Java に慣れ親しんでおり，検出された非同時修正
クローンを修正するのが容易だったからである．最終的に 14 個の OSS から 15 件の PR を作成した．
作成した 15 件の PR 及び 2020 年 11 月 3 日時点での状態の一覧を表 5 に示す．作成した PR の内 10 件状態
MergedMergedMergedMergedMergedMergedMergedMergedMergedMergedClosed
Open
Open
Open
Open

クローンの変更
新規追加
新規追加
新規追加
新規追加
新規追加
新規追加
新規追加
新規追加
非同時修正
新規追加

がマージ，1 件がクローズ，4 件がオープン状態となった．マージされた 10 件の PR に関しては，その OSSを選択し，その PR を作成した開発者 4 名に通知内容の開発者が CLIONE を利用していれば，該当する PRに関するアンケートを行った．なお，本論文の筆頭著を作成した時点で非同時修正クローンに対応できたと者はその開発者に含まれていない．アンケート対象の考えられる．一方，1 件の PR がクローズされた．こPR と，その PR 内で行われたクローンの変更内容をの PR では，著者らは CLIONE が検出した非同時修正

表 6 に示す．また，アンケート内容は以下のとおりでクローンを修正が必要だと考え修正したが，開発者はある．

修正は不要だと判断した．

（ 1 ） この PR 内で行われたクローンの変更を認識

以上から，開発者が修正の要否を判断する必要はあしていましたか．

るが，CLIONE が検出する非同時修正クローンの情報（ 2 ） 認識していた場合，修正（新規追加クローンは開発者に対して有用であると考えられる．

の場合は集約，非同時修正クローンの場合は同時修正）

5. 4 実験4

実験 4 では，開発者に対する CLIONE の有用性をを行わなかった理由は何ですか．
（ 3 ） PR 作成時に CLIONE の通知があった場合，評価するために，CLIONE の通知内容に関して開発者修正を行いますか．

へアンケートを行った．具体的には，著者らが開発し以降，アンケートに対する回答の紹介と考察を行う．

ている OSS である kGenProg [18] の過去の PR に対し質問（1）で開発者がクローンの変更を認識していて CLIONE を実行し，出力された通知内容から 10 件なかったという回答が 2 件（PR#633，663）得られた．
どちらも質問（3）に対して，修正対象のコード片が（注 8）：GitHub 利用者が気に入ったリポジトリを保存するための機能．
スター数が多いほど人気があるリポジトリだといえる．

通知されていれば修正を行うと回答していた．現在のkGenProg の実装を確認したところ，どちらの修正対象
697電子情報通信学会論文誌 2021/9 Vol. J104–D No. 9
表 7 アンケート結果
Table 7 Questionnaire results.
PR 番号633，663
154，442，482
491，4964076449

質問（1）の回答
認識していなかった

認識していた質問（2）の回答
CLIONE の改善案——集約する必要がない
フィルタリング機能の追加
可読性を優先した—実装速度を優先した
Issue 作成機能の追加
集約が難しい集約に適したクローン検出器の利用集約方法を知らない
修正方法提示機能の追加のコード片も修正がなされていた．以上から，CLIONEは技術的負債と呼ばれ，できるだけ早い段階で修正すを利用していれば，開発者は PR 作成時に修正対象のべきだと考えられている [19]．このようなコード片の

コード片を修正できたといえる．

対処方法として，Issue の作成が挙げられる．Issue と一方，質問（1）で開発者がクローンの変更を認識

は GitHub の機能の一つであり，Issue を用いることでしていたという回答が 8 件得られた．以降，この 8 件

タスクを管理したり，他の開発者へ助けを求めたりでについてより詳細に分類し，考察を行う．初めに，3きる．技術的負債を修正するタスクを Issue として管件（PR#154，442，482）に関しては，質問（2）で “対理することで，その後の技術的負債に対する修正作業

象のクローンを集約する必要がない” という旨の回答を容易にできる．したがって，CLIONE に Issue 作成を得られた．対象のクローンを確認したところ，全て機能を実装することで，このような修正対象のコード

行数が 6 行程度だった．以上から，開発者は行数の小片の管理を支援できると考えられる．

さいクローンを集約対象として扱わないと考えられ

次に，1 件（PR#76）に関しては，質問（2）で “クる．したがって，新規追加されたクローンに対して，

ローン間で変数の型が異なるので集約が困難である”

行数でフィルタリングを行った後に通知を行うようにという旨の回答が得られた．これについては，一般的CLIONE を改善することで，このような開発者に有用なクローン検出器はクローンを検出する際に識別子のでない通知を送信しないようにできると考えられる．

正規化を行うが，同時に型名も正規化するのが原因で次に，2 件（PR#491，496）に関しては，質問（2）である．したがって，型名を正規化しない設定をもつよ“クローンを集約することで可読性が悪化すると考えうなクローン検出器を CLIONE で利用することによった” という旨の回答が得られた．これらの PR で新して，このような集約に適していないクローンの検出をく追加されたクローンは，似たような処理を行ってい避けられると考えられる．

るがどちらも親クラスが異なっているためメソッドの最後に，1 件（PR#449）に関しては，質問（2）で “集引き上げが難しく，また，無理にメソッドの抽出を行約を行いたかったが，方法を知らなかった” という旨のうと可読性が悪化する可能性があるクローンだった．

回答が得られた．対象のクローンは共通の親クラスを一方，これは追加されたコードにおける継承関係など

もち，処理の一部のみが異なるクローンだった．現在の設計の悪さがクローンの集約を困難にしているともの kGenProg の実装を確認したところ，このクローン考えられる．実際に，PR#491，496 で追加されたコー

は Template Method パターン [20] によって集約されてドに対して設計を改善するリファクタリングが行われいた．これに関しては，先ほど述べたような Issue 作ていた（注 9）．このことから CLIONE は，集約対象のク成機能を CLIONE に実装することで，PR 作成時でのローンのみでなく，プロジェクトの設計の悪さを指摘

クローンの集約が困難だと開発者が判断しても，Issue

しているとも考えられる．

を作成することで他の開発者に助けを求められる．ま次に，1 件（PR#40）に関しては，質問（2）で “実た，質問（3）の回答に “CLIONE が「こう集約すると装速度を重視してあえて集約を行わなかった” といういいですよ」という提案をしてくれるとなお良い” とい旨の回答が得られた．この回答から，クローンを集約

う記述があった．そのため，修正対象のコード片を通するかどうかは開発者の判断によることがわかる．一

知するだけでなく，その修正方法も提示できるように方，このような実装速度を重視した場当たり的な実装

CLIONE を改善することも重要であると考えられる．

（注 9）：https://github.com/kusumotolab/kGenProg/pull/501

結果から，開発者は 10 件中 2 件のクローンの変更を認

本実験のアンケート結果を表 7 に示す．アンケート698

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

識しておらず，変更に関する通知があればクローンの存ツールがクライアントサイドアプリケーションとし修正を行っていたという回答を得られた．また，残りて実装されているのに対し，CLIONE がサーバサイド

8 件の変更に関しては，質問（2）の回答から，幾つか

アプリケーションとして実装されているという点であの CLIONE の改善案を得られた．以上から，CLIONE

る．CLIONE はその特徴から以下の長所がある．

は開発者に対して有用な通知を行え，また，現時点（ 1 ） CLIONE は開発者個人の環境に依存しない利で有用でないと開発者に判断された通知であっても，用が可能である．既存ツールは Eclipse プラグインとCLIONE に幾つかの改善を加えることで，有用でない

して実装されていることから，Eclipse を利用している通知を送信しないようにしたり，通知以外の方法で開開発者しか利用できない．

発者を支援したりする可能性を示した．したがって，（ 2 ） CLIONE は開発者個人が複雑な設定を行うこ

CLIONE は開発者のクローン修正支援に対して有用でとなく，GitHub のプロジェクト単位で開発への導入やあると考えられる．

利用の解除を行える．
一方で以下の短所が考えられる．

6. 関 連 研 究（ 1 ） 外部サーバにプロジェクトをダウンロードで

6. 1 PR 型開発支援システム

きないプロジェクトに対して CLIONE を利用したい

Alizadeh らは，自動リファクタリングを PR 型開発

場合，オンプレミスでサーバを用意する必要がある．

に統合するシステム RefBot を提案した [21]．RefBot（ 2 ） 開発者個人の好みに合わせた CLIONE の設

は PR の作成ごとに自動で対象プロジェクトのリファ

定の変更は困難である．

クタリングを行い，結果を開発者に提示する．

また，CLIONE は PR 型開発を支援するという点

Carvalho らは，静的解析を PR 型開発に統合するシにおいても既存ツールと異なる．PR 型開発は今日のステム C-3PR を提案した [22]．C-3PR は PR の作成ご

OSS 開発で広く採用されているため，PR 型開発を支とに対象プロジェクトに対して既存の静的解析ツール

援する重要性は高いと著者らは考えている．

を実行し，出力された警告を自動で修正する．

また，著者らはこれらの手法と CLIONE は必ずしAlizadeh 及び Carvalho らは開発したシステムを実開も排他的ではないと考えている．例えば，JSync のク

発に適用する実験を行っており，それぞれ自動リファ

ローン修正方法の提示を CLIONE に統合させること

クタリングと静的解析の PR 型開発への統合は開発者で，より有用な開発者支援が行えると考えている．

に有用であると結論付けている．CLIONE はクローン修正支援を PR 型開発に統合するシステムであり，同様に開発者に有用であると考えている．

7. 妥当性の脅威
本研究では，特定の OSS を対象に実験を行った．そ6. 2 クローン修正支援のため，異なるプロジェクトを対象とした場合，異なNGuyen らは，クローンの同時修正支援を行うツー（注 10）

ル JSync を提案した [23]．JSync は Eclipse

る結果が得られる可能性がある．また，実験 4 ではアのプラ

ンケートを行ったが，アンケート対象の開発者 4 名のグインとして開発されており，コードのコミット時に中に本論文の著者 1 名が含まれている（注 11）．そのため，非同時修正クローンを自動で検出する．また，修正さその開発者はアンケートに好意的な回答をしている可れたクローンと修正されなかったクローン間の差分を能性がある．しかし，著者らが確認した限り，他の開計算し，クローンの修正方法を開発者に提示する．

発者が行ったアンケート結果と比較して特段好意的な

Wit らはクローン管理ツール CLONEBOARD を提案

回答は見られなかった．

した [24]．CLONEBOARD も Jsync と同様に Eclipse

CLIONE はクローン検出に既存のクローン検出器のプラグインとして開発されており，コード片のコ

NiCad と SourcererCC を用いている．異なるクローン

ピーアンドペースト操作を記録し，ペーストされた検出器を用いた場合，今回の実験結果とは異なる結果

コード片が修正された際に，そのコピー元のコード片が得られる可能性がある．

を修正対象として開発者に提示する．

CLIONE によるクローン対応付け及び変更の分類は

これらの既存ツールと CLIONE の大きな違いは，既（注 10）：https://eclipse.org/（注 11）：その開発者が回答したアンケートの PR 番号は次のとおり: 76，
154，442，482，491，496，633699

電子情報通信学会論文誌 2021/9 Vol. J104–D No. 9

クローン検出の対象となるプログラミング言語に依存しない．そのため，CLIONE が利用しているクローン

ing, pp.642–646, 2020.
[5]

ing clone change notification system into an industrial development

検出器がクローンを検出可能なプログラミング言語で記述された全てのプロジェクトに対して CLIONE を

process,” Int. Conf. Program Comprehension, pp.199–206, 2013.
[6]

適用できる．しかし，本研究では Java で記述された

J. Feller and B. Fitzgerald, Understanding Open Source Software
Development, Addison-Wesley Longman Publishing Co., Inc.,
USA, 2002.

OSS のみを実験対象として扱っている．そのため，他の言語に対して実験した場合，結果が異なる可能性がY. Yamanaka, E. Choi, N. Yoshida, K. Inoue, and T. Sano, “Apply-[7]

T. Nakagawa, Y. Higo, and S. Kusumoto, “CLIONE: Clone modification support for pull request based development,” Asia-Pacificある．

Software Engineering Conference, pp.455–459, 2020.
[8]

8. む す び

J.R. Cordy and C.K. Roy, “The NiCad clone detector,” Int. Conf.
Program Comprehension, pp.219–220, 2011.

本研究では，PR 型開発への統合を目的としたクローン修正支援手法を提案し，GitHub 向けシステム[9]Computer Programming, pp.190–210, Aug. 2006.
[10]

CLIONE として実装した．CLIONE は PR の作成時にその PR の先頭コミットと分岐コミット間でのクローン変更により修正が必要になったコード片を検出す

J. Cordy, “The TXL source transformation language,” Science of
H. Sajnani, V. Saini, J. Svajlenko, C.K. Roy, and C.V. Lopes,“SourcererCC: Scaling code clone detection to big-code,” Int.
Conf. Software Engineering, pp.1157–1168, 2016.

[11]“CCFinderX,” http://www.ccfinder.net/[12]

K. Yokoi, E. Choi, N. Yoshida, and K. Inoue, “Investigating vector-

る．加えて，四つの実験から CLIONE の有用性を確認

based detection of code clones using BigCloneBench,” AsiaPacific Software Engineering Conference, pp.699–700, 2018.

した．
今後の課題として以下を考えている．

[13]

cal study of code clone genealogies,” Int. Symp. Foundations of

既存システムの二つ目の課題に対する評価
著者らは 1. にて，既存システムは大量の修正対象のSoftware Engineering, pp.187–196, 2005.
[14]

Y. Yu, H. Wang, V. Filkov, P. Devanbu, and B. Vasilescu, “Waitfor it: Determinants of pull request evaluation latency on GitHub,”

コード片を一度に開発者に通知してしまうことを課題として挙げている．しかし，現時点では提案手法がこM. Kim, V. Sazawal, D. Notkin, and G. Murphy, “An empiri-

Working Conf. Mining Software Repositories, pp.367–371, 2015.
[15]

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-Pacific Software Engineering Conference, pp.284–291, 2019.

実装の改善
今後は CLIONE の実装の改善を行う予定である．

[16]

pilation to enhance clone detection,” Int. Workshop on Software

具体的には，5. 4 で述べたように，集約に適しないク
ローンのフィルタリング機能，Issue 作成機能，及びClones, pp.1–7, 2017.
[17]

K. Uemura, A. Mori, E. Choi, and H. Iida, “Tracking methodlevel clones and a case study,” Int. Workshop on Software Clones,

CLIONE が検出した修正対象のコード片に対する修正方法の推薦機能の実装を予定している．

C. Ragkhitwetsagul and J. Krinke, “Using compilation/decom-

pp.27–33, 2019.
[18]

Y. Higo, S. Matsumoto, R. Arima, A. Tanikado, K. Naitou, J.

謝辞 本研究は，日本学術振興科学研究費補助金基Matsumoto, Y. Tomida, and S. Kusumoto, “kGenProg: A high-

盤研究（B）（課題番号:20H04166）の助成を得て行わ

performance, high-extensibility and high-portability APR sys-

れた．

tem,” Asia-Pacific Software Engineering Conference, pp.697–698,

文
[1]

献

2018.
[19]

M. Mondal, C.K. Roy, and K.A. Schneider, “Bug propagationof code smells debt on quality code evaluation,” Int. Workshop on

through code cloning: An empirical study,” Int. Conf. Software
Maintenance and Evolution, pp.227–237, 2017.
[2]

Managing Technical Debt, pp.15–22, 2012.
[20]

Y. Higo, Y. Ueda, S. Kusumoto, and K. Inoue, “Simultaneousmodification support based on code clone analysis,” Asia-Pacific[4]

Software Engineering, pp.823–834, 2019.
[22]

A. Carvalho, W. Luz, D. Marcílio, R. Bonifácio, G. Pinto, and E.

Process Improvement, pp.220–233, 2004.

Dias Canedo, “C-3PR: A bot for fixing static analysis violations

S. Tokui, N. Yoshida, E. Choi, and K. Inoue, “Clone notifier:

via pull requests,” Int. Conf. Software Analysis, Evolution andDeveloping and improving the system to notify changes of code
clones,” Int. Conf. Software Analysis, Evolution and Reengineer-

700

V. Alizadeh, M.A. Ouali, M. Kessentini, and M. Chater, “RefBot: Intelligent software refactoring bot,” Int. Conf. AutomatedY. Higo, T. Kamiya, S. Kusumoto, and K. Inoue, “Refactoring
support based on code clone analysis,” Product Focused Software

E. Gamma, Design patterns: elements of reusable object-oriented
software, Pearson Education India, 1995.

[21]

Software Engineering Conference, pp.262–269, 2007.
[3]

F.A. Fontana, V. Ferme, and S. Spinelli, “Investigating the impact

Reengineering, pp.161–171, 2020.
[23]

H.A. Nguyen, T.T. Nguyen, N.H. Pham, J. Al-Kofahi, and T.N.

論文／プルリクエスト型開発への統合を目的としたコードクローン修正支援システム CLIONE
Nguyen, “Clone management for evolving software,” IEEE Trans.
Software Engineering, pp.1008–1026, 2012.
[24]

M. de Wit, A. Zaidman, and A. van Deursen, “Managing code
clones using dynamic change tracking and resolution,” Int. Conf.
Software Maintenance, pp.169–178, 2009.

（2020 年 11 月 16 日受付，2021 年 3 月 24 日再受付，
5 月 18 日早期公開）

中川将2019 大阪大学基礎工学部情報科学科卒．
2021 同大学大学院情報科学研究科コンピュータサイエンス専攻博士前期課程了．在学中，コードクローン分析に関する研究に
従事．

肥後 芳樹

（正員）

2002 大阪大学基礎工学部情報科学科中退．
2006 同大学大学院博士後期課程了．2007 同大学大学院情報科学研究科コンピュータサ
イエンス専攻助教．2015 年同准教授．博士（情報科学）．ソースコード分析，特にコー
ドクローン分析，リファクタリング支援，
ソフトウェアリポジトリマイニング及び自動プログラム修正に関する研究に従事．情報処理学会，日本ソフトウェア科学会，
IEEE 各会員．

楠本 真二

（正員）

1988 大阪大学基礎工学部卒．1991 同大

学大学院博士課程中退．同年同大学基礎工学部助手．1996 同講師．1999 同助教授．
2002 同大学大学院情報科学研究科助教授．
2005 同教授．博士（工学）．ソフトウェアの生産性や品質の定量的評価に関する研究に従事．情報処理学会，IEEE，IFPUG 各会員．

701