JP7116313B2 - 修正候補特定プログラム - Google Patents

Description

本発明は、修正候補特定プログラムに関する。

ソフトウェア開発においては、「技術的負債(technical debt)」と呼ばれるコードが作成されてしまうことがある。技術的負債は、主に「ソフトウェアの動作としては仕様を満たしているが、後に修正することが予想されるコード」を指す。例えば変数の命名規則などの開発規約を満たしていないコードや、簡素に記述できるはずなのに過度に複雑な記述となっているコードや、可読性が低いコードなどが、技術的負債である。技術的負債の発生要因としては、コードの品質よりもリリース時期を優先するという優先度の判断によるものや、個々の開発者のスキルの差異などが挙げられる。

このような技術的負債は、コードの保守性を下げる要因となる。例えば技術的負債は、バグの要因になりやすかったり、トラブルシューティングの長期化を招いたり、機能拡張時のコード理解の妨げになったりする。そのため技術的負債は事前に取り除くことが望ましい。技術的負債を解消するためには、対象のコードに対して、その入出力を変化させずに、可読性向上や開発規約準拠を満たすための修正を行う。このようなコードの清書作業は「リファクタリング(refactoring)」と呼ばれる。

コードの修正を支援する技術としては、例えばソフトウェア技術者や技術者の属する会社のコーディング能力を客観的に評価することができるソースコード評価システムが提案されている。

またＪａｖａ（登録商標）ソースコードの品質に影響を与える事項について、プログラム作成者毎の傾向を把握することができる品質チェックプログラムも提案されている。また、リファクタリングが必要ない複雑なソースコードを抽出せず、真にリファクタリングが必要なソースコードを特定する効率的なプログラム分析方法も提案されている。さらに、ソースコードに含まれる不具合の効率的な修正や分析を可能にする支援装置も提案されている。

特開２００６－５９２７６号公報 特開２０１１－２５８０７６号公報 特開２０１６－１４３１０７号公報 特開２０１７－１５１５９４号公報

現状では、リファクタリングを行う場合、コード修正を行う技術者は、コードを目視ですべて精査して、技術的負債箇所の候補を見つける。そして技術者は、技術的負債箇所の候補の内容をより詳細に確認し、技術的負債に該当するか否かを判断する。しかし、技術者による目視の調査では、膨大なソフトウェアのコードの中からリファクタリング対象となる技術的負債箇所の候補を短時間で特定するのは困難である。

１つの側面では、本件は、技術的負債箇所を容易に特定できるようにすることを目的とする。

１つの案では、コンピュータに以下の処理を実行させる修正候補特定プログラムが提供される。
まずコンピュータは、ソースコードに対して実行された複数の修正処理ごとに、修正処理により削除された削除コード、修正処理により追加された追加コード、および修正処理に関する属性を示す属性情報を含む修正記録を記憶部に格納する。次にコンピュータは、複数の修正処理それぞれの修正記録に示される削除コードと追加コードとを比較し、複数の修正処理のうち、処理の入出力を変えずに部分コードを修正するリファクタリングを行った第１修正処理を特定する。次にコンピュータは、第１修正処理の第１修正記録に基づいて、第１修正処理によって削除された削除コードを追加コードに含む第２修正処理を特定する。次にコンピュータは、第２修正処理の第２修正記録に示される属性情報に基づいて、リファクタリング候補とする部分コードの属性を示す被疑属性を決定する。そしてコンピュータは、被疑属性を有する被疑修正処理によってソースコードに追加され、ソースコードに残存している部分コードを、リファクタリング候補として出力する。

１態様によれば、技術的負債箇所を容易に特定可能となる。

第１の実施の形態に係るコンピュータの一例を示す図である。 修正候補特定方法の一例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 サーバのハードウェアの一構成例を示す図である。 ソーシャルコーディングを説明する図である。 サーバの機能を示すブロック図である。 コードリポジトリの一例を示す図である。 コード修正履歴管理テーブルの一例を示す図である。 マスタコード管理テーブルの一例を示す図である。 コード属性情報管理テーブルの第１の更新例を示す図である。 コード属性情報管理テーブルの第２の更新例を示す図である。 コード属性情報管理テーブルの第３の更新例を示す図である。 コード開発時の処理手順の一例を示すフローチャートである。 リファクタリング対象特定処理を示す第１の例である。 リファクタリング対象特定処理を示す第２の例である。 リファクタリング対象情報の一例を示す図である。 被疑作成者の特定例を示す図である。 被疑期間の特定例を示す図である。 リファクタリング候補の抽出例を示す図である。 被疑コード属性の論理積を採用した場合と論理和を採用した場合との出力結果の違いを示す図である。 リファクタリング候補抽出処理の手順の一例を示すフローチャートである。 リファクタリングコードとリファクタードコード特定処理の手順の一例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。第１の実施の形態は、修正候補となる技術的負債箇所を自動で特定する修正候補特定方法を、コンピュータを用いて実現するものである。

図１は、第１の実施の形態に係るコンピュータの一例を示す図である。図１には、修正候補となる技術的負債箇所を自動で特定する修正候補特定方法を実施するコンピュータ１０を示している。コンピュータ１０は、例えば修正候補特定方法の処理手順が記述された修正候補特定プログラムを実行することにより、修正候補特定方法を実施することができる。

コンピュータ１０は、修正候補特定方法を実現するために、記憶部１１と処理部１２とを有する。記憶部１１は、例えばコンピュータ１０が有するメモリ、またはストレージ装置である。処理部１２は、例えばコンピュータ１０が有するプロセッサ、または演算回路である。

記憶部１１には、修正対象のソースコード１が格納されている。ソースコード１には、１以上のコマンド行が含まれる。コマンド行の中には、そのコマンド行を実行する時点で成立していることが期待される条件式を示すテストコードが含まれる場合がある。テストコードは、ソースコード１の一部である部分コードについて、入力値または出力値が適切か否かを判定するのに使用される。ソースコード１の実行過程において、テストコードで値が適切であると判定された場合、ソースコード１の実行が継続される。他方、ソースコード１の実行過程において、テストコードで値が不適切であると判定された場合、ソースコード１の実行が終了する。

また記憶部１１は、ソースコード１に対する修正履歴２を記憶することができる。修正履歴２は、ソースコード１に対して修正処理を行ったときの修正内容を示す修正記録２ａ～２ｃを時系列に並べたものである。

各修正記録２ａ～２ｃには、例えば変更ＩＤ、適用日時、作成者、追加コード、および削除コードが含まれる。変更ＩＤは、修正処理の識別子である。適用日時は、修正処理を行った日時である。なお図１の例では、日時として日付のみを示し時刻については省略している。以下の説明においても、日時を示す情報のうち時刻を省略する場合がある。作成者は、修正によって追加したコード（追加コード）を作成した開発者の名称である。追加コードは、修正処理によってソースコード１に追加された１以上のコマンド行である。削除コードは、修正処理によってソースコード１から削除された１以上のコマンド行である。なお、修正記録２ａ～２ｃに含まれる情報のうち、適用日時と作成者は、修正処理に関する属性を示す属性情報の一例である。

コンピュータ１０の処理部１２は、ソースコード１への修正処理に応じた修正履歴２を作成すると共に、修正履歴２に基づいて、修正候補となる技術的負債箇所を自動で特定する。

図２は、修正候補特定方法の一例を示す図である。例えばソースコード１には、２度の修正処理が行われているものとする。図２では、ソースコード１の第１版のときの内容をソースコード１ａとし、ソースコード１の第２版のときの内容をソースコード１ｂとし、ソースコード１の第３版のときの内容をソースコード１ｃとしている。

