Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Report

プロジェクト間クローンに対する変更傾向の調査
石津卓也1,a)

吉田

則裕2

崔 恩瀞3

徳井 翔梧1

井上 克郎1

概要：既存のプロジェクトやコードを再利用することは標準化されたシステム開発環境 (エコシステム) を形成し開発の効率化に貢献する．しかしながら, このようなプロジェクト間クローンを変更した場合，再利用ソースコードにおいても同様の変更を検討する必要がある．そこで本研究では，実際の GitHub 上で管理されている C/C++プロジェクト間クローンの変更傾向に関する調査を行った．その結果，一貫した変更は一貫性のない変更に比べて約 1.89 倍存在し，一貫した変更が行われているプロジェクトペアは完全一致していることが明らかになった．一貫した変更に比べて一貫性のない変更のほうが約 1.89 倍存在していることが判明した．プロジェクトの変更理由についても調査し，一貫性のない変更の多くはプロジェク
トペアの一方が開発者の開発活動があまり活発ではないために生じていると考察した．また，両方のプロ
ジェクトの開発が活発だった場合，それぞれの機能が独自に拡張されている可能性がある．
キーワード：プロジェクト間コードクローン,OSS, 変更傾向

Change Trends Analysis of Inter-Project Cloning
Takuya Ishizu1,a)Norihiro Yoshida2

Eunjong Choi3

1. まえがき

Shogo Tokui1

Katsuro Inoue1の依存関係やバグ修正の観点などから望ましいと考えられるが，一貫した変更が行われるとは限らない．再利用ソー

オープンソースソフトウェア (OSS) の開発には高品質なスコード間の一貫性のない変更が生じる理由は次の 2 つのソースコードが開発される．昨今では，多くのソフトウェ

理由が考えられる．1 つは再利用ソースコードの変更を検ア開発者が GitHub などのリポジトリ上で公開されている知ができていない可能性があることで，もう 1 つはその検OSS を容易に利用でき，高品質で効率的な開発が可能であ知した変更を反映するべきか否か検討しなければならず開る．その一方で各々の開発者が既存の OSS を再利用をす

発者にとって負担になっている可能性があることである．

ることで生じる問題がある．変更された再利用ソースコー

開発者は一貫性のある変更が必要になった時，変更に伴うドを一貫性のない変更が行われることである．例えば，プ

保守作業全体について考慮して一貫した変更を行うべきか

ログラミング言語や依存ソフトウェアの仕様変更，機能拡否かを検討する必要があるが，必ずしも行われるとは限ら

張，バグの修正のために再利用したソースコードが変更さない．

れることがある．このような変更に対して再利用元ソース

しかしながら，この理由を調べるためにはプロジェクト

コードにも一貫した変更を検討することはソフトウェア間

間にまたがる再利用ソースコードの変更に関する実際の傾

1

2

3

a)

大阪大学
Osaka University
名古屋大学
Nagoya University
京都工芸繊維大学
Kyoto Institute of Technology
t-ishizu@ist.osaka-u.ac.jpⓒ 2019 Information Processing Society of Japan向について詳細に把握する必要があり，多くの OSS を対象にどのような再利用ソースコードがどの程度変更されているのか，あるいはなぜ一貫性のない変更をしているのかについて調査する必要がある．また，反対に一貫した変更についても同様にどのような再利用ソースコードがどの程度

1Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Report

変更されているのか調査することはプロジェクト間にまたド片に対して同一修正を行うかを検討するため，コードク

がる再利用ソースコードの一貫した変更を行う効率的な開ローンはなるべく集約すべきであるという考え方がある．

発方法を考える上で重要な手掛かりになると考えられる．

一方で，ソースコードの可読性やモジュールの再利用によ

プロジェクト間の再利用に関する研究はいくつか行われてる機能の凝集性を考慮した場合，すべてのコードクローン

いる [1], [6]．これらの研究はともに GitHub 上に存在するを集約すべきではないとも考えられる．そのため，コード

プロジェクトにまたがる再利用ソースコードの分布についクローンの集約はどのようなコードクローンであるのかをて，コードの類似性に着目して検出するプロジェクト間ク

開発者がよく見極めて行う必要がある．
一般的にコードクローンが発生する主な要因としてはコローンを検出する手法を用いて調査し，どのようなソース
コードが再利用されやすいかについて考察している．

ピーアンドペーストが挙げられる．開発者が類似処理を開

