ソフトウェア・シンポジウム2017 in 宮崎

コードクローン変更過程における開発者のインタラクションとソフトウェア品質の関係
久木田 雄亮和歌山大学大学院 システム工学研究科
kukita.yusuke@g.wakayama-u.jp

要旨

大平 雅雄
和歌山大学 システム工学部
masao@sys.wakayama-u.ac.jp

このような懸念を払拭するために，コードクローンの検出手法 [1, 5, 10] や分析手法 [6, 7, 9] がこれまで盛んに

本稿では，コードクローン追跡ツール CCT (Code

研究されてきた．これら既存研究の多くは主に，ある時Clone Tracer) を用いて，コードクローンの変更に関与した開発者らとソフトウェア品質との関係について分析

点のソフトウェアシステムに含まれるコードクローンとする．CCT は，コードクローンの作成・利用過程におけンの変更がソフトウェアシステムの品質に与える影響にる人的影響を調査することを意図して設計されたコード

着目している．コードクローンの存在により，あるソー

クローン追跡ツールである．分散型バージョン管理シス

スコードに対する変更が他のソースコードに対してどの

テム Git を対象としたコードクローン追跡機能に加え，ように影響するかを把握することが困難になるため，結不具合管理システムと連携することで不具合を混入した果として品質が低下する可能性が高いと考えられていたコミットとその作成者を特定し分析するための機能を備ためである．しかしながら，これまでの膨大な量の研究えている．本稿では，3 つのオープンソース開発プロジェ

を通じて，コードクローンの存在と品質に明確な関係がクト（RxJava, c:geo, Jackson databind）を対象として認められる事例とそうでない事例が混在して報告されて行った社会ネットワーク分析の結果について報告する．

おり，未だ統一的なコンセンサスは得られていない [15]．

ソフトウェアシステムの品質，あるいは，コードクロー

そのため，特に近年では，ソフトウェアシステムの改良・保守の過程でコードクローンがどのように拡散し

1. はじめにていくのかを詳細に分析するためのクローン追跡手法[4, 8, 14] に注目が集まっている．ソフトウェアシステム
長きに渡るソフトウェアシステムの改良・保守の過程の開発において広く利用されているバージョン管理シス

では，生産性の向上を目的として既存コードが頻繁に再テムに記録された全変更履歴に基づいて，リビジョンを利用されることがある．その結果，「同一の」または「類1 つずつ辿りながらコードクローンの変更により不具合が混入される過程を正しく理解し，不具合の混入を未然に防ぐための対策につながると期待されている．

似する」コード片（本稿ではコードクローンあるいは単にクローンと呼ぶ）がソースコード全体に遍在することも少なくない．ソースコード全体にコードクローンが多

本稿では，我々[12, 16] が提案したコードクローン追跡

数存在する状況においてコードクローンに変更を加える

ツール CCT (Code Clone Tracer) を用いて，コードク

必要性が生じた場合，変更箇所が多岐に渡ることから多ローンの変更に関与した開発者らとソフトウェア品質とくコストが必要となったり，変更漏れにより新たな不具の関係について分析を行い，プロジェクトにおいてコー合を混入してしまう恐れがある．すなわち，改良・保守

ドクローンを作成することは悪影響を与えるものであるの初期段階では有益な手段であった既存コードの再利用

かをコードクローンに関係する Issue や開発者間の繋がが，結果的にその後の生産性や品質を低下させる原因とりから確認する．CCT は，コードクローンの作成・利用なる可能性がある．

過程における人的影響を調査することを意図して設計さ

120

SEA

ソフトウェア・シンポジウム2017 in 宮崎

れたコードクローン追跡ツールである．分散型バージョʁϨϑζϥϱ

ン管理システム Git を対象としたコードクローン追跡

機能に加え，不具合管理システムと連携することで不具ʁϜʖζ൅ਫ਼Ϩϑζϥϱ







਎Ϩϑζϥϱ
ࢢϨϑζϥϱ
















合を混入したコミットとその作成者を特定し分析するための機能を備えている．本稿では，3 つのオープンソー

図 1: リビジョンの親子関係の特定

ス開発プロジェクト (RxJava, c:geo, Jackson databind)を対象として行った社会ネットワーク分析の結果についWて報告する．

$%

5HY 

$%5HY 

$%5HY 

$%&5HY 

$%&本論文の構成は以下の通りである．続く 2 章では，まず，
コードクローン追跡ツール CCT (Code Clone Tracer)の実装について詳述する．3 章では，CCT の処理結果$

5HY 

%&&%を用いて，コードクローン変更過程における開発者のイ
ンタラクションとソフトウェア品質との関係を調査する$