例えば第１版のソースコード１ａを開発者「Ｃｏｄｅｒ Ａ」が作成し、２０１８年１月５日にコンピュータ１０に登録したものとする。この場合、コンピュータ１０の処理部１２は、登録されたソースコード１ａ内のすべてのコマンド行を新たに追加する修正処理と認識し、その修正処理を表す修正記録２ａを、修正履歴２に登録する。登録した修正記録２ａには、変更ＩＤ「Ｃ００１」、適用日時「２０１８．１．５」、作成者「Ｃｏｄｅｒ Ａ」が含まれる。また修正記録２ａの追加コードには、ソースコード１ａにすべてのコマンド行が含まれる。

次に第１版のソースコード１ａを開発者「Ｃｏｄｅｒ Ｂ」が修正し、２０１８年１月６日に修正後の第２版のソースコード１ｂをコンピュータ１０に登録したものとする。この場合、処理部１２は、ソースコード１ａをソースコード１ｂに修正する修正処理を表す修正記録２ｂを、修正履歴２に登録する。登録した修正記録２ｂには、変更ＩＤ「Ｃ００２」、適用日時「２０１８．１．６」、作成者「Ｃｏｄｅｒ Ｂ」が含まれる。また修正記録２ｂの追加コードには、ソースコード１ｂに新たに追加されたコマンド行が含まれ、削除コードには、元のソースコード１ａから削除されたコマンド行が含まれる。

次に第２版のソースコード１ｂを開発者「Ｃｏｄｅｒ Ｃ」が修正し、２０１８年１月９日に修正後の第３版のソースコード１ｃをコンピュータ１０に登録したものとする。この場合、処理部１２は、ソースコード１ｂをソースコード１ｃに修正する修正処理を表す修正記録２ｃを、修正履歴２に登録する。登録した修正記録２ｃには、変更ＩＤ「Ｃ００３」、適用日時「２０１８．１．９」、作成者「Ｃｏｄｅｒ Ｃ」が含まれる。また修正記録２ｃの追加コードには、ソースコード１ｃに新たに追加されたコマンド行が含まれ、削除コードには、元のソースコード１ｂから削除されたコマンド行が含まれる。

処理部１２は、例えばソースコード１のいずれかの版を指定した修正候補特定要求が入力されると、修正候補特定処理を実行する。例えば最新の版のソースコード１ｃを指定した修正候補特定要求が入力されたものとする。

修正候補特定要求に応じて、処理部１２は、複数の修正処理それぞれの修正記録２ａ～２ｃに示される削除コードと追加コードとを比較し、複数の修正処理のうち、処理の入出力を変えずにコードを修正するリファクタリングを行った第１修正処理を特定する。例えば処理部１２は、複数の修正処理のうちの一修正処理において削除した削除コードが存在し、かつ一修正処理においてテストコードに変更がない場合に、一修正処理を第１修正処理として特定する。

図２の例では、第１版のソースコード１ａを登録する処理を示す修正記録２ａでは、追加コードは存在するが削除コードが存在しない。すなわち修正記録２ａに対応する修正処理では、新たなコマンド行の追加のみが行われている。追加コードにおいて新たな入出力が発生しているため、処理部１２は、修正記録２ａに示される修正処理は、処理の入出力を変えずにコードを修正するリファクタリングではないと判断する。

第１版のソースコード１ａを第２版のソースコード１ｂに修正する処理を示す修正記録２ｂでは、削除コードが追加コードに変更されている。また削除コードと追加コードとに、テストコードが含まれない。そのため処理部１２は、修正記録２ｂに対応する修正処理は、処理の入出力を変えずにコードを修正するリファクタリングであると判断する。その結果、処理部１２は、修正記録２ｂに示される修正処理を第１修正処理として特定する。

第２版のソースコード１ｂを第３版のソースコード１ｃに修正する処理を示す修正記録２ｃでは、削除コードが追加コードに変更されている。また削除コードと追加コードとに、テストコードが含まれており、テストコードで確認する変数の値が異なっている。そのため処理部１２は、修正記録２ｃに対応する修正処理は、リファクタリングではないと判断する。

第１修正処理を特定後、処理部１２は、第１修正処理の第１修正記録（修正記録２ｂ）に基づいて、第１修正処理によって削除された削除コードを追加コードに含む第２修正処理を特定する。例えば修正記録２ｂには、削除コード「Ｃｏｍｍａｎｄ ２」が登録されている。この削除コードは修正記録２ａの追加コードに含まれている。従って処理部１２は、修正記録２ａに対応する修正処理を第２修正処理として特定する。

第２修正処理を特定後、処理部１２は、第２修正処理の第２修正記録（修正記録２ａ）に示される属性情報に基づいて、リファクタリング候補とする部分コードの属性を示す被疑属性を決定する。例えば処理部１２は、複数の修正処理それぞれの修正記録２ａ～２ｃの属性情報に示される一属性項目の値の、複数の修正処理それぞれの修正記録における出現数に対する、第２修正処理の第２修正記録における出現数の割合を計算する。そして処理部１２は、計算した割合が閾値以上の場合、一属性項目の値を被疑属性に決定する。閾値は、０より大きく１以下の実数である。

なお、属性情報に示される属性項目としては、例えば適用日時や作成者の識別子（例えば作成者の名称）がある。ここで属性項目として作成者の識別子に着目したとき、第２修正記録（修正記録２ａ）に示される作成者の識別子は「Ｃｏｄｅｒ Ａ」である。作成者の識別子「Ｃｏｄｅｒ Ａ」の作成者が修正処理を行ったのは１回のみであり、「Ｃｏｄｅｒ Ａ」の修正記録への出現数は「１」である。また作成者の識別子「Ｃｏｄｅｒ Ａ」の第２修正処理の第２修正記録への出現数も「１」である。すると作成者の識別子「Ｃｏｄｅｒ Ａ」の修正記録への出現数に対する、第２修正記録への出現割合は「１（１００％）」となる。この場合、処理部１２は、作成者の識別子「Ｃｏｄｅｒ Ａ」を被疑属性（被疑作成者）に決定する。

また属性項目として適用日時に着目したとき、第２修正記録（修正記録２ａ）に示される適用日時は「２０１８．１．５」である。処理部１２は、例えば１週間（７日間）単位の期間ごとに、該当期間が被疑属性となるか否かを判断する。「２０１８．１．５」が属する判断対象の期間が「２０１７．１２．３０－２０１８．１．５」の場合、該当期間内に行われた修正処理は１回のみであり、該当期間内の日時の修正記録への出現数は「１」である。また期間「２０１７．１２．３０－２０１８．１．５」内の日時の第２修正処理の第２修正記録への出現数も「１」である。すると期間「２０１７．１２．３０－２０１８．１．５」の修正記録への出現数に対する、第２修正記録への出現割合は「１（１００％）」となる。この場合、処理部１２は、第２修正記録（修正記録２ａ）に示される適用日時は「２０１８．１．５」を含む期間「２０１７．１２．３０－２０１８．１．５」を、被疑属性（被疑期間）に決定する。

被疑属性を決定後、処理部１２は、被疑属性を有する修正処理（被疑修正処理）によって最新版のソースコード１ｃに追加され、ソースコード１ｃに残存している部分コードを、リファクタリング候補として出力する。図１の例では、被疑期間に被疑作成者によって追加されたコマンド文「Ｃｏｍｍａｎｄ １」がリファクタリング候補として出力される。

このようにコンピュータ１０がリファクタリング候補を自動で特定し出力することで、技術的負債箇所を容易に特定可能となる。すなわちリファクタリングを行う開発者は、リファクタリング候補として示されたコマンド行と、そのコマンド行に関連する他の記述を確認することで、技術的負債箇所か否かを判断できる。その結果、例えばソースコード１ｃの全体の記述を確認する場合に比べ、技術的負債箇所の特定が容易となる。

しかも処理部１２はテストコードの変更の有無によって、修正による入出力の変更の有無を判断する。これにより、実行された修正処理がリファクタリングか否かを正しく判断することができる。