本研究では，Lopes らの研究 [6] のが発見した GitHub 内

発する際に既存ソースコードをコピーアンドペーストしの再利用ソースコードについて，プロジェクト間で一貫して開発作業を効率化させたいためである．ソースコードのた変更の効率的な開発方法や一貫性のない変更に対する対

再利用は単一のプロジェクト内だけではなくて，プロジェ

策を考える目的のためにプロジェクト間クローンの変更傾

クトを跨って頻繁に行われる．単一のプロジェクト内で発向について調査した．その結果，918 プロジェクト中 148

生するコードクローンをプロジェクト内クローンと呼ぶ．

プロジェクトのプロジェクト間クローンが変更されてお一方で，プロジェクト間で発生するコードクローンをプロ

り，一貫性のある変更に比べて一貫性のない変更のほうがジェクト間クローンと呼ぶ．
コードクローンの差異の度合いに応じてコードクローン

約 1.89 倍存在していることが判明した．一貫性のある変更は完全一致している，あるいは完全一致に近い類似度をは以下の 4 つの分類がされている [7]．

持つプロジェクトペアで起こり，その変更は開発者が必要

タイプ 1 空白やタブ，コーディングスタイル，コメントに応じてリビジョンアップのタイミングで一貫性のある変の有無などの差異を取り除き完全に一致するコードク

更が行われていると考えられる．さらに，プロジェクトのローン．

変更理由についても調査し，一貫性のない変更の多くはプタイプ 2 タイプ 1 の差異に加えて，変数名やユーザ定義
名，型が異なるコードクローン．

ロジェクトペアの一方が開発者の開発活動があまり活発ではないために生じていることが明らかになった．また，両タイプ 3 タイプ 2 の差異に加えて，文の挿入や削除，変更などが行われているコードクローン．

方のプロジェクトの開発が活発だった場合，それぞれの機能が独自に拡張されている可能性がある．

タイプ 4 類似処理ではあるが，構文上の実装が異なるコー
ドクローン．

以降，2 章では変更傾向を行う調査の背景，3 章では変更傾向を調査の目的とその手順，4 章ではその調査結果と入力ソースコードからコードクローンを自動で検出する手

そこから得られた考察，5 章ではまとめと今後の課題につ法はいくつか提案されていて，SourcererCC*1 [8] は，タイ

いて述べる．

プ 3 までのコードクローンを検出可能であり，字句解析に

2. 背景基づいてファイル単位で構文的な類似度が高いコードク
ローンを検出できる．SourcererCC は Lepes らの研究 [6]

本章では，再利用ソースコードを調査する目的や手段をなどで利用された実績もあり，GitHub の任意のスナップ

説明するにあたって前提となるコードクローンやクローンショットに含まれるおよそ 100 万に近いプロジェクト数を変更管理システム，プロジェクト間クローンの既存研究に対象に 80%以上類似しているファイル単位のコードクロー

ついて説明する．

ンを検出している．

2.1 コードクローン

ジェクト間クローンの類似度である．これはコード片同士

ここで 2 つの言葉の使い分けに注意したい．1 つはプロ
コードクローンとは，プログラムテキスト中の互いに一の類似度を示していて，クローンペア 1 つにつき 1 つの類

致または類似したコード片を意味する [9]．また互いに一致

似度が算出される．もう 1 つはプロジェクトの類似度であまたは類似したコード片の集合をクローンセットと呼ぶ．

る。これはプロジェクト同士の類似度を示していて，プロ

コードクローンの存在はソフトウェアの保守作業を困難な

ジェクトペア 1 つにつきそれぞれのプロジェクトの類似度ものにすると言われている．例えば，あるコード片を変更が存在するため，2 つの類似度が算出される．例えば，プロ

する場合，そのコードクローンと同じクローンセットに属

ジェクト A とプロジェクト B が類似しているかどうかを判する他のコードクローンに対しても同様の変更が行われる

断するためには，それらに含まれるファイル数とプロジェ

べきか検討する必要がある．コードクローンにバグ等が含

クト間クローンとなっているファイル数の比率を基準に判まれていた場合，そのコードクローンとコードクローン関係になっている全てにコード片を見つけて，それらのコーⓒ 2019 Information Processing Society of Japan*1

http://github.com/Mondego/SourcererCC

2

Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Report

断している．例えば，プロジェクト A に含まれる 8 ファイ