ための分析方法について述べる．4 章では，3 つのオー
プンソース開発プロジェクト (RxJava, c:geo, Jackson

databind) を対象として行った社会ネットワーク分析の結果を示し，分析結果を考察する．最後に 5 章において，本稿をまとめるとともに本研究の今後の課題を示す．

%&

5HY 1
ຎྭ$・⿊実線はリビジョン関係を⽰しているϓΟ΢ϩʤ̘ͺϓΟ΢ϩ໌ʥ

௧Յ

รߍ
͵͢

รߍ

ࡡঈ

図 2: コード片特定対象ファイルの決定（リビジョンの親子関係は図 1 と同じ）

コードクローン追跡ツール CCT2$αʖχฤಝఈ
ଲেϓΟ΢ϩ

本章では，コードクローンの作成・利用過程における人的影響を調査するため実装したコードクローン追跡ツー

ンの追跡の 4 種類の処理を順に行う．以下ではそれぞれ

ル CCT (Code Clone Tracer) について述べる．CCT は，の処理について説明する．

に存在するコードクローンの追跡を想定しており，高速(1) Git におけるリビジョンの親子関係の特定：CCT
は分散型バージョン管理システム Git を対象とするたにクローンを特定することができる粗粒度なクローン

め，従来の集中型バージョン管理システムを対処とした特定方法 [13] を用いてクローンを追跡する 1 ．また，不クローン追跡 [4, 8, 14] のように時系列でリビジョンを

数千から数万リビジョンからなるソフトウェアシステム

では，コードクローン追跡機能とコードクローン分析機

1 つ 1 つ順に辿る方法は適用できない．そのため，以下の手順でリビジョンの親子関係を特定する（図 1）．まず，分析対象リポジトリに含まれるリビジョンの情報を能のそれぞれについて詳細に説明する．

取得する．次に，リビジョン毎に親リビジョンと子リビ

具合管理システムと連携することで不具合を混入したコ
ミットとその作成者を特定する機能を備えている．以降

ジョンを特定し（図 1 左），各リビジョンの親子関係を2.1記録する（図 1 右表）．リビジョンの親子関係を整理し

コードクローン追跡機能ておくことで，図 1 の Rev.1 や Rev.5 のように，複数の親リビジョンや子リビジョンを持つリビジョンが参照

分散バージョン管理システム Git を対象としたコード可能になる．

クローン追跡を実現するために，リボジトリに保存されているすべてのリビジョンを対象に，(1) リビジョンの(2) 各リビジョンに含まれる全コード片の特定：ファ親子関係の特定，(2) 各リビジョンに含まれる全コード

イル変更情報を基にして各リビジョンのコード片特定対

片の特定，(3) コードクローンの特定，(4) コードクロー

象ファイルを決定し（図 2），[13] と同様にブロック単位でコード片を特定する（図 3）．

1 実際，クローンの特定までの処理（コード片抽出，正規化，ハッまず，分析対象リポジトリのコミット履歴から，リビ

シュ化）は，CRD (Clone Region Descriptors)[4] ベースのクローン追跡ツール ECTEC ( Enhancement of CRD-Based Clone Tracker
for Evolution of Clones ) [8] の一部を再利用して実装している．

ジョン番号，コミット日時，コミッタ名，追加・変更・削

121

SEA

ソフトウェア・シンポジウム2017 in 宮崎ſřƀƇ ʰɥŚſʰʰɥƀƇʰ ʫɨŚƈſʰʰɥƀƇʰ ʫɩŚƈʫʫ Ś
ƈ