さらに処理部１２は、ある属性項目の値についての、第２修正記録への出現割合が閾値以上の場合に、その属性項目の値を被疑属性とする。これにより、技術的負債箇所である可能性が高い部分コードのみを、リファクタリング候補とすることができる。

処理部１２は、作成者の識別子を被疑属性とすることができる。これにより、作成者の能力不足など、作成者に起因して発生した技術的負債箇所を、適確にリファクタリング候補として特定することができる。

また処理部１２は、修正処理の適用日時を含む期間を、被疑属性とすることができる。これにより、例えば開発期限に間に合わせるために最適化を十分に実施することができなかった期間を、被疑属性（被疑期間）とすることができる。これにより、ソフトウェア開発の工程上の都合で除去できなかった技術的負債箇所を、適確にリファクタリング候補として特定することができる。

なお処理部１２は、被疑属性が複数ある場合、例えば複数の被疑属性すべてに対応する属性を有する部分コード（被疑属性の論理積）を、リファクタリング候補として出力する。また処理部１２は、被疑属性が複数ある場合、例えば複数の被疑属性うちの少なくとも１つに対応する属性を有する部分コード（被疑属性の論理和）を、リファクタリング候補として出力してもよい。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ＯＳＳ（Open Source Software）の開発環境において、効率的なリファクタリングを支援するシステムである。

ＯＳＳなどでは、多数の開発者が非同期にかつ並行でソフトウェアを開発する「ソーシャルコーディング」が普及している。現在は、ソーシャルコーディングのためのコードリポジトリサービスも存在する。コードリポジトリサービスでは、コードの提出や承認、議論コメントなどのソーシャルコーディングのための情報交換が、すべてオンラインで実行可能である。一企業内でも、コードリポジトリサービスを行うサーバを設けることで、企業内の開発者間でのソーシャルコーディングを支援している。

図３は、第２の実施の形態のシステム構成例を示す図である。ネットワーク２０を介して、サーバ１００と複数の端末装置３１，３２，・・・とが接続されている。サーバ１００は、ソーシャルコーディング基盤を実現するコンピュータである。端末装置３１，３２，・・・は、ソフトウェアの開発者またはレビュアが使用するコンピュータである。

図４は、サーバのハードウェアの一構成例を示す図である。サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

サーバ１００は、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示したコンピュータ１０も、図４に示したサーバ１００と同様のハードウェアにより実現することができる。

サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

次に、ソーシャルコーディングについて図５を参照して説明する。
図５は、ソーシャルコーディングを説明する図である。ソーシャルコーディング基盤として機能するサーバ１００は、マスタコード１１１を記憶するコードリポジトリ１１０を有している。マスタコード１１１は、正式なバージョンのプログラムのソースコードである。マスタコード１１１は、例えば１つのファイル（ソースファイル）としてリポジトリに格納される。開発者４１は、例えば端末装置３１を用いてサーバ１００にアクセスし、コードリポジトリ１１０内のマスタコード１１１を参照する。開発者４１は、端末装置３１を用いて、マスタコード１１１に対する機能の追加、不具合の修正、またはリファクタリングのための修正コード５１を作成する。そして開発者４１は、端末装置３１に対して、修正コード５１をサーバ１００に送信させる。

送信された修正コード５１は、サーバ１００で保持される。その後、レビュア４２が、例えば端末装置３２を用いて修正コード５１を参照し、レビューする。レビュア４２は、修正コード５１に問題がなければ、端末装置３２を用いて、承認する旨のメッセージをサーバ１００に送信する。サーバ１００は、修正コード５１が承認されると、修正コード５１に示される修正内容を、マスタコード１１１に反映する。

ここで、開発者４１がマスタコード１１１のリファクタリングをする場合、開発者４１はマスタコード１１１の中から、まずリファクタリングの対象とする部分コードを特定する。この際、マスタコード１１１が大規模なプログラムの場合、すべての部分コードを開発者４１が目視で確認して、リファクタリングの対象となる部分コードを特定するのは困難である。そこで、サーバ１００は、マスタコード１１１の中から、リファクタリング対象となる可能性の高い部分コードをリファクタリング候補として抽出する。そしてサーバ１００は、リファクタリング候補を、開発者４１が使用する端末装置３１に送信する。

図６は、サーバの機能を示すブロック図である。サーバ１００は、図５に示したコードリポジトリ１１０以外に、コード修正管理部１２０、リファクタリング対象特定部１３０、被疑属性特定部１４０、コード属性特定部１５０、およびリファクタリング候補抽出部１６０を有する。

コードリポジトリ１１０は、修正によりバージョンが更新されたマスタコードの各バージョンのソースコード、および修正コード５１による修正内容を示す修正記録を記憶する。

コード修正管理部１２０は、マスタコードのコード修正を管理する。例えばコード修正管理部１２０は、開発者またはレビュアが使用する端末装置３１，３２，・・・と通信し、図５に示したようなソーシャルコーディングの一連の手続きを管理する。

リファクタリング対象特定部１３０は、コードリポジトリ１１０に登録されたマスタコードの中から、リファクタリングを目的として追加された部分コードを特定する。例えばリファクタリング対象特定部１３０は、以下の２つの条件を共に満たす修正コードによって修正された修正前の部分コードを、リファクタリング対象として特定する。
・作成された部分コードが別の部分コードによって上書き修正されたこと。
・修正においてテストコードの修正がないこと。

テストコードは、変数の値が想定通りとなっているか否かを確認するために、プログラム中の１つの実現する部分コードの前後に設定される。テストコードは、例えば想定通りの入力値が入力されたか否かの確認、または想定通りの出力値が出力されたか否かの確認に利用される。テストコードの修正がないことは、修正箇所の入出力の仕様に変化がないことを表しており、修正の目的がリファクタリングである可能性が高い。

被疑属性特定部１４０は、例えば、複数のリファクタリング対象の属性（作成者、適用日時など）のうち、高頻度に出現する属性を特定する。例えば被疑属性特定部１４０は、被疑作成者特定部１４１と被疑期間特定部１４２とを有する。

被疑作成者特定部１４１は、リファクタリング対象の属性として高頻度で出現する作成者を、被疑作成者として特定する。被疑作成者は、後にリファクタリング対象となった部分コードを頻繁に作成した開発者であり、該当開発者が作成した未修正の部分コードは、リファクタリング対象である可能性が高い。

被疑期間特定部１４２は、例えばある期間内に実行されたマスタコードの更新処理のうち、後にリファクタリング対象となった部分コードの追加を行った更新処理が高頻度で含まれる場合、その期間を被疑期間として特定する。被疑期間は、後にリファクタリング対象となった部分コードが頻繁に適用された期間であり、該当期間内に適用された未修正の部分コードは、リファクタリング対象である可能性が高い。

コード属性特定部１５０は、マスタコードに含まれる部分コードの属性を特定する。例えばコード属性特定部１５０は、修正時に追加された部分コードについて、その部分コードの作成者、またはその部分コードを適用した日時を特定する。

リファクタリング候補抽出部１６０は、マスタコードからリファクタリング候補とする部分コードを抽出する。例えばリファクタリング候補抽出部１６０は、被疑作成者または被疑期間に該当する属性の部分コードを、リファクタリング候補とする。リファクタリング候補抽出部１６０は、リファクタリング候補を、リファクタリングを行う開発者が使用する端末装置（例えば端末装置３１）に送信する。

なお、図６に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図６に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

次に、コードリポジトリ１１０に格納される情報について詳細に説明する。
図７は、コードリポジトリの一例を示す図である。コードリポジトリ１１０には、コード修正履歴管理テーブル１１２、マスタコード管理テーブル１１３、およびコード属性情報管理テーブル１１４が格納されている。

コード修正履歴管理テーブル１１２は、マスタコードに対して行われた修正記録１１２ａ，１１２ｂ，・・・を管理するためのデータテーブルである。コード修正履歴管理テーブル１１２には、コード修正ごとの修正内容を示す修正記録１１２ａ，１１２ｂ，・・・が登録されている。