クトから派生的に再利用がされて，さらにその派生は同一

ルのうち，4 ファイルがプロジェクト B とプロジェクト間

アプリケーションドメイン，異なるアプリケーションドメ

クローンであると認められる場合，プロジェクト A の類似

インと変化していくことが明らかになった．

度は 4/8 = 0.5 となる．また，プロジェクト B のファイル

既存研究 [1], [6] では，GitHub 上に存在するプロジェク

数が 12 ファイルの場合，その類似度は 4/12 = 0.33 と計

ト間コードクローンが多いことを明らかにした．このこと算される．

よりソフトウェア開発において，効率化や高い品質，メンテナンスの容易さの面を考慮して OSS を利用することが2.2 クローン変更管理システム Clone Notifier

選択肢の 1 つであるといえる．そのため，ソフトウェアの

コードクローン変更管理システム Clone Notifier [10] と進化過程では必ずしも 1 つのソフトウェアで完結した進化は，2 バージョン間のコードクローン変更情報を検出し，をするわけではなく，[1] で述べられているようにオニオン分類した結果を開発者に通知するシステムである．まずモデルとして拡張的な進化していくと予想される．

Clone Notifier はコードクローン検出ツール CCFinder [4]

一方で再利用ソースコードの変更が加えられればその変を用いて，各バージョンのソースコードからクローンセッ

更を再利用先 OSS で一貫した変更をするのか検討しなけトを検出し，２つのバージョン間のクローンセットの変更ればならない．プログラミング言語や依存ソフトウェアの情報を検出する．最後に，各クローンセットを変更の内容

仕様変更，機能拡張，バグの修正などの理由のために変更

で以下のように分類する．

が加えられるが，再利用ソースコードのメンテナンスを行• Stable: ２バージョン間で全てのコード片が変更されなかったクローンセット

う開発者は必ずしも変更内容を一貫した変更をする選択が行う必要はない．

• Changed: ２バージョン間で一部のコード片に対してLopes らは再利用ソースコードに関してプロジェクト間

編集、追加、削除の操作が行われたクローンセット

クローンを検出することで統計的な再利用ソースコードの• New: 新リビジョンにしか存在しないコードクローン

分布に関する大規模な調査を行い，再利用ソースコードのセット• Deleted: 旧リビジョンにしか存在しないコードクロー
ンセット

特性について考察しているが，それらの一貫性のある変更について調査した研究はない．そこで本研究では，再利用
ソースコードの一貫した変更について注目し，実際に変更されたプロジェクト間クローンを検出してその特性につい2.3 大規模プロジェクト間クローンに関する既存研究
プロジェクト間クローンに関する大規模な調査がいくつか行われている [1], [6]．

Lopes ら [6] は，GitHub で開発されているおよそ 450 万のフォークしていないプロジェクトを対象にプロジェクトて考察を行う．

3. 調査
本章では，再利用ソースコードを調査する目的や手段について詳細に説明する．

間クローンについて調査し，再利用ソースコードの分布を視覚的に表現する DéjàVu を作成した．この関連研究ではGitHub のスナップショットを GHTorrent[2] に対して各プロジェクトの詳細情報（スター数，コミット数，コミッタ，

3.1 調査の目的
本研究では以下の 3 つのリサーチクエスチョンに従い調査を行った．

フォークの有無，開発主要プログラミング言語など）を取

RQ1 GitHub に含まれるプロジェクト間クローンのう得し，人気のあるプロジェクトやプログラミング言語の違ち，変更されるコードクローンおよび一貫性のない変いなどからプロジェクト間クローン分布の傾向を調査して更がされたコードクローンの割合はどのくらい存在す

いる．その結果，調査対象のおよそ 70%のファイルが既存るのか．

ファイルの再利用であることを突き止めた．

RQ2 一貫した変更が行われたプロジェクト間クローンはGharehyazie ら [1] は，プロジェクト間のコード検索のどのようにして一貫性を実現しているのか，また，ど効率化を目的としてプロジェクト全体でのコード再利用のようなプロジェクトが一貫性を実現しているのか．

実態を調査している．そのためにコードクローン検出ツー

RQ3 変更されたプロジェクト間クローンはどのような

ル Deckard[3] が検出したプロジェクト間クローンに対し理由で変更されていたのか．

て統計学的アプローチといくつかのユースケースから再利RQ1 ではプロジェクト間クローンはどの程度の変更がなさ