67(3
 

ſřƀƇ ʰɥŚſʰʰɥƀſʰʰɥƀʫʫ ŚƈſʰʰɥƀƇʰ ʫɨŚƈſʰʰɥƀƇʰ ʫɩŚ
ƈ

67(3
  

ſɛřɛƀƇɛʰɛŚſɛʰʰɛƀſɛʰʰɛƀɛʫɛʫɛŚƈſɛʰʰɥƀƇɛʰɛʫɛŚƈſɛʰʰɥƀƇɛʰɛʫɛŚƈ

W
5HY 









5HY 









5HY 









5HY 









5HY 











Q

Q





図 3: ブロックの検出・正規化・ハッシュ化の流れ（[13] より抜粋）除されたファイルについての情報（コミット情報と呼ぶ）を取得する．次に，分析対象リポジトリの最初のリビジョ

5HY 1ン（リポジトリに初めてコミットされたファイル群からຎྭέϫʖϱ͹௧੽
Qͺύρεϣ஍構成されるリビジョン）を調査し，最初のリビジョンをέϫʖϱ௧੽ࣨഌ

構成する全ファイルを特定する（図 2 における Rev.1）．
コミット情報を用いて，各リビジョンに加えられたすべ

Q

αʖχฤ

έϫʖϱॄ߻

図 4: コードクローンの追跡（リビジョンの親子関係は図 1 と同じ）ての変更（ファイルの追加・変更・削除）を，最初のリビジョンを起点として，リビジョンの親子関係に従って順次遡り最新のリビジョンまでコード片特定対象ファイド片が特定される．コードクローンの特定処理においてルを決定する．マージコミット（図 2 における Rev.5）

は，まず，[13] と同様の方法（図 3 の STEP3&4&5）で，では，変更の衝突が発生する場合がある．衝突がない場特定されたブロックを定められたフォーマットに整形す合，マージ元の 2 つのコミットとの差分情報を取得し，る．STEP3 において，ブロックに含まれる変数名とリテ変更が加えられたファイルをコード片特定対象ファイル

ラルは特殊文字にすることで正規化し，変数名やリテラとする．衝突が発生していた場合，衝突を解消するまで

ルのみが異なるようなクローンを特定できるようにする．

の履歴が抜け落ちていることがあるため，そのリビジョ

さらに，STEP4 において，正規化されたブロックの文

ンに存在するファイル情報を基にしてすべてのファイル

字列をもとにハッシュ値を算出する．そして，STEP5 にをコード片特定対象ファイルとする．なお，ソースコー

おいて，ハッシュ値の一致するブロックをクローンとし

ド以外のファイルは分析対象ではないため除外する．

て特定する．このコードクローン特定処理を前述の前処

コード片特定対象ファイルに対して行うコード片特定

理によって特定できた全てのリビジョンのコード片に対処理について以下で説明する．まず，最初のリビジョン

して行うことで，各リビジョンに存在するコードクローを構成する全ファイルに対してブロック単位でコード片ンを特定できる．

を特定する．図 3 の STEP1 でソースコードに対して字(4) コードクローンの追跡：コードクローンの追跡処

句解析，構文解析を行い，STEP2 でブロックの種類，条理では，最初のリビジョンに含まれるすべてのコード片

件式，シグネチャ，クラス名を特定する．ブロックとは，のハッシュ値を比較し，同じハッシュ値を持つコード片

クラスやメソッド，for 文や if 文などのブロック文を指の集合をクローン集合としてまとめ，以降のリビジョン

す．ブロック単位でコード片を特定した後，最初のリビでのクローン集合の前後関係を特定できるようにする．

ジョンを起点として以降のリビジョンを構成するファイ

具体的には，以下の方法でクローン集合の前後関係を特ルについてもコード片を順次特定する．このとき，最初定しクローン集合をリビジョン間で追跡する（図 4）．

のリビジョン以降のリビジョンでは，ファイルの変更情

まず，次の子リビジョンに存在しているクローン集合

報に基づいて，変更が加えられたファイル（図 3 のコーに含まれるコード片のハッシュ値を調べ，直前のリビジョ

ド片特定対象ファイル）のみに対してコード片を特定し，ンのクローンのハッシュ値と比較する．ハッシュ値が一変更がなかったファイルのコード片は前のリビジョンの致した場合は，前のリビジョンに存在するクローン集合

コード片情報を再利用する．

と同じクローン集合であるので要素数を前後のリビジョ(3) コードクローンの特定：前述の前処理により，すべてのリビジョンに対してブロック単位ですべてのコーンで比較する．要素数の増加によるものか，ハッシュ値が変化しない変数名やリテラルの変更によるものかを判

122

SEA

ソフトウェア・シンポジウム2017 in 宮崎

下の処理によって実現している．

W
5HY 









(1) 開発者の特定処理：クローンの作成・利用過程に関与した開発者を作成者（オリジナルのクローンを作成ࡠ੔ं

5HY 










ཤ༽ं

5HY 



した開発者）
・利用者（既存のクローンを他の場所に移植した開発者）
・変更者（ハッシュ値の変更を伴わないクรߍं

ローンに対する変更をおこなった開発者）
・削除者（ファ5HY 



5HY 



イルの削除などによりクローンを削除した開発者）の 4

ࡡঈं





種類に分けて特定し，リビジョンと紐づける（図 5）．

ࡡঈं(2) 不具合混入リビジョンとファイルの特定処理：これまで紹介した機能はすべて Git リポジトリから得られ5HY 1ຎྭ৿‫و‬έϫʖϱॄ߻ࡡঈ͠Ηͪέϫʖϱॄ߻รߍέϫʖϱॄ߻ร਼໌͵ʹรԿ

รߍέϫʖϱॄ߻གྷો਼รԿ

る情報に基づいた処理であり，クローンの作成・利用過程に関与した開発者が混入した不具合に関する情報は別ʀࣰત໾һͳ఼ત໾һͺέϫʖϱ௧੽ͳέϫʖϱ௧੽ࣨഌΝනͤ

途，不具合管理システム（Bugzilla や Jira など）から

図 5: コードクローンの追跡と開発者の分類（リビジョンの親子関係は図 1 と同じ）取得する必要がある．本ツールには，SSZ アルゴリズム[11] を用いて不具合混入コミットを特定し，不具合を混入した開発者を分析する機能を実装してる．
別後，前のリビジョンのクローン集合を親集合，次のリ
ビジョンのクローン集合を子集合と解釈し，クローン集(3) コードクローンと不具合紐づけ処理：本ツールで行ったコードクローン追跡処理と不具合混入リビジョン

合間にリンクを張る．ハッシュ値だけの比較では追跡漏とファイルの特定処理の結果から得られる開発者と不具れが起きてしまうため，ハッシュ値の比較でリンクを張合の関係を用いて，コードクローンと不具合を紐づけるることができなかったクローン集合に対して [8] で用いらことによって，クローン・人・不具合の紐付けできる．

れている手法と同様に CRD の類似度比較（CRD はコー
ド片のブロックの種類やソースコードにおける位置情報

分析：開発者のインタラクションとソフト
ウェア品質

3

を含む表記形式で，この文字列が類似するかを比較）によってクローン集合間にリンクを張る．リンクが張られることがなかったクローン集合は，新たなクローン集合

本章では，コードクローン変更過程における開発者のが作成されたものと解釈し，該当クローン集合を以降のインタラクションとソフトウェア品質の関係を調べるた

リビジョンでの追跡対象とする．最後に，前のリビジョ

めに CCT を用いて行う分析と，分析で用いたデータセッ

ンにのみ存在するクローン集合は削除されたものと解釈

トについて述べる．

して追跡対象から除外する．
従来の追跡ツールである ECTEC[8] では全てのコード

3.1

目的

片に対してリンクを張ることによって，コードクローンの追跡を行っていた．本ツールではコードクローンのみ

ファイルの作成・変更に関与する開発者と品質を分析にリンクを張ることによってコードクローンの追跡を実した研究 [3, 2] から，開発者のインタラクションとソフ現しているので，コードクローンとは関係のないコード

トウェア品質には密接な関係があることが知られている．

片の追跡判定処理をする必要がなくなり，コードクロー

例えば文献 [3] では，安定して成長している OSS 開発プンの追跡にかかる処理時間を削減できる．

ロジェクトでは潜在的に密なコミュニティが存在しており，そのコミュニティに属する開発者同士が同じファイ

2.2

コードクローン分析機能

ルの変更に関与していることを明らかにしている．すな
わち，特定の開発者からなるグループでの密なインタラ

CCT はコードクローン追跡機能に加えて，コードク
ローンの作成・利用に関与した開発者とコードクローン

クションがソフトウェア品質に寄与することを示唆するの品質との関係を時間を遡って分析するための機能を以変更されてきたファイルよりも多数の開発者によって変ものである．一方，文献 [2] では，一人の開発者によって

123

SEA

ソフトウェア・シンポジウム2017 in 宮崎

更が加えられてきたファイルの方が欠陥が含まれやすい(2) 開発者の特定：次に，各コードクローンを変更（追加，修正，削除）した開発者の情報を CCT の処理結果から取り出す．

ことを明らかにしている．文献 [3] とは反対の結果ではなく，開発者の疎なインタラクションを通じて同一ファイルに対する変更が行われるとソフトウェア品質の低下(3) ネットワーク情報の作成：(1), (2) の情報を用いを招くということを示唆したものである．

てコードクローンとコードクローンの変更に関与した開これらの研究成果は，ファイル単位での分析によりファ発者を紐付け，Pajek 形式のネットワークデータを作成

イルの作成・変更に関与した開発者とソフトウェア品質する．

の関係を示したものであった．そこで本稿では，コード(4) コードクローンと開発者の関係の可視化：(3) にクローン単位の分析でも同様の結果を導くことができる

より Pajek を用いてコードクローンと開発者の関係を無のかどうかを確かめることを目的とする．コードクロー

向グラフとして可視化する．

ンとソフトウェア品質の関係については多数の研究がとって有害である場合とそうでない場合が混在しており，(5) 開発者のインタラクションの可視化：さらに，(4)から同一クローンの変更に関与した開発者のみを紐づけることにより開発者のインタラクションを無向グラフと統一的なコンセンサスは未だ得られていない．さらに，

して可視化する．

存在しているが，コードクローンがソフトウェア品質に

コードクローン変更過程における開発者とソフトウェア

3.3

品質の関係について調べた研究はまだ多くないため，既

データセット

存研究では示されていないコードクローンの長期的な本稿では，GitHub3 で活発に活動を行なっている 3

メンテナンスのための新たな知見を提供できる可能性がつのオープンソース開発プロジェクト（RxJava, c:geo,

ある．

3.2

Jackson databind）を対象として分析を行う．RxJava はリアクティブプログラミングを支援するライブラリであ

分析方法

る．c:geo は Android 向けの GPS 機能を使ったゲーム
本稿では，コードクローン変更過程における開発者のアプリケーションである．Jackson databind は JSONのインタラクションを Pajek2 により可視化し分析する．

形式のデータを扱うことを支援するライブラリである．

Pajek とは人と人，人とモノの関係などをネットワーク
として表現し分析するためのネットワーク分析ツールの1 つである．分析では，課題管理システムに報告された

表 1 に各プロジェクトの基本統計量を示す．

課題 (Issue) に関係しているコードクローン（Issue 混入

開発者の数と Issue 未混入クローンの変更に関与（Issue

クローン）と Issue 解決のためにコードクローンの変更とは関連のない理由でコードクローンを変更）した開に関与した開発者との関係を Pajek により可視化する．

発者の数を指す．プロジェクト間でばらつきがあるもの

表 1 中の「Issue 混入 CC 変更」，
「Issue 未混入 CC 変更」とはそれぞれ，Issue 混入クローンの変更に関与した

また，対比のため，Issue の解決とは全く関係のないコーの，プロジェクトの開発者の約 1 割〜3 割程度がコード

ドクローン（Issue 未混入クローン）とその変更に関与

クローンの変更に関与していることが見て取れる．なお，した開発者との関係を可視化する．すなわち，品質に問題のあるコードクローンの変更に関与した開発者のイン

Github では Issue の種類をプロジェクト毎に自由に定義するタグで管理する仕様になっておりプロジェクト間

タラクションと，品質に問題のないコードクローンの変に共通のタグが存在しないため，本データセットにおけ更に関与した開発者のインタラクションとを比較する．

る Issue には不具合に関するものから機能拡張（エンハ

具体的には以下の手順で分析を行う．

ンスメント）に関するものまで含まれている．特定の種(1) Issue 混入クローンと未混入クローンの分別：まず類の課題のみを指すものではないことに注意されたい．

初めに，CCT の処理結果から得られる情報を基に，Issue

Issue の種類を厳密に区別するためにはすべての Issue をと紐づいた Issue 混入クローンと，Issue と紐づいていな

目視する必要があるため，本データセットでは区別しな

い Issue 未混入クローンとに分ける．

いこととしたが，分析結果に影響を与える可能性があり本研究の今後の課題とする．

2 Pajek, http://vlado.fmf.uni-lj.si/pub%20/networks/pajek/

3 https://www.github.com/

124

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1: 対象プロジェクトの統計量

プロジェクト名

RxJava

c:geo

対象期間

2014/08/30∼2016/06/29

2011/07/11∼2016/07/21

2011/12/23∼2016/07/21

1,397

9,821

3,260

73
18

107
28

114
17

リビジョン数
開発者総数
開発者数（人）(∗)

コードクローン（セット数）

Issue 数（件）

Issue 混入 CC 変更者

Jackson databind

Issue 未混入 CC 変更者

17

27

11

CC 合計
Issue 混入 CC

289
104

2,660
2,008

1,610
1,223

Issue 未混入 CC

185

652

387

Issue 合計
CC 関連有 Issue

1,892
35

5,849
405

1,307
241

CC 関連無 Issue

1,857

5,444

1,066

(∗) 開発者総数とは，プロジェクトでコードを変更したことのあるすべての開発者の数である．直下の 2 項目（Issue 混入/未混入 CC 変更）はコードクローン (CC) の変更に関与した開発者の数を示すもので，それら 2 項目の合計とはプロジェクト全体の開発者の合計は一致しない．

表 1 中，「Issue 混入 CC」，
「Issue 未混入 CC」とはそれ分析結果と考察

4

ぞれ，変更されたコードクローンの内，Issue が混入していたものと未混入だったもの数を意味している．それぞ

本章では，前章で述べたデータセットに対して Pajek

れを足し合わせたものが合計と一致する．なお，コードを用いて可視化した開発者のインタラクションをプロ

クローンは，クローンとなっているコード片の総数ではジェクト毎に示し結果を考察する．

なくクローン関係にあるコード片集合（セット数）を示

4.1

すものである．コードクローンはリビジョン数の違いを考慮してもプロジェクト間で大きな差異があることがわ

Pajek で可視化した開発者のインタラクションを可視化した結果を図 6〜図 11 に示す．すべての可視化結果
において，赤色のノードは Issue 混入クローンを，緑色かる．特に，c:geo では 2,008 セットの Issue 混入クローンが存在しており，コードクローンに対する変更の多く
は Issue に関連したものである．Jackson databind も同のノードは Issue 未混入クローンを表す．黄色のノード

様に，コードクローンの変更の多くは Issue に関連してが開発者である．

いることが見て取れる．

図 6, 8, 10 は，コードクローンを変更した開発者と変表 1 中，「CC 関連有 Issue」，「CC 関連無 Issue」と更されたコードクローンの間をエッジで結び，コードク

はそれぞれ，報告された Issue を解決するためにコードクローンの変更を伴ったものとコードクローンの変更
は伴わなかったものを意味している．それぞれを足し合

概要

ローンとコードクローンの変更に関与した開発者の関係（開発者とコードクローンのインタラクション）を，Issue
混入クローンと Issue 未混入クローンとで対比できるよ

わせたものが Issue 合計と一致する．RxJava について

うに可視化したものである．

は，報告された Issue に占める CC 関連有 Issue は少な

図 7, 9, 11 は，図 6, 8, 10 のグラフから，同じコード

い (35/1,892) が，c:geo および Jackson databind につクローンを変更したことのある開発者間をエッジで結び，いては比較的多くの Issue がコードクローンの変更に関

コードクローンの変更に関与した開発者同士の関係（開係していることが見て取れる．

発者間のインタラクション）のみを抽出し可視化したものである．開発者とコードクローンのインタラクションと同様に，Issue 混入クローンと Issue 未混入クローン

125

SEA

ソフトウェア・シンポジウム2017 in 宮崎(a) Issue 混入（密度：0.603）(b) Issue 未混入（密度：0.394）

図 6: コードクローンと開発者の関係 (RxJava)(a) Issue 混入（密度：0.614）(b) Issue 未混入（密度：0.529）

図 7: 開発者の関係 (RxJava)とで対比できるようにしている．開発者間のインタラク

ドクローンの変更に関与していることが分かる．

ションは，開発者同士が同じコードクローンを共同で作一方，図 7 からは Issue 混入クローン数 (104) は Issue

成・変更・利用したことを意味する．つまり，図 7, 9, 11

未混入クローン数 (185) よりも少ないにもかかわらず，のグラフが密になっているということは，開発者同士が

図 7(a) の方が若干ではあるが密な構造になっているこ

同じコードクローンを共同で作成・変更・利用したこととが分かる．コードクローンは開発担当者の異なる複が多いということを示している．各グラフの密度はある数のファイルに散在していることが多いが，いずれかのグラフの辺の数とそのグラフの可能な辺の数の最大数でファイル中のコードクローンを変更した場合にはその他割ったものである．

のファイル中のコードクローンも変更する必要が生じや次節では，これらの可視化結果をプロジェクトごとにすい．特に Issue 混入クローンでは，コードクローンの

考察する．

4.2

変更により Issue を混入させる，あるいは，Issue を解決するためにコードクローンを変更する必要があるため，

RxJava

コードクローンを含むファイル間の依存関係が Issue 未

表 1 より，RxJava は他の 2 プロジェクトに比べて変混入コードクローンの変更よりも強く現れやすいものと更されたクローンセット数（CC 合計: 289, Issue 混入考えられる．結果的に，Issue 混入クローンの変更に関

CC: 104, Issue 未混入 CC: 185）が少ないことが分かる．

与した開発者同士のインタラクションは，Issue 未混入

図 6 からも変更されたコードクローンの数に違いがある

クローンの変更に関与した開発者同士のインタラクショ

ものの，開発者とコードクローンのインタラクションのンよりも密になるものと思われる．

基本構造に大きな違いがないことが見て取れる．実際，
図 6(a), (b) のどちらも 5, 6 名の開発者が数多くのコー

126

SEA

ソフトウェア・シンポジウム2017 in 宮崎(a) Issue 混入（密度：0.891）(b) Issue 未混入（密度：0.333）

図 8: コードクローンと開発者の関係 (c:geo)(a) Issue 混入（密度：0.597）(b) Issue 未混入（密度：0.351）

図 9: 開発者の関係 (c:geo)

4.3

Issue 混入クローンを変更する場合の方が開発者同士のc:geo

インタラクションが密になっていることが分かる．Issue

表 1 より，c:geo は他の 2 プロジェクトに比べてリビ未混入クローンの変更では，Issue 混入クローンの変更

ジョン数が最も多く，変更されたクローンセット数（CC
合計: 2,660, Issue 混入 CC: 2,008, Issue 未混入 CC: 652）が非常に多いことが分かる．一方，コードクローンの変とは異なり数名の開発者がより多くの繋がり（エッジ）を持っているが全体としては比較的疎な構造担っていることが分かる．

更に関与した開発者自体は十数名多い程度（Issue 混入

CC 変更者: 28, Issue 未混入 CC 変更者：27）であるため，
図 8 のグラフではコードクローンのノードとそのエッジがグラフ要素の大半を占める．その結果，開発者とコー

4.4

Jackson databind

表 1 より，Jackson databind のリビジョン数 (3,260)
は c:geo (9,821) の 1/3 程度であることが分かる．一方，ドクローンのインタラクションの詳細を読み取ることがIssue 混入 CC および CC 関連有 Issue は 1/2 程度である

できないが，少なくとも少数の開発者が多数の Issue 混

ため，Jackson databind におけるソースコードの変更は入/未混入クローンの変更に関与していることは見て取

3 つのプロジェクトの中で最もコードクローンの変更にれる．RxJava と同様，少数の中心的な開発者がコードよるものであることが読み取れる．図 10 からは，Issue

クローンの変更において重要な役割を担っていると思わ混入クローンの変更では 2 名，Issue 混入クローンの変れる．

更では 1 名の開発者がほとんどのコードクローンの変更

図 9 からは，コードクローンの変更に関与した開発者に関与していることが分かる．

の数はほぼ同じであるが，Issue 混入クローン数 (2,008)
が Issue 未混入クローン数 (652) よりも相当多いため，

127

図 11 からも，同様のことが見て取れる．Jackson

databind では，1,2 名の中心的な開発者が作成したソー

SEA

ソフトウェア・シンポジウム2017 in 宮崎(a) Issue 混入（密度：0.855）(b) Issue 未混入（密度：1.223）

図 10: コードクローンと開発者の関係 (Jackson databind)(a) Issue 混入（密度：0.235）(b) Issue 未混入（密度：0.231）

図 11: 開発者の関係 (Jackson databind)

スコードには多くのコードクローンが含まれており，そ社会ネットワーク分析ツール Pajek によって可視化しの他の開発者がそれらコードクローンを利用した結果をた結果，以下の知見が得られた．

表しているものと思われる．Jackson databind において
も，Issue 混入クローンの変更の場合の方が 2 名以外の開発者のインタラクションも若干密な構造になっている．

Issue 未混入クローンの変更の場合は，1 名の開発者のみが全ての開発者とインタラクションが存在する構造になっており，他の開発者同士の繋がりはほとんど存在し• いずれのプロジェクトにおいても少数の開発者のみ
がコードクローンの編集の大多数に関与しており，Issue の存在の有無に関わらず各プロジェクトにおける開発者とコードクローンのインタラクションの全体構造に大きな違いはなかった（図 6, 8, 10）．
• Issue 混入クローンの変更に関与した開発者同士のインタラクションは比較的密な構造になる（図 7, 9,

ない．

本稿では，コードクローンの編集過程における開発11），すなわち，コードクローンに何らかの問題がありそれを解決するためには多くの利害関係者の協力を必要とする．問題のあるコードクローンの編集者のインタラクションとソフトウェア品質の関係を理解

は多数のソースコードの変更という観点だけではな

する事を目的として，我々が提案しているコードクロー

く，それぞれの担当者との調整や協力という観点か

ン追跡ツール CCT (Code Clone Tracer) を用いて，3らも影響範囲がより大きくなる可能性がある．

つのオープンソース開発プロジェクト（RxJava, c:geo,

本稿では，CCT の処理結果をもとに社会ネットワー

Jackson databind）を対象とした社会ネットワーク分析を行った．

ク分析を行ったが，まだ基本的な分析を終えた段階であ

5. まとめと今後の課題

り，より有益な知見を提供するためには今後はさらに分

128

SEA

ソフトウェア・シンポジウム2017 in 宮崎

析を精錬する必要がある．本研究の今後の課題としては[3] C. Bird, D. Pattison, R. D’Souza, V. Filkov, and P. Devanbu. Latent social structure in open source projects.
In Proc. of the 16th ACM SIGSOFT Int’l Symp. on
Foundations of Software Engineering (FSE ’08), pp.
24–35, 2008.

以下のようなものが挙げられる．

• Issue の種類を分別する（本稿では不具合なのか機能拡張なのか等を区別していない）．

[4] E. Duala-Ekoko and M.P. Robillard. Clone region descriptors: Representing and tracking duplication insource code. ACM Trans. on Software Engineering andMethodology (TOSEM), Vol. 20, No. 1, pp. 3:1–3:31,
2010.

• Issue の内容を識別するとともに変更されたコード
クローンの内容を分析する（本稿では Issue の内容
やコードクローンの変更内容を詳細に把握しておらずコードクローンの変更理由は不明なままである）．

• Issue の内容を識別する（本稿では Issue の内容を詳細に把握していないのでコードクローンの変更理[5] S. Ducasse, M. Rieger, and S. Demeyer. A language
independent approach for detecting duplicated code.
In Proc. of the IEEE Int’l Conf. on Software Maintenance (ICSM ’99), pp. 109–118, 1999.
[6] N. Göde and R. Koschke. Frequency and risks ofchanges to clones. In Proc. of the 33rd Int’l Conf. on
Software Engineering (ICSE ’11), pp. 311–320, 2011.

由は不明なままである）．

• ファイル単位の従来の分析結果 [3, 2] と比較して，
コードクローンの編集過程においてのみ特徴的な現象を抽出する（本稿ではファイル単位での分析は[7] J. Harder. How multiple developers aﬀect the evolutionof code clones. In Proc. of the 2013 IEEE Int’l Conf. on
Software Maintenance (ICSM ’13), pp. 30–39, 2013.
[8] Y. Higo, K. Hotta, and S. Kusumoto. Enhancementof crd-based clone tracking. In Proc. of the 2013 Int’lWorkshop on Principles of Software Evolution (IWPSE ’13), pp. 28–37, 2013.

行っていないため，前述の知見はコードクローンの変更に関してのみ観察される事象でない可能性がある）．

[9] E. Juergens, F. Deissenboeck, B. Hummel, and S. Wagner. Do code clones matter? In Proc. of the 31st Int’l
Conf. on Software Engineering (ICSE ’09), pp. 485–
495, 2009.

• 開発者とコードクローンのインタラクションを時系列に可視化する（本稿では，過去のデータを一度に可視化しているためコンテキストが失われている）．

• 分析対象とする OSS プロジェクトデータを増やす，
あるいは，企業のプロジェクトデータを対象にする（本稿では，Github 上の 3 つの OSS プロジェクトを対象にしたのみ）．

謝辞[10] T. Kamiya, S. Kusumoto, and K. Inoue. Ccfinder: A
multilinguistic token-based code clone detection system for large scale source code. IEEE Transactions
on Software Engineering (TSE), Vol. 28, No. 7, pp.
654–670, 2002.
[11] J. Śliwerski, T. Zimmermann, and A. Zeller. When dochanges induce fixes? In Proc. of the 2005 Int’l Workshop on Mining Software Repositories (MSR ’05), pp.
1–5, 2005.
[12] 大平雅雄, 久木田雄亮. コードクローンの作成・利用過程における人的影響を調査するための追跡ツールの試作.
情報処理学会 ソフトウェア工学研究会, 第 2016-SE-193
巻, pp. 1–25, 7 2016.

本研究の一部は，文部科学省科学研究補助金（基盤(C): 15K00101）による助成を受けた．

[13] 堀田圭佑, 楊嘉晨, 肥後芳樹, 楠本真二. 粗粒度なコード
クローン検出手法の精度に関する調査. 情報処理学会論文誌, Vol. 56, No. 2, pp. 580–592, 2015.

参考文献[14] 堀田圭佑, 肥後芳樹, 楠本真二. Crd を用いたコードク
ローンの生存期間と修正回数に関する調査. 情報処理学
会論文誌, Vol. 55, No. 2, pp. 947–958, 2013.

[1] I.D. Baxter, A. Yahin, L. Moura, M. Sant’Anna, and
L. Bier. Clone detection using abstract syntax trees.
In Proc. of the Int’l Conf. on Software Maintenance(ICSM ’98), pp. 368–377, 1998.

[15] 堀田圭佑, 肥後芳樹, 楠本真二. 生成抑止，分析効率化，不具合検出を中心としたコードクローン管理支援技術に関する研究動向. コンピュータソフトウェア, Vol. 31, No. 1,
pp. 14–29, 2014.

[2] C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu. Don’t touch my code!: Examining the eﬀects
of ownership on software quality. In Proc. of the Joint
Meeting of the European Software Engineering Conf.
and the ACM SIGSOFT Symp. on the Foundationsof Software Engineering (ESEC/FSE ’11), pp. 4–14,
2011.

[16] 久木田雄亮, 大平雅雄. コードクローンの編集過程における開発者の潜在的社会構造に関する分析. 2016 年度情報処理学会関西支部大会 支部大会講演論文集, 第 2016 巻,
9 2016.

129

SEA