マスタコード管理テーブル１１３は、過去に生成されたことのあるマスタコード１１１，１１１ａ，１１１ｂ，１１１ｃ，・・・を管理するためのデータテーブルである。マスタコード管理テーブル１１３には、最初に作成されたマスタコード１１１と、その後の修正によって生成されたマスタコード１１１ａ，１１１ｂ，１１１ｃ，・・・とが登録されている。

コード属性情報管理テーブル１１４は、最新のマスタコード１１１ｃ内のコマンド行ごとの属性（作成者、適用日時など）を管理するためのデータテーブルである。コード属性情報管理テーブル１１４は、マスタコードが修正されるごとに、最新の情報に更新される。

図８は、コード修正履歴管理テーブルの一例を示す図である。コード修正履歴管理テーブル１１２には、変更ＩＤ、適用日時、作成者、追加内容、および削除内容の欄が設けられている。変更ＩＤの欄には、マスタコードに対する修正処理の識別子（変更ＩＤ）が設定される。適用日時の欄には、修正コードがマスタコードに適用された日時が設定される。作成者の欄には、修正によって追加したコードを作成した開発者の名称が設定される。追加内容の欄には、修正コードの適用によってマスタコードに追加された部分コードが設定される。削除内容の欄には、修正コードの適用によってマスタコードから削除された部分コードが設定される。

図９は、マスタコード管理テーブルの一例を示す図である。マスタコード管理テーブル１１３には、バージョン、作成日時、最後に適用された変更ＩＤ、およびコード内容の欄が設けられている。バージョンの欄には、マスタコードのバージョンが設定される。作成日時の欄には、対応するバージョンのマスタコードが作成された日時が設定される。最後に適用された変更ＩＤの欄には、対応するバージョンのマスタコードに最後に適用された修正コードの変更ＩＤが設定される。コード内容の欄には、対応するバージョンのマスタコードの内容が設定される。なお、コード内容の欄には、マスタコードを直接記述するのではなく、マスタコードが記述されたソースファイルを示す情報（ファイルパスとファイル名）を設定することもできる。

図９の例では、バージョン「Ｖ１．０」のコード内容が、最初に生成されたマスタコード１１１である。また、バージョン「Ｖ１．１」、「Ｖ１．２」、「Ｖ１．３」それぞれのコード内容が、修正によって生成されたマスタコード１１１ａ，１１１ｂ，１１１ｃである。

コード属性情報管理テーブル１１４は、マスタコードに対して修正コードが適用されるごとに更新される。以下、図１０～図１２を参照して、コード属性情報管理テーブル１１４の更新内容を説明する。

図１０は、コード属性情報管理テーブルの第１の更新例を示す図である。例えば開発者４３（名称「Ｃｏｄｅｒ Ａ」）が、バージョン「Ｖ１．０」のマスタコード１１１に対する修正コード５１を作成したものとする。開発者４３は、端末装置を用いて、修正コード５１の追加を示す変更要求６１をサーバ１００に送信する。例えば開発者４３は、端末装置を用いて、サーバ１００に対して、ユーザ名「Ｃｏｄｅｒ Ａ」のアカウントでログインする。そして開発者４３は、ログインしたアカウントにより、変更要求６１をサーバ１００に入力する。変更要求６１には、修正コード５１が含まれる。

サーバ１００では、コード修正管理部１２０が、変更要求６１に応じて、修正コード５１の内容をマスタコード１１１に適用する。これにより、バージョン「Ｖ１．１」のマスタコード１１１ａが生成される。バージョン「Ｖ１．１」のマスタコード１１１ａには、修正コード５１に示される部分コードが追加されている。このときコード修正管理部１２０は、修正コード５１を適用する修正処理に対して変更ＩＤを付与する。図１０の例では変更ＩＤ「Ｃ００１」が付与されている。

マスタコード１１１に修正コード５１が適用されると、コード属性特定部１５０がコード属性情報管理テーブル１１４を更新する。コード属性情報管理テーブル１１４には、行番号、コマンド、変更ＩＤ、日時、および作成者の欄が設けられている。行番号の欄には、ソースコード内の各コマンド行の行番号が設定される。コマンドの欄には、対応する行番号のコマンド行の文字列が設定される。変更ＩＤの欄には、対応する行番号のコマンド行が追加された修正処理の変更ＩＤが設定される。日時の欄には、修正コードを適用した日時が設定される。作成者の欄には、修正コードを作成した開発者の名称が設定される。開発者の名称は、例えば変更要求の入力を行ったアカウントのユーザ名である。

例えば修正コード５１の適用前は、コード属性情報管理テーブル１１４には行番号「１」、コマンド「／＊ Ｃａｌｃｕｌａｔｉｏｎ ＊／」のコマンド行のみが存在する。修正コード５１が適用されると、コード属性特定部１５０が、コード属性情報管理テーブル１１４に行番号「２」～「８」のレコードを追加する。各レコードのコマンドの欄には、修正コード５１に示されるコマンド行が設定される。追加されたレコードそれぞれの変更ＩＤは「Ｃ００１」であり、日時は「２０１８．１．５」（２０１８年１月５日）であり、作成者は「Ｃｏｄｅｒ Ａ」である。

図１１は、コード属性情報管理テーブルの第２の更新例を示す図である。例えば開発者４４（名称「Ｃｏｄｅｒ Ｂ」）が、バージョン「Ｖ１．１」のマスタコード１１１ａに対する修正コード５３を作成したものとする。修正コード５３は、マスタコード１１１ａ内の部分コード（削除コード５２）を削除した位置に挿入する部分コードである。この場合、開発者４４は、端末装置を用いて、削除コード５２から修正コード５３への修正を示す変更要求６２をサーバ１００に送信する。変更要求６２には、削除コード５２と修正コード５３とが含まれる。なお変更要求６２には、削除コード５２に代えて、削除コード５２のマスタコード１１１ａ内での行番号が示されていてもよい。

サーバ１００では、コード修正管理部１２０が、変更要求６２に応じて、修正コード５３の内容をマスタコード１１１ａに適用する。すなわちコード修正管理部１２０は、マスタコード１１１ａから削除コード５２に対応するコードを削除し、削除したコードがあった位置に修正コード５３を挿入する。これにより、バージョン「Ｖ１．２」のマスタコード１１１ｂが生成される。このときコード修正管理部１２０は、修正コード５３を適用する修正処理に対して変更ＩＤを付与する。図１１の例では変更ＩＤ「Ｃ００２」が付与されている。

マスタコード１１１ａに修正コード５３が適用されると、コード属性特定部１５０がコード属性情報管理テーブル１１４を更新する。例えば修正コード５３が適用されると、コード属性特定部１５０が、修正前のコード属性情報管理テーブル１１４から行番号「４」～「７」のレコードを削除する。さらにコード属性特定部１５０は、コード属性情報管理テーブル１１４に新たに、修正コード５３に対応する行番号「４」～「５」のレコードを追加する。追加されたレコードのコマンドの欄には、修正コード５３に示されるコマンド行が設定される。追加されたレコードそれぞれの変更ＩＤは「Ｃ００２」であり、日時は「２０１８．１．６」（２０１８年１月６日）であり、作成者は「Ｃｏｄｅｒ Ｂ」である。

図１２は、コード属性情報管理テーブルの第３の更新例を示す図である。例えば開発者４５（名称「Ｃｏｄｅｒ Ｃ」）が、バージョン「Ｖ１．２」のマスタコード１１１ｂに対する修正コード５６，５７を作成したものとする。修正コード５６，５７は、マスタコード１１１ｂ内の部分コード（削除コード５４，５５）を削除した位置に挿入する部分コードである。この場合、開発者４５は、端末装置を用いて、削除コード５４，５５から修正コード５６，５７への修正を示す変更要求６３をサーバ１００に送信する。変更要求６３には、削除コード５４，５５と修正コード５６，５７とが含まれる。なお変更要求６３には、削除コード５４，５５に代えて、削除コード５４，５５のマスタコード１１１ｂ内での行番号が示されていてもよい。