用ソースコードの特性について調査している．調査結果，れるのかについて調査する．さらにその中で一過性のある

GitHub ではプロジェクト間クローンが広く普及している

変更あるいは一貫性のない変更が行われるプロジェクトのことや，エコシステムの形成はオニオンモデルとなってい数を調査することで本研究の調査対象の全体的な変更傾向

ることが明らかになった．すなわち，一つの同じプロジェについて考察する．RQ2 では，変更されているプロジェクⓒ 2019 Information Processing Society of Japan3

Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Report

ト間クローンを有するプロジェクトのうち一貫性のある変行うことができる．

更されているものに関して調査する．一貫した変更がされ3.2.3 Clone Notifier の拡張ているプロジェクトの傾向を見ることで将来的なメンテナ

調査のために，本研究では Clone Notifier に 2 点の改変をンス作業の効率化に貢献できる可能性がある．RQ3 では，加えた．1 点目は，コードクローン検出ツールを CCFinder

実際に変更されたプロジェクト間クローンがどのような理から SourcererCC に変更した．なぜなら，CCFinder では

由で変更されたかについて調査する．特に変更が起こりや検出できなかったタイプ３のコードクローンを Sourcer-

すいプロジェクトの傾向の調査を行う．

erCC は検出できるからである．2 点目は，本研究におい3.2 調査の手順

らが定義したクローンセットの進化パターンを参考に，クて詳細な分析を行うための，分類の拡張である [5] ．Kim
リサーチクエスチョン回答のために行った調査の手順について説明する．

3.2.1 対象プロジェクトペアの選択
まず調査対象のプロジェクトは Lopes らの研究で検出したプロジェクト間クローンを含む OSS を対象に調査した．
彼らの研究では，対象プログラミング言語を C/C++，Java，

Python，JavaScript の 4 つに絞っているが，ソースコー
ドの再利用率が最も高いプログラミング言語は JavaScript
で，最も低いのは Java であると示している．本研究では,再利用率が中間である C/C++プロジェクトを調査対象として選択した．
次に、対象プロジゼクトペアを選択するために，まず現ローンセットの分類の１つである Changed Cloneset にラベルを追加した．

• Add 追加されたコード片がある• Subtract 削除されたコード片がある• Shift 別のクローンセットから移動してきたコードク
ローンが含まれる• Consistent 全てのコード片に同様の編集が行われている• Inconsistent 編集されたコード片と編集されていない
コード片が同時に存在する

3.2.4 Clone Notifier によるバージョンにまたがるプロ
ジェクト間クローンの検出

在も公開されているプロジェクト*2 を調べ，DéjàVu が公

2.2 節で説明した Clone Notifier はダウンロードしてき

開しているクローン結果をもとに任意のプロジェクトペ

たプロジェクトからコードクローンを検出し，2 バージョ

ア 6900 を選択した．Dejavu が公開しているプロジェクトン間の変更を管理できる．本研究では，3.2.1 節で選択した間の類似度はしきい値が 50%以上に限られている．2 バー

プロジェクトペアを 1 つのプロジェクトとみなして，それジョンは 2017 年 1 月 19 日を調査開始日付として 2019 年

ぞれの調査対象期間の調査開始と終了日付のコミットを 2

9 月 30 日〜10 月 6 日を終了日付として採用した。前者はバージョンとみなす．各バージョンごとにプロジェクトペDéjàVu におけるデータセットの構築日と推測された選択

アのコードコーンを検出する．2 バージョンのそれぞれでした．なお，正確な日付については Lopes らの研究 [6] に検出したバージョン間クローンに関する情報を永続化するは明記されていない．また，後者についてはダウンロード

際に，その各ファイルが属する本来のプロジェクトに関し期間でダウンロードしたときに最新のバージョン選択してて，プロジェクト間にまたがるようなバージョン間のコーいる．

ドクローンを抽出する．そして，その永続化したプロジェ

3.2.2 プロジェクト間クローンの検出

クト間クローンに関する情報に基づいて 3.1 節で述べた 3

プロジェクト間クローンについて，本論文では Lopes

つのリサーチクエスチョンにこたえる．なお，この一連のら [6] が公開している結果を用いている．そのため，プロ調査プロセスを自動化した際にリポジトリを clone するこ

ジェクト間クローンの検出は既存研究の手法に準拠していとを失敗する，あるいは SourcererCC の実行時間が非常にる．Lopes らが提案したプロジェクト間クローン検出手法

長くなる場合を想定して 1 時間のタイムアウトを設けたたについて簡単に説明する．まず GitHub のスナップショッ

め，永続化できたプロジェクトペア数は 918 となった．

トに対して，主要プログラミング言語が C/C++で開発されているフォークのないすべてのプロジェクトをダウンロードし，すべての対象ソースコードに対してファイル
ハッシュ値，トークン列ハッシュ値を算出する．次に，ファ4. 調査結果
本章では，リサーチクエスチョンに沿って調査結果を報
告しその考察を行う．

イルハッシュ値が一致する場合，ソースコードが一致していると判定し，トークン列ハッシュ値が 80%以上類似していればプロジェクト間クローンであると判定している．
コードクローン検出ツール SourcererCC はこれらの判定を4.1 RQ1：変更プロジェクト数および一貫しない変更が行われたプロジェクト数
表 1 は，プロジェクト間クローンが存在するプロジェク
トについて，プロジェクトが含むクローンセットの変更情報*2

http://dejavu.ics.uci.edu/indexⓒ 2019 Information Processing Society of Japanで分類した結果を示す．ここでの変更とは Clone Notifier

4Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Reportの分類でいう Changed，New および Deleted を指す．ただ表 1 プロジェクト間クローンが存在するプロジェクト数の変更情報

し，この表からわかるように、今回の対象プロジェクト
間クローンにおいてはいずれも Chganged または Stable に

完全一致

All

ChangedStable70

2248

分類され，New および Deleted は検出されなかった．その

100%

99

5

94

ため，表中では Changed と Stable の分類しか表記してい100%未満 80%以上

205

31

174

ない．

80%未満 50%以上

318

60

258

50%未満

226

30

196

また，表 1 の縦の項目はプロジェクトの類似度で分類している．その分類は既存研究 [6] に従い，「100%」，「80%」，「50%」を目安に 5 つの区分に分けていて，それらの項目は一貫した変更に比べて一貫していない変更がおよそ 1.89 倍

排他的な関係となっている．表 1 の項目を上から順番に説存在していることが分かった．また，一貫した変更が行わ

明する．まず「完全一致」とは，2 つのプロジェクトペア

れているプロジェクトペアは完全一致していることが多い

が完全に一致していることを指している．その数は 70 あるが，注意したいのは集計はプロジェクト数で行っているということが判明した．


RQ1 の答え

ので完全一致の項目では 35 ペアの完全一致したプロジェ

RQ1. ではプロジェクト間クローンがどの程度変更さクトペアについて表示していることになる．次の「100%」

れているのかについて調査している．その答えはおよという項目は，ペアプロジェクトに対して包含されている

そ 16%であり，決して多い数ではないが，無視できる

プロジェクト数を示している．すなわち，プロジェクト A1ほどの小さな数でもないと考えられる．その変更プロと A2 において，A1 が 100%であるとき，A1 のファイルはジェクトのうち，一貫していない変更のほうが一貫し

A2 に完全に含まれているが，その反対では部分的にしかた変更よりも多く，一貫した変更が行われているプロ

含んでいないことを意味している．最後に，この，「100%」
項目から下の項目 3 つについては「100%」
，
「80%」
，
「50%」



ジェクトペアは完全一致しているという特徴がある．



をしきい値に範囲ごとの分類している．
表 1 から、調査対象プロジェクトの傾向では，918 プロ
ジェクトのうち 148 プロジェクト（約 16.1%）が変更され4.2 RQ2：一貫性のある変更の手段ていることが分かる．変更されたプロジェクト数の割合がRQ2 を答えるために表 2 で示した完全一致しているプ

最も高い分類は「完全一致」で約 31.4%であり，最も低い

ロジェクトペア中の一貫した変更をしているプロジェクト

分類は「100%」で約 5%だった．実際の数で比較すると変ペア 10 組すべてについて目視で確認した．これらのプロ

更プロジェクトが最大であるのは「80%未満 50%以上」のジェクトを調査したとき，以下の 2 つのコードクローン間60 プロジェクトで，最小であるのは「100%」の 5 プロジェ

で一貫的な変更が行われた理由があることが判明した．

クトであった．

( 1 ) 対象プロジェクトが開発用と公開用の 2 つのリポジト

表 2 は変更されていた各プロジェクトに含まれていリに分岐していて，定期的に開発者がマージしている．