サーバ１００では、コード修正管理部１２０が、変更要求６３に応じて、修正コード５６，５７の内容をマスタコード１１１ｂに適用する。すなわちコード修正管理部１２０は、マスタコード１１１ｂから削除コード５４，５５に対応するコードを削除し、削除したコードがあった位置に修正コード５６，５７を挿入する。これにより、バージョン「Ｖ１．３」のマスタコード１１１ｃが生成される。このときコード修正管理部１２０は、修正コード５６，５７を適用する修正処理に対して変更ＩＤを付与する。図１２の例では変更ＩＤ「Ｃ００３」が付与されている。

マスタコード１１１ａに修正コード５６，５７が適用されると、コード属性特定部１５０がコード属性情報管理テーブル１１４を更新する。例えば修正コード５６，５７が適用されると、コード属性特定部１５０が、修正前のコード属性情報管理テーブル１１４から行番号「４」，「６」のレコードを削除する。さらにコード属性特定部１５０は、コード属性情報管理テーブル１１４に新たに、修正コード５６，５７に対応する行番号「４」，「６」のレコードを追加する。追加されたレコードのコマンドの欄には、修正コード５６，５７に示されるコマンド行が設定される。追加されたレコードそれぞれの変更ＩＤは「Ｃ００３」であり、日時は「２０１８．１．９」（２０１８年１月９日）であり、作成者は「Ｃｏｄｅｒ Ｃ」である。

図１０～図１２に示したような修正処理の内容は、コード修正管理部１２０により、修正記録１１２ａ，１１２ｂ，・・・としてコード修正履歴管理テーブル１１２に登録される。またマスタコードの修正が行われると、コード修正管理部１２０により、新たなバージョンのマスタコードが、マスタコード管理テーブル１１３に登録される。

コード開発時にコード修正履歴管理テーブル１１２、マスタコード管理テーブル１１３、およびコード属性情報管理テーブル１１４は、コード開発過程でコードの修正が行われるごとに更新される。

図１３は、コード開発時の処理手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］コード修正管理部１２０は、開発者が使用する端末装置から、マスタコードの変更要求を受信する。

［ステップＳ１２］コード修正管理部１２０は、変更要求に示されるコード修正に対応する修正記録を、コードリポジトリ１１０に保存する。例えばコード修正管理部１２０は、コード修正履歴管理テーブル１１２に、新たな変更ＩＤを付与したレコードを追加する。コード修正管理部１２０は、追加したレコードの適用日時として、現在の日時を設定する。またコード修正管理部１２０は、追加したレコードの作成者として、変更要求を送信した開発者の名称を設定する。またコード修正管理部１２０は、追加したレコードの追加内容として、変更要求に示される修正コードを設定する。さらにコード修正管理部１２０は、変更要求において削除コードが示されている場合、追加したレコードの削除内容として、変更要求に示される削除コードを設定する。

［ステップＳ１３］コード修正管理部１２０は、変更要求に応じた修正内容を、マスタコードに反映する。例えばコード修正管理部１２０は、マスタコード管理テーブル１１３から、最新のバージョンのマスタコードのコード内容を取得する。コード修正管理部１２０は、取得したコード内容に対して、変更要求に応じた修正（部分コードの削除または部分コードの追加）を行う。

［ステップＳ１４］コード修正管理部１２０は、修正後のマスタコードをコードリポジトリ１１０に保存する。例えばコード修正管理部１２０は、マスタコード管理テーブル１１３に、新たなバージョン番号を付与したレコードを追加する。コード修正管理部１２０は、追加したレコードの作成日時として、現在の日時を設定する。またコード修正管理部１２０は、追加したレコードの最後に適用された変更ＩＤとして、ステップＳ１２で保存した修正記録の変更ＩＤを設定する。さらにコード修正管理部１２０は、追加したレコードのコード内容として、修正後のマスタコードを設定する。なおコード修正管理部１２０は、追加したレコードのコード内容として、修正後のマスタコードが記述されたソースファイルを示す情報（ファイルパスとファイル名）を設定してもよい。

［ステップＳ１５］コード属性特定部１５０は、コード属性情報管理テーブル１１４を更新する。例えばコード属性特定部１５０は、変更要求に応じてソースコードから部分コードが削除された場合、削除された部分コード内の各コマンド行に対応するコード属性情報管理テーブル１１４内のレコードを削除する。またコード属性特定部１５０は、変更要求に応じて追加した部分コードの各コマンド行に対応するレコードを、コード属性情報管理テーブル１１４に追加する。コード属性情報管理テーブル１１４は、追加したレコードの行番号として、対応するコマンド行の行番号を設定する。またコード属性情報管理テーブル１１４は、追加したレコードのコマンドとして、対応するコマンド行に追加されたコマンドを設定する。またコード属性情報管理テーブル１１４は、追加したレコードの変更ＩＤとして、ステップＳ１２で保存した修正記録の変更ＩＤを設定する。またコード属性情報管理テーブル１１４は、追加したレコードの日時として、現在の日時を設定する。さらにコード属性情報管理テーブル１１４は、追加したレコードの作成者として、変更要求を送信した端末装置を使用している開発者の名称を設定する。

コード属性情報管理テーブル１１４の更新が終了すると、ステップＳ１１に進められ、サーバ１００は、次の変更要求を受信するまで待機する。
以上のようにして、開発者による部分コードの修正が行われるごとに、コードリポジトリ１１０に格納されている各テーブルが更新される。そしてサーバ１００は、コードリポジトリ１１０内の各テーブルに基づいて、任意のバージョンのマスタコード内のリファクタリング対象候補となる部分コードを特定することができる。

ここで、バージョン「Ｖ１．３」のマスタコード１１１ｃに対して、開発者４１がリファクタリングを行う場合を想定する。この場合、開発者４１は、端末装置３１を用いて、サーバ１００に対して、バージョン「Ｖ１．３」のマスタコード１１１ｃを指定したリファクタリング候補特定要求を送信する。サーバ１００は、リファクタリング候補特定要求に応じて、マスタコード１１１ｃからリファクタリング対象となる可能性が高い部分コードを特定し、特定した部分コードをリファクタリング候補とする。

以下、リファクタリング候補の特定処理を具体的に説明する。
リファクタリング対象特定部１３０は、まず部分コードの修正記録に基づいて、リファクタリングによって修正した後の部分コード（リファクタリングコード）と、リファクタリングによって修正された元の部分コード（リファクタードコード）とを特定する。リファクタリングコードであるための条件は、以下の通りである。
（条件ａ）削除した部分コード（削除コード）があること。
（条件ｂ）テストコード（例えばａｓｓｅｒｔ文）の変更がないこと。

リファクタリング対象特定部１３０は、条件ａと条件ｂを共に満たす部分コードを、リファクタリングコードと判定する。
部分コードがリファクタードコードであるための条件は、以下の通りである。
（条件ｃ）リファクタードコードか否かの検討対象の部分コード内に、該当部分コードが作成された後に、他のリファクタリングコードによって修正された１以上のコマンド行があること。

リファクタリング対象特定部１３０は、条件ｃを満たす部分コードを、リファクタードコードと判定する。
図１４は、リファクタリング対象特定処理を示す第１の例である。図１４には、変更ＩＤ「Ｃ００２」に示された修正処理に関するリファクタリング対象の特定処理を示している。

変更ＩＤ「Ｃ００２」の修正処理では、変更ＩＤ「Ｃ００１」で追加された部分コードを削除し、新たな部分コードを追加している。従って条件ａが満たされている。また変更ＩＤ「Ｃ００２」の修正処理では、テストコードであるａｓｓｅｒｔ文に変更はない。従って条件ｂが満たされている。その結果、リファクタリング対象特定部１３０は、変更ＩＤ「Ｃ００２」の修正処理で追加された部分コードを、リファクタリングコードであると判定する。