たクローンセットがどのような変更であるのか調査しし( 2 ) GitHub の仕様によって，プロジェクトのリネーム後た結果を示す．ただし，紙面の幅の関係で表 2 の各項目であっても旧 URL からリダイレクトされる．

名を省略した表記を用いているので説明する．まず，横後者の要因は調査方法の問題点であり，本質的な一貫した軸では変更されたプロジェクト間クローンの分類として変更は前者である．前者に該当するプロジェクトは 2 組

Kim らの研究 [5] に従い，
「ADD」，
「ADD(CONsistent)」，

存在し，どちらも CRAN*3 に公開されているプロジェク「ADD(INConsistent)」，「CONSistent」，「INConsistent」，

トだった．これらのプロジェクトペアは一方が開発用リポ「SHIFT(INConsistent)」，「SHIFT」の 7 項目としている．

ジトリで，もう一方が公開用リポジトリとなっている．開また，縦の項目はクローンセットが属するプロジェクトペ

発用リポジトリでは盛んにコミットが行われ，リビジョン

アのそれぞれの類似度を，括弧内が類似度のしきい値を表が更新されるタイミングでマージが行われていた．公開用しており，ハイフンでそのしきい値の組み合わせを示してリポジトリは Read Only となっており，認可された開発いる．

者しか変更を加えることはできない．更新のタイミングは

表 2 の「(100)-(100)」は完全一致するプロジェクトを示

開発者の任意のタイミングで行われていると考えられる．

していて，その多くが consistent な変更であることが分か

また，一貫性のない変更が行われていた完全一致するプロ

る．完全一致をしていないプロジェクトの組み合わせでは

ジェクト間でも同様にミラーとなっているリポジトリを発

consistent な変更よりも inconsistent な変更な多いことも見している．
また，表 2 中に完全一致していないにもかかわらず一貫

わかった．
変更されたプロジェクト間クローン全体の傾向としてはⓒ 2019 Information Processing Society of Japan*3

https://cran.r-project.org/

5Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Report
表 2 プロジェクト間クローンの変更に関するクローンセットの内訳

ADD

ADD(CON)

ADD(INC)

CONS

INC

SHIFT(INC)

SHIFT

SUM

(100)-(100)

1

0

0

80

0

0

0

81

(100)-(100:80)

0

0

0

0

0

0

0

0

(100)-(80:50)

0

0

0

0

0

0

0

0

(100)-(0:50)

0

0

0

0

7

7

0

14

(100:80)-(100:80)

1

0

2

3

58

0

2

66

(100:80)-(80:50)

0

0

0

0

14

0

0

14

(100:80)-(0:50)

0

0

0

0

23

3

0

26

(80:50)-(80:50)

0

1

0

14

63

0

0

78

(80:50)-(0:50)

0

0

0

1

11

0

0

12

(0:50)-(0:50)

0

0

0

0

0

0

0

0

SUM

2

1

2

93

176

10

2

した変更が行われているクローンセットが 18 つ確認でき
RQ2 の答えた．これらのうち 1 つのプロジェクトは，それらの類似率

RQ2. では一貫した変更を行っているプロジェクト間はお互いに 97%である．これらが一貫した変更をしているクローンについて調査することを目的としている．そのも開発用と公開用の 2 つのプロジェクトに分岐しているの答えは次のとおりである．完全に一致しているプことが理由だった．これらはリビジョンの更新時などに定ロジェクトペアの場合は，公開用リポジトリと開発用期的にマージされていると予想され，DéjàVu がプロジェ

プロジェクトをそれぞれ持ち，リポジトリの所有者にクトクローンを検出時には一部一貫した変更がなされていよって一貫した変更を行うかどうか管理されている．

なかったと予想できた．

また，完全に一致していないプロジェクトペアの場合

残りの 17 のプロジェクト間クローンをもつ 5 組のプロ
ジェクトペアについて，観察して考察した結果，次の理由が考えられる．

は，その修正に同一の編集者が携わっているため一貫した変更が管理されている．

( 3 ) プロジェクトペアにおける共通の編集者がかかわっているソースコードが含まれているため，同様の修正が行われている．

4.3 RQ3：再利用ソースコードの変更理由
まず RQ3 に答えるために，表 2 で示した変更されたプ

5 つのプロジェクトペアについて，それぞれのプロジェク

ロジェクト間クローンの変更について目視で確認し，次のトペアを持つ所有者は同じであった．すなわち，これらのような理由でプロジェクト間クローンの変更が行われていそれぞれの一貫した変更は同じ編集者が同時に変更すべきると判断した．

と判断した結果を反映していると考えることができる．
さらに 1 つのプロジェクトについては一貫した変更と一• 動作環境やライブラリに依存したバージョンアップ
• プロジェクトがもつ機能の拡張・修正

貫性のない変更の両方が含まれていた．一貫性のない変更

動作環境には Visual Studio などの IDE が含まれる．Vi-

は実行結果の出力ファイルのデフォルトパスを変更する

sual Studio は頻繁にアップデートされるが，C/C++ではものであったが，それに相当する処理内容がもう一方のク

この Visual Studio の拡張を目的とした開発が存在する．

ローン片に含まれておらず，そのプロジェクト間クローン

C/C++プロジェクトでは Visual Studio を判別するマクは機能的には処理内容が異なるクローンであると考えられ

ロ MSC VER などがある．このような動作環境のバージョ

るため，SourcererCC の誤検出であると考えられる．

ンアップに依存して変更が行われるプロジェクトを確認し完全一致するプロジェクトペアを検出する上で，URL のた．また動画ファイルフォーマット Matroska を編集する

リダイレクトは注意すべき点であるといえる．今回の調査

ライブラリに依存するプロジェクトにおいても，そのバーでリポジトリ名等を変更した影響で URL が変更される時，

ジョンアップに依存して変更が行われているなど，ライブ

GitHub の仕様で変更前の URL でもリダイレクトされる

ラリのバージョン依存な変更を確認した．これら以外の修ことが判明した．これは分析時にプロジェクトごとに固有正理由としては，バグ修正や機能拡張といったものであるの ID を割振る際に URL に対して割り当てているためにと判断した．ただし，一部の修正についてはその理由の判生じている分析の問題点だと考えられる．

別が難しくここでは言及しないものとする．
まず一貫した変更について，4.2 節の調査結果から完全一致あるいは完全一致に近い類似度を持つプロジェクトペ
アまたは同じ開発者が含まれるプロジェクトペアは一貫しⓒ 2019 Information Processing Society of Japan

6

Vol.2019-SE-203 No.1
2019/12/12

情報処理学会研究報告
IPSJ SIG Technical Report

た変更が行われやすいと考えられる．完全一致しているプ

コードの変更に関するリサーチクエスチョンを 3 つ立て

ロジェクトぺアは一貫した変更が行われる意図があって変て，それらにこたえるためにプロジェクト間クローンを検更を反映していることが 4.2 節の調査で確認できている．

出し調査した．その結果，完全一致しているプロジェクト同じく同じ開発者が携わっているプロジェクトペアについペアは一貫した変更が行われており，開発者が必要なタイても，変更すべき箇所を検討することで一貫した変更が行

ミングで同期していると考えられる．一貫した変更は，同われている可能性はある．

じ開発者がそれらのプロジェクトに携わっていても行われ

また，一貫性のない変更が行われている 53 プロジェク

る．また，一貫した変更に比べて一貫性のない変更のほう

トペアについて，それぞれプロジェクトの開発活動がどのが約 1.89 倍存在していることが判明した．プロジェクト

程度活発なのか調査した．その結果，調査期間 2017 年 1の変更理由についても調査し，一貫性のない変更の多くは

月 19 日と 2019 年 9 月 30 日〜10 月 6 日の間に変更が一度

プロジェクトペアの一方が開発者の開発活動があまり活発も行われていないプロジェクトが 41 プロジェクト含まれではないために生じていると考察した．また，両方のプロていた．すなわち，一貫性のない変更が行われるプロジェ

ジェクトの開発が活発だった場合，それぞれの機能が独自

クトペアの多くは，一方のプロジェクトの開発活動があまに拡張されている可能性がある．

り活発ではないと考えることができる．また，このようなまた，本研究を通して今後の再利用ソースコードの分析

一方のプロジェクトの開発活動があまり活発ではないプロ

における課題には以下が挙げられる．

ジェクトペアのうち，所有者が同じリポジトリが 1 組存在• 調査プログラミング言語の拡大した．一方は 2013 年頃まで開発が行われ，それ以降まった• 調査リポジトリ数の拡大く開発されていなかった．もう一方は 2014 年頃から 2018

• エコシステム周辺における変更の伝播に関する考察