また変更ＩＤ「Ｃ００１」の修正処理で追加された部分コード内の一部のコマンド行は、変更ＩＤ「Ｃ００２」の修正処理において、リファクタリングコードによって変更されている。従って条件ｃが満たされている。その結果、リファクタリング対象特定部１３０は、変更ＩＤ「Ｃ００１」で追加された部分コードを、リファクタードコードであると判定する。

図１５は、リファクタリング対象特定処理を示す第２の例である。図１５には、変更ＩＤ「Ｃ００３」に示された修正処理に関するリファクタリング対象の特定処理を示している。

変更ＩＤ「Ｃ００３」の修正処理では、変更ＩＤ「Ｃ００２」で追加されたコマンド行「ｆｏｒ（ｉ＝０； ｉ＜１０； ｉ＋＋）｛」を削除し、新たなコマンド行「ｆｏｒ（ｉ＝０； ｉ＜１１； ｉ＋＋）｛」を追加している。従って条件ａが満たされている。ただし変更ＩＤ「Ｃ００３」の修正処理では、テストコードであるａｓｓｅｒｔ文が変更されている。従って条件ｂが満たされない。その結果、リファクタリング対象特定部１３０は、変更ＩＤ「Ｃ００３」の修正処理で追加された部分コードは、リファクタリングコードではないと判定する。

変更ＩＤ「Ｃ００３」の修正処理において追加された部分コードがリファクタリングコードではないため、条件ｃを満たすことはできない。その結果、リファクタリング対象特定部１３０は、変更ＩＤ「Ｃ００２」で追加された部分コードは、変更ＩＤ「Ｃ００３」の修正処理で変更されているものの、リファクタードコードではないと判定する。

リファクタリング対象特定部１３０は、リファクタリング対象特定処理の結果に基づいて、リファクタリング対象情報を生成する。
図１６は、リファクタリング対象情報の一例を示す図である。リファクタリング対象情報１３１には、変更ＩＤ、リファクタリングコードか否か、リファクタリングターゲット、リファクタードコードか否か、およびリファクタをした修正処理の欄が設けられている。

変更ＩＤの欄には、修正処理の変更ＩＤが設定される。
リファクタリングコードか否かの欄には、対応する修正処理で追加された部分コードが、リファクタリングコードか否かを示す情報が設定される。例えば追加されたコードがリファクタリングコードであれば、リファクタリングコードか否かの欄に「Ｙｅｓ」と設定される。また追加された部分コードがリファクタリングコードでなければ、リファクタリングコードか否かの欄に「Ｎｏ」と設定される。

リファクタリングターゲットの欄には、対応する修正処理で追加された部分コードがリファクタリングコードの場合において、そのリファクタリングコードで修正したリファクタードコードを追加コードとして含む修正処理の変更ＩＤが設定される。

リファクタードコードか否かの欄には、対応する修正処理で追加された部分コードが、他の修正処理によるリファクタードコードであるか否かを示す情報が設定される。例えば追加された部分コードがリファクタードコードであれば、リファクタードコードか否かの欄に「Ｙｅｓ」と設定される。また追加された部分コードがリファクタードコードでなければ、リファクタードコードか否かの欄に「Ｎｏ」と設定される。

リファクタをした修正処理の欄には、対応する修正処理で追加された部分コードがリファクタードコードの場合において、そのリファクタードコードを修正した修正処理の変更ＩＤが設定される。

図１６の例では、変更ＩＤ「Ｃ００１」のレコードには、対応する修正処理で追加された部分コードがリファクタードコードであり、該当コードは、変更ＩＤ「Ｃ００２」の修正処理によって修正されていることが示されている。また変更ＩＤ「Ｃ００２」のレコードには、対応する修正処理で追加された部分コードがリファクタリングコードであり、該当部分コードによる修正の対象は、変更ＩＤ「Ｃ００１」で追加された部分コードであることが示されている。

リファクタリング対象特定部１３０は、生成したリファクタリング対象情報１３１を、被疑属性特定部１４０に送信する。被疑属性特定部１４０は、リファクタリング対象情報１３１を用いて、被疑作成者または被疑期間を特定する。

図１７は、被疑作成者の特定例を示す図である。被疑属性特定部１４０の被疑作成者特定部１４１は、各開発者が、過去にリファクタリング対象となったリファクタードコードを作成した数や割合を、コード修正履歴管理テーブル１１２とリファクタリング対象情報１３１に基づいて算出する。

例えば被疑作成者特定部１４１は、コード修正履歴管理テーブル１１２を参照し、開発者ごとに、変更回数を計数する。また被疑作成者特定部１４１は、コード修正履歴管理テーブル１１２とリファクタリング対象情報１３１を参照し、開発者ごとに、その開発者が作成した部分コードがリファクタードコードであると判定された回数（リファクタードコード数）を計数する。そして被疑作成者特定部１４１は、開発者ごとに、その開発者によって作成された部分コードがリファクタードコードと判定された割合を計算する。

被疑作成者特定部１４１は、例えば計算した割合が所定の閾値以上となる開発者を、被疑作成者とする。被疑作成者特定部１４１は、例えばすべての開発者について被疑作成者か否かを判定し、判定結果を示す被疑作成者情報１４３を生成する。

被疑作成者情報１４３には、作成者、リファクタードコード数、全変更回数、割合、および被疑作成者か否かの欄が設けられている。作成者の欄には、開発者の名称が設定される。リファクタードコード数の欄には、開発者が追加した部分コードのうちの、リファクタードコードの数が設定される。全変更回数の欄には、開発者がコード修正を行った回数（全変更回数）が設定される。割合の欄には、開発者の全変更回数に対するリファクタードコード数の割合が設定される。被疑作成者か否かの欄には、開発者が被疑作成者か否かが設定される。例えば開発者が被疑作成者であれば、被疑作成者か否かの欄に「Ｙｅｓ」と設定される。また開発者が被疑作成者でなければ、被疑作成者か否かの欄に「Ｎｏ」と設定される。

図１７には、全変更回数に対するリファクタードコード数の割合が０．３以上の開発者を被疑作成者と判定する場合の例が示されている。この場合、開発者「Ｃｏｄｅｒ Ａ」は被疑作成者であるが、開発者「Ｃｏｄｅｒ Ｂ」と「Ｃｏｄｅｒ Ｃ」とは被疑作成者ではない。

なお被疑作成者特定部１４１は、リファクタードコード数が所定値以上の場合に被疑作成者と判定してもよい。さらに被疑作成者特定部１４１は、割合またはリファクタードコード数が上位から所定数の開発者を、被疑作成者としてもよい。

図１８は、被疑期間の特定例を示す図である。被疑属性特定部１４０の被疑期間特定部１４２は、リファクタリング対象となったリファクタードコードが作成された日時が集中する期間を、被疑期間として特定する。例えば被疑期間特定部１４２は、コード修正履歴管理テーブル１１２を参照し、一定の期間ごとに、該当期間内でのソースコードの変更回数を計数する。また被疑期間特定部１４２は、コード修正履歴管理テーブル１１２とリファクタリング対象情報１３１を参照し、一定の期間ごとに、該当期間内に作成されたコードがリファクタードコードであると判定された回数（リファクタードコード数）を計数する。そして被疑期間特定部１４２は、一定の期間ごとに、該当期間内に作成された部分コードがリファクタードコードと判定された割合を計算する。

被疑期間特定部１４２は、例えば計算した割合が所定の閾値以上となる期間を、被疑期間とする。被疑期間特定部１４２は、例えばすべての期間について被疑期間か否かを判定し、判定結果を示す被疑期間情報１４４を生成する。

被疑期間情報１４４には、期間、リファクタードコード数、全変更回数、割合、および被疑期間か否かの欄が設けられている。期間の欄には、判定対象の期間（開始日時と終了日時）が設定される。リファクタードコード数の欄には、判定対象の期間内に追加された部分コードのうちの、リファクタードコードの数が設定される。全変更回数の欄には、判定対象の期間内にコード修正が行われた回数（全変更回数）が設定される。割合の欄には、判定対象の期間の全変更回数に対するリファクタードコード数の割合が設定される。被疑期間か否かの欄には、判定対象の期間が被疑期間か否かが設定される。例えば判定対象の期間が被疑期間であれば、被疑期間か否かの欄に「Ｙｅｓ」と設定される。また判定対象の期間が被疑期間でなければ、被疑期間か否かの欄に「Ｎｏ」と設定される。

図１８には、全変更回数に対するリファクタードコード数の割合が０．３以上の期間を被疑期間と判定する場合の例が示されている。この場合、期間「２０１７．１２．３０－２０１８．１．５」は被疑期間であるが、期間「２０１８．１．６－２０１８．１．１２」と「２０１８．１．１３－２０１８．１．２０」とは被疑期間ではない。

なお被疑期間特定部１４２は、リファクタードコード数が所定値以上の場合に被疑期間と判定してもよい。さらに被疑期間特定部１４２は、割合またはリファクタードコード数が上位から所定数の期間を、被疑期間としてもよい。

被疑作成者と被疑期間とが特定されると、リファクタリング候補抽出部１６０が、ソースコードからリファクタリング候補を抽出する。
図１９は、リファクタリング候補の抽出例を示す図である。図１９には、バージョン「Ｖ１．３」のソースコードについてのリファクタリング候補の抽出例が示されている。

リファクタリング候補抽出部１６０は、被疑作成者情報１４３から、被疑作成者の名称を取得する。またリファクタリング候補抽出部１６０は、被疑期間情報１４４から、被疑期間を示す情報を取得する。次にリファクタリング候補抽出部１６０は、コード属性情報管理テーブル１１４を参照し、被疑作成者が作成したコマンド行と、被疑期間内に作成されたコマンド行とを抽出する。そしてリファクタリング候補抽出部１６０は、例えば抽出したコマンド行の行番号とコマンドとを出力する。出力された情報は、例えばリファクタリングを行う開発者が使用する端末装置に送信され、その端末装置の画面に表示される。

このようにして、多くのリファクタードコードを作成した開発者によって作成されたか、または多くのリファクタードコードが追加された期間内に作成された部分コードのうち、着目したバージョンのソースコードに残存している部分コードが表示される。開発者は、出力された結果を見て、ソースコード内の該当コードおよび関連するコードを確認し、リファクタリングを行うか否かを判断する。

図１９の例では、リファクタリング候補として「２行目：ｘ＝０；」と「３行目：ｙ＝０；」とが抽出されている。開発者は、ソースコード内のこれらのコマンド行に関連する記述を確認する。そして開発者は、例えばバージョン「Ｖ１．３」のソースコードでは変数ｙについて、３行目で値が設定されているものの、他の場所で使用されていないことを見つけることができる。すなわち３行目のコマンド行が削除できる可能性がある。開発者は、３行目のコマンド行を削除可能と判断した場合、端末装置を用いてそのコマンド行を削除する変更要求をサーバ１００に送信する。

なお、被疑作成者と被疑期間のように、被疑コード属性が複数ある場合、リファクタリング候補抽出部１６０は、例えばそれらの被疑コード属性の論理積（ＡＮＤ）によってリファクタリング候補を特定する。またリファクタリング候補抽出部１６０は、それらの被疑コード属性の論理和（ＯＲ）によってリファクタリング候補を特定してもよい。

図２０は、被疑コード属性の論理積を採用した場合と論理和を採用した場合との出力結果の違いを示す図である。図２０の例では、被疑作成者情報１４３ａには、被疑作成者として「Ｃｏｄｅｒ Ａ」などが示されている。また被疑期間情報１４４ａには、被疑期間として「２０１７．１２．３０－２０１８．１．６」などが示されている。

他方、コード属性情報管理テーブル１１４ａには、行番号「２」、「３」のコマンド行が、開発者「Ｃｏｄｅｒ Ａ」によって、日時「２０１８．１．５」に作成されたことが示されている。またコード属性情報管理テーブル１１４ａには、行番号「４」のコマンド行が、開発者「Ｃｏｄｅｒ Ａ」によって、日時「２０１８．１．９」に作成されたことが示されている。さらにコード属性情報管理テーブル１１４ａには、行番号「５」のコマンド行が、開発者「Ｃｏｄｅｒ Ｂ」によって、日時「２０１８．１．６」に作成されたことが示されている。

ここでリファクタリング候補の抽出条件として、被疑コード属性の論理積（ＡＮＤ）を採用した場合、被疑作成者と被疑期間との両方に該当するコマンド行が、リファクタリング候補として抽出される。図２０の例では、行番号「２」、「３」のコマンド行「Ｃｏｍｍａｎｄ ２」、「Ｃｏｍｍａｎｄ ３」がリファクタリング候補として抽出される。

また ここでリファクタリング候補の抽出条件として、被疑コード属性の論理和（ＯＲ）を採用した場合、被疑作成者と被疑期間とのいずれかに該当するコマンド行が、リファクタリング候補として抽出される。図２０の例では、行番号「２」～「５」のコマンド行「Ｃｏｍｍａｎｄ ２」、「Ｃｏｍｍａｎｄ ３」、「Ｃｏｍｍａｎｄ ４」、「Ｃｏｍｍａｎｄ ５」がリファクタリング候補として抽出される。

次に、リファクタリング候補抽出処理の手順を詳細に説明する。リファクタリング候補抽出処理は、例えばリファクタリングを行う開発者が使用する端末装置からの、リファクタリング候補特定要求の入力に応じて実行される。

図２１は、リファクタリング候補抽出処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
［ステップＳ２１］リファクタリング対象特定部１３０は、コード修正履歴管理テーブル１１２を参照し、コード修正でソースコードに追加された部分コードの中から、リファクタリングコードとリファクタードコードとを特定する。そしてリファクタリング対象特定部１３０は、リファクタリングコードとリファクタードコードとを示すリファクタリング対象情報１３１を生成する。リファクタリングコードとリファクタードコード特定処理の詳細は後述する（図２２参照）。

［ステップＳ２２］被疑作成者特定部１４１は、リファクタリング対象特定部１３０からリファクタリング対象情報１３１を取得し、取得したリファクタリング対象情報１３１とコード修正履歴管理テーブル１１２とに基づいて被疑作成者を特定する。例えば被疑作成者特定部１４１は、開発者ごとに、リファクタードコード数と全変更回数とを集計する。そして被疑作成者特定部１４１は、開発者ごとに、リファクタードコード数を全変更回数で除算し、その開発者が作成した追加コードがリファクタードコードである割合を算出する。被疑作成者特定部１４１は、開発者ごとに、算出した割合を所定の閾値と比較し、割合が閾値以上であれば、該当する開発者を被疑作成者として特定する。被疑作成者特定部１４１は、被疑作成者を特定した場合、被疑作成者情報１４３に対し、被疑作成者の名称に対応付けて、被疑作成者か否かの欄に「Ｙｅｓ」を設定する。

［ステップＳ２３］被疑期間特定部１４２は、リファクタリング対象特定部１３０からリファクタリング対象情報１３１を取得し、取得したリファクタリング対象情報１３１とコード修正履歴管理テーブル１１２とに基づいて被疑期間を特定する。例えば被疑期間特定部１４２は、一定の期間ごとに、リファクタードコード数と全変更回数とを集計する。そして被疑期間特定部１４２は、期間ごとに、リファクタードコード数を全変更回数で除算し、その期間内で作成された追加コードがリファクタードコードである割合を算出する。被疑期間特定部１４２は、期間ごとに、算出した割合を所定の閾値と比較し、割合が閾値以上であれば、該当する期間を被疑期間として特定する。被疑期間特定部１４２は、被疑期間を特定した場合、被疑期間情報１４４に対し、被疑期間に対応付けて、被疑期間か否かの欄に「Ｙｅｓ」を設定する。