年頃まで開発が継続して続けられていた．このような開発• リダイレクトされるプロジェクトの排除がずっと前に止まっているプロジェクトは古いバージョン• コードクローン検出手法の精度向上のリポジトリと考えることができる．
一貫性のない変更が行われたプロジェクトペアのうち，調査期間内に両方のプロジェクトに変更が加えられた残り

参考文献
[1]

の 12 プロジェクトペアについても考察する．それらの変更は分岐的なプロジェクトの進化が起きている可能性が高いと考えられる．例えば，所有者名が異なるがプロジェク
ト名が同じあるプロジェクトペアにおいて，一方は動作環[2]境であるハードウェアに依存した変更が加えられて，もう一方は入力できるフォーマットの種類の増加に関する機能[3]

拡張が行われていた．このように開発者が望んだ用途を実現するための変更が独自に加えられている．


RQ3 の答え

[4]

RQ3. ではプロジェクトペアの変更理由を考察する．
非一貫性のない変更の多くは，プロジェクトペアの一方が開発者の開発活動があまり活発ではないために[5]生じている．また，両方のプロジェクトの開発が活発だった場合，それぞれの機能が独自に拡張されている可能性がある．また，動作環境やライブラリに依存し[6]たバージョンアップも変更理由として一部存在して
いる．





5. まとめと今後の課題[7]

本研究では，Lopes らの研究 [6] が発見した GitHub 内の再利用ソースコードについて，プロジェクト間で一貫した変更の効率的な開発方法や一貫性のない変更に対する対策を考える目的のために GitHub に含まれる再利用ソースⓒ 2019 Information Processing Society of Japan[8]

Mohammad Gharehyazie, Baishakhi Ray, and VladimirFilkov. Some from here, some from there: Crossproject code reuse in github. In Proceedings of 2017
IEEE/ACM 14th International Conference on Mining
Software Repositories (MSR), pp. 291–301. IEEE, 2017.
Georgios Gousios. The ghtorent dataset and tool suite. In
Proceedings of the 10th working conference on mining
software repositories, pp. 233–236. IEEE Press, 2013.
Lingxiao Jiang, Ghassan Misherghi, Zhendong Su, andStephane Glondu. DECKARD: Scalable and accurate
tree-based detection of code clones. In Proceedings of the
29th international conference on Software Engineering,pp. 96–105. IEEE Computer Society, 2007.
Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue.
CCFinder: a multilinguistic token-based code clone detection system for large scale source code. IEEE Transactions on Software Engineering, Vol. 18, No. 7, pp.
654–670, 2002.
Miryung Kim, Vibha Sazawal, David Notkin, and Gail
Murphy. An empirical study of code clone genealogies.
In Proc. ESEC/FSE, Vol. 30, pp. 187–195, 2005.
Cristina V Lopes, Petr Maj, Pedro Martins, Vaibhav
Saini, Di Yang, Jakub Zitny, Hitesh Sajnani, and Jan
Vitek. Déjàvu: a map of code duplicates on github.
Proceedings of the ACM on Programming Languages,Vol. 1, No. OOPSLA, pp. 84:1–84:28, 2017.
Chanchal K Roy, James R Cordy, and Rainer Koschke.
Comparison and evaluation of code clone detection techniques and tools: A qualitative approach. Science ofcomputer programming, Vol. 74, No. 7, pp. 470–495,
2009.
Hitesh Sajnani, Vaibhav Saini, Jeﬀrey Svajlenko, Chanchal K Roy, and Cristina V Lopes. Sourcerercc: Scalingcode clone detection to big-code. In Proceedings of 2016
IEEE/ACM 38th International Conference on Software7

情報処理学会研究報告
IPSJ SIG Technical Report

[9]

[10]

Vol.2019-SE-203 No.1
2019/12/12

Engineering (ICSE), pp. 1157–1168. IEEE, 2016.
肥後芳樹, 楠本真二, 井上克郎. コードクローン検出とその関連技術. 電子情報通信学会論文誌 D, Vol. 91, No. 6,
pp. 1465–1481, 2008.
山中裕樹, 崔恩瀞, 吉田則裕, 井上克郎, 佐野建樹. コード
クローン変更管理システムの開発と実プロジェクトへの適用. 情報処理学会論文誌, Vol. 54, No. 2, pp. 883–893,
2013.

ⓒ 2019 Information Processing Society of Japan

8