［ステップＳ２４］リファクタリング候補抽出部１６０は、被疑作成者情報１４３、被疑期間情報１４４、およびコード属性情報管理テーブル１１４を参照し、ソースコードからリファクタリング候補となる部分コードを特定する。例えばリファクタリング候補抽出部１６０は、抽出条件が論理積の場合、被疑作成者情報１４３に示される被疑作成者の名称と被疑期間情報１４４に示される被疑期間の内の日時とを含むレコードを、コード属性情報管理テーブル１１４から抽出する。またリファクタリング候補抽出部１６０は、抽出条件が論理和の場合、被疑作成者情報１４３に示される被疑作成者の名称、被疑期間情報１４４に示される被疑期間の内の日時とのいずれかを含むレコードを、コード属性情報管理テーブル１１４から抽出する。リファクタリング候補抽出部１６０は、抽出したレコードに示されるコマンド行を、リファクタリング候補として特定する。

［ステップＳ２５］リファクタリング候補抽出部１６０は、特定したリファクタリング候補を出力する。例えばリファクタリング候補抽出部１６０は、リファクタリングを行う開発者が使用する端末装置へ、リファクタリング候補のコマンド行を示す情報を送信する。

以上のようにして、リファクタリング候補が特定される。リファクタリング候補が自動で特定されることで、リファクタリングを行う開発者は、マスタコード内のリファクタリング候補に関連する部分を精査すればよく、作業効率が向上する。

次に、リファクタリングコードとリファクタードコード特定処理の詳細について説明する。
図２２は、リファクタリングコードとリファクタードコード特定処理の手順の一例を示すフローチャートである。

［ステップＳ３１］リファクタリング対象特定部１３０は、コード修正履歴管理テーブル１１２から、未選択の修正記録を１つ選択する。
［ステップＳ３２］リファクタリング対象特定部１３０は、選択した修正記録に示される修正内容に、既存の部分コードの削除が含まれるか否かを判断する。例えばリファクタリング対象特定部１３０は、コード修正履歴管理テーブル１１２における選択した修正記録のレコードに、削除内容としてコマンド行が設定されている場合、既存の部分コードの削除が含まれると判定する。リファクタリング対象特定部１３０は、既存の部分コードの削除が含まれる場合、処理をステップＳ３２に進める。またリファクタリング対象特定部１３０は、既存の部分コードの削除が含まれない場合、処理をステップＳ３７に進める。

［ステップＳ３３］リファクタリング対象特定部１３０は、選択した修正記録に示される修正内容に、テストコードの変更があるか否かを判断する。例えばリファクタリング対象特定部１３０は、修正記録において、追加されたａｓｓｅｒｔ文に示される変数の値が、削除されたａｓｓｅｒｔ文に示される変数の値と異なる場合、テストコードが変更されたと判断する。リファクタリング対象特定部１３０は、テストコードの変更がある場合、処理をステップＳ３７に進める。またリファクタリング対象特定部１３０は、テストコードの変更がない場合、修正による入出力の変更がないと認識し、処理をステップＳ３４に進める。

［ステップＳ３４］リファクタリング対象特定部１３０は、抽出した修正記録に示される追加コードを、リファクタリングコードとして特定する。この際、リファクタリング対象特定部１３０は、例えばリファクタリング対象情報１３１に対し、選択した修正記録の変更ＩＤに対応付けて、リファクタリングコードか否かの欄に「Ｙｅｓ」を設定する。

［ステップＳ３５］リファクタリング対象特定部１３０は、コード修正履歴管理テーブル１１２に基づいて、選択した修正記録に示される修正で削除された削除コードを追加コードとして含む他の修正記録を特定する。

［ステップＳ３６］リファクタリング対象特定部１３０は、特定した修正記録の追加コードを、リファクタードコードとして特定する。この際、リファクタリング対象特定部１３０は、リファクタリング対象情報１３１に対し、リファクタードコードを追加した修正処理を示す修正記録の変更ＩＤに対応付けて、リファクタードコードか否かの欄に「Ｙｅｓ」を設定する。

［ステップＳ３７］リファクタリング対象特定部１３０は、未選択の修正記録があるか否かを判断する。リファクタリング対象特定部１３０は、未選択の修正記録がある場合、処理をステップＳ３１に進める。またリファクタリング対象特定部１３０は、すべての修正記録が選択済みであれば、リファクタリングコードとリファクタードコード特定処理を終了する。

このようにして、リファクタリングコードとリファクタードコードとを正しく特定することができる。リファクタードコードを正しく特定できることにより、どのような属性のコードがリファクタードコードになりやすいのかについての解析精度が向上する。その結果、リファクタリング候補を高精度に判定することが可能となる。

〔その他の実施の形態〕
第２の実施の形態では、サーバ１００は、コード開発時にコード属性情報管理テーブル１１４を生成しているが、リファクタリング候補抽出時にコード属性情報管理テーブル１１４を生成することもできる。その場合、サーバ１００のコード属性特定部１５０は、ソースコードの修正記録に基づいて、ソースコードに対して行われた修正処理を再現する。そしてコード属性特定部１５０は、再現された修正処理ごとにコード属性情報管理テーブル１１４を更新することで、任意のバージョンのソースコードが作成された時点でのコード属性情報管理テーブル１１４を生成する。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１，１ａ～１ｃ ソースコード
２ 修正履歴
２ａ～２ｃ 修正記録
１０ コンピュータ
１１ 記憶部
１２ 処理部

Claims (4)

1. コンピュータに、
   ソースコードに対して実行された複数の修正処理ごとに、修正処理により削除された削除コード、前記修正処理により追加された追加コード、および前記修正処理に関する属性を示す属性情報を含む修正記録を記憶部に格納し、
   前記複数の修正処理それぞれの前記修正記録に示される削除コードと追加コードとを比較し、前記複数の修正処理のうち、処理の入出力を変えずに部分コードを修正するリファクタリングを行った第１修正処理を特定し、
   前記第１修正処理の第１修正記録に基づいて、前記第１修正処理によって削除された削除コードを追加コードに含む第２修正処理を特定し、
   前記第２修正処理の第２修正記録に示される属性情報に基づいて、リファクタリング候補とする部分コードの属性を示す被疑属性を決定し、
   前記被疑属性を有する被疑修正処理によって前記ソースコードに追加され、前記ソースコードに残存している部分コードを、リファクタリング候補として出力する、
   処理を実行させる修正候補特定プログラム。
2. 前記第１修正処理の特定では、前記複数の修正処理のうちの一修正処理において削除した削除コードが存在し、かつ前記一修正処理においてテストコードに変更がない場合に、前記一修正処理を前記第１修正処理として特定する、
   請求項１記載の修正候補特定プログラム。
3. 前記複数の修正処理それぞれの前記修正記録の格納では、前記修正記録の前記属性情報に、前記修正記録に対応する前記修正処理で追加した追加コードの作成者の識別子を含め、
   前記被疑属性の決定では、前記第２修正記録に示される追加コードの作成者の識別子を、前記被疑属性として決定する、
   請求項１または２に記載の修正候補特定プログラム。
4. 前記複数の修正処理それぞれの前記修正記録の格納では、前記修正記録の前記属性情報に、前記修正記録に対応する前記修正処理を実行した日時を含め、
   前記被疑属性の決定では、前記第２修正記録に示される前記第２修正処理を実行した日時を含む所定の期間を、前記被疑属性として決定する、
   請求項１ないし３のいずれかに記載の修正候補特定プログラム。

Images