JP6336919B2 - ソースコードレビュー方法及びそのシステム - Google Patents

Description

本発明はソフトウェア開発におけるソースコードレビューを支援する方法及びシステムに係る。

オープンソースソフトウェア開発において、GitHub(非特許文献１)のようなサービスを利用した不特定多数の開発者と共同開発を行っていく開発手法が採用されてきている。

これらのサービスは、不特定多数の開発者からPull Requestと呼ばれるソースコード差分のレビュー依頼を受け、当該ソフトウェアのオーナーがレビューをし、レビューが完了したソースコード差分を取り込んでいく開発手法を、システムとしてサポートしている。

近年、企業内でも従来行われてきたウォーターフォールモデルの開発から、このようなサービス・システムを利用したアジャイル的開発手法の適用がなされようとしているが、ソースコードレビューのコストが大きいことが問題となっている。

ソースコードレビューコスト削減への公知の取り組みとして、特許文献１が存在する。

これは、レビュー対象となるソースコードを静的解析し、コーディング上の警告を出力し、その警告に優先度を付与することで、レビューコストを削減する。しかし、昨今行われているアジャイル開発においては、品質は自動テストにより担保し、なおかつソフトウェアの仕様は作りながら変わっていくものである。また、仕様を変更するときは、そのソフトウェアが当初目指していたコアとなるコンセプト、例えばユーザビリティやデザインが守られているかどうかが非常に重要である。

この時、開発チームとしては、品質と同程度にソフトウェアの仕様がどのように変えられたかということに関心があり、より詳細にレビューされなければならない。しかし、静的解析においては、そのような開発チームの関心の度合いを知る術を持たない。

特開2008-52424

Git, GitHub, Gerrit, Stash
GitHub, Chris Dawson, Oreilly Media, ISBN-13:978-1449368012

アジャイル開発等の手法を採用したソフトウェア開発において、ソースコードレビュー時に、開発チームの関心度の高い箇所を優先的に出力することで、ソースコードレビューの漏れをなくすと同時に、レビューコストの削減を行う。

関心度の高い箇所はより多く変更され、また、多くのレビューコメントが付くという前提に立ち、ソースコード中の各関数の変更回数や、変更内容、レビューシステムに投稿されたレビューの多寡、バージョン管理システムの派生開発状況といった情報から、当該開発チームにおけるソースコードの関心度をスコア付けし、よりスコアの高い箇所が変更された場合、その箇所を優先的にレビュー画面に出力するようにする。

重要な箇所のレビューを優先的に実行しレビュー時間の短縮が期待できる。

アジャイル開発を行った場合の開発の流れ 本実施例におけるレビューシステムのハードウェア構成図の例 本実施例におけるレビューシステムのソフトウェア構成図の例 本実施例におけるレビューシステムの処理の流れを示すフローチャートの例 管理単位テーブルのテーブル構成図の例 スコアテーブルのテーブル構成図の例 レビュー依頼記録部に保存されるデータの例 レビュー依頼スコア情報記録部に保存されるデータの例 レビューコメントテーブルのテーブル構成図の例 スコア補正値テーブルのテーブル構成図の例 レビュー依頼情報の例 管理単位変更情報の例 スコア計算処理部のフローチャートの例 マージ処理部のフローチャート レビュー入力画面の例 レビュー依頼選択画面の例 ソースコードリポジトリの例

以下、本発明に係る実施例を、図面を用いて説明する。

図１はアジャイル開発を行った場合の開発の流れである。この例では１から始まる上のラインがmaster branch１、３から始まるラインが他のグループで開発されmaster branch１ へ開発機能を定期的にマージしているdev branch２、７から始まるラインがdev branch２から分割されレビュー後にdev branch２へマージされるtopic branch３を示しています。

この例ではレビュー依頼が７から９のノード６で表されています。ノード６の中には大量の形式的な修正を行うためのレビュー依頼や、経験年数の少ないプログラマからのレビュー依頼、重要な機能修正のためのレビュー依頼が含まれています。

図２はソースコードレビューシステムが稼働する計算機のハードウェア構成の一例である。

計算機１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０２、主記憶装置としてのメモリ１０３、ネットワークデバイス１０４、外部記憶装置としてのストレージデバイス１０５から構成される。ＣＰＵ１０２は、メモリ１０３上にロードされたアプリケーションプログラム１１１やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１１０を実行したり、ネットワークデバイス１０４、ストレージデバイス１０５等の周辺機器を制御するために利用される。メモリ１０３は、ストレージデバイス１０５に保存されたアプリケーションプログラム１１１や、ＯＳ１１０や各種データをロードし、ＣＰＵ１０２から参照するために利用される。

また、レビューシステム２０１もメモリ１０３にロードされ、ＣＰＵ１０２により実行される。ネットワークデバイス１０４は、例えば有線ＬＡＮカードであり、ネットワーク１０６を介し、他の計算機たとえば開発者端末１０７が接続され、そこからソースコードを受信したり、要求に対する応答として、Ｗｅｂ画面などを表示するための情報をやりとりするために利用される。ネットワークデバイス１０４としては、ほかに、無線ＬＡＮやＩｎｆｉｎｉｂａｎｄ，Ｍｙｒｉｎｅｔ，Ｆｉｒｅｗｉｒｅなども利用することができる。ストレージデバイス１０５は、アプリケーションプログラムやＯＳだけでなく、バージョン管理システムが管理するソースコードリポジトリ、ソースコードのスコア、レビューコメント、プログラマのスコア補正値を記録するために使われる。

ストレージデバイス１０５としては、具体的にはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ），ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ブロックストレージ、ファイルストレージ、クラウドストレージ、テープ、また、ネットワークデバイスを介した他の計算機上にあるストレージデバイスを利用してもよい。また、計算機１０１は、実ハードウェアを必ずしも持つ必要はなく、ソフトウェア的に構築された仮想計算機でもよい。

図１７は本発明で前提とするバージョン管理システムが管理するソースコードリポジトリの一例である。本発明においてソースコードリポジトリは、ソースコード記録部２１５に格納される。ソースコードリポジトリは、ある時点のソースコードの内容を一意に識別するためのバージョンＩＤ１７００、前記バージョンＩＤにおける変更元を示す親バージョンＩＤ１７０１、当該バージョンに更新した作業者を記録するコミッタ１７０２、当該バージョンに更新した日時を記録するコミット日時１７０３、派生開発情報を記録するブランチ１７０４、また、各バージョンＩＤに含まれるファイル名１７０５およびその内容１７０６を記録している。

バージョンＩＤ１７００はバージョン管理システムにより自動的に付与され、このバージョンＩＤを指定することで利用者は、前記バージョン管理システムに記録されたソースコード一式を得ることができる。このような情報を記録・管理する公知のバージョン管理システムとして、ＧｉｔやＳｕｂｖｅｒｓｉｏｎ等があり、本発明ではこのようなバージョン管理システムおよび、その記録形式であるソースコードリポジトリ利用することができる。

図３はレビューシステム２０１のソフトウェア構成図の例である。レビューシステム２０１はＷｅｂフロントエンド２０２を持ち、ユーザからＷｅｂブラウザや、ＲＥＳＴのようなＨＴＴＰを利用した通信手段によってアクセスされる。本実施例ではＷｅｂによるフロントエンドを持つことを想定しているが、一般的なＧＵＩを持ったアプリケーションでもよいし、他の通信手段を用いたフロントエンドでもよい。

レビューシステム２０１はレビュー依頼受付部２０６を持つ。Ｗｅｂフロントエンド２０２経由でレビュー依頼受付部２０６が受け付けたソースコードは、管理単位分割処理部２０８が本レビューシステムで管理する管理単位に分割したものと併せ、ソースコード記録部２１５に記録される。

レビュー受付部２０５は開発者がＷｅｂフロントエンド２０２を介し、レビュー依頼者が依頼したソースコードへの変更にレビューやコメントを受け取る。レビュー受付部２０５で受け付けられたレビュー情報はレビューデータ記録部２１２へ保存される。

そして、作業者評価値計算部２１０を経由し、レビューを行った作業者への評価を行った後、作業者評価値を作業者評価値テーブル２１３に保存する。

レビュー依頼受付部２０６はソースコードの変更を受け付ける。レビュー依頼受付部２０６で受け付けたレビュー依頼に含まれるソースコードへの変更差分は、管理単位分割処理部２０８により本レビューシステムで管理する単位に分割され、ソースコード記録部２１５へと記録される。分割された管理単位はスコア計算処理部２０９へ送付され、当該レビュー依頼に含まれる管理単位の変更に関する重要度が計算される。

計算されたスコアはスコア情報記録部２１４と、レビューデータ記録部２１２およびレビュースコア情報記録部２１１に記録される。

レビューデータ記録部２１２にはレビュー依頼の情報を記録するレビュー依頼情報と、レビューコメントを記録するレビューコメントテーブルが含まれる。

スコア情報記録部２１４には、管理単位毎のスコアを記録しているスコアテーブル、レビュー依頼者のレビュー時・被レビュー時のスコアが記録されるユーザスコアテーブル、 レビュー依頼がどのブランチ（派生開発）に関連するかを示す対応ブランチテーブル、変更内容の種別毎の加算スコアを設定する変更種別スコアテーブルが含まれる。

ソースコード記録部２１５には、実際にソースコードを記録するためのソースコードリポジトリと、レビューシステムでスコア管理対象とする管理単位の情報を格納した管理単位テーブルが含まれる。

ソースコードリポジトリはソースコードのバージョンを一意に特定でき、誰がいつ行った変更か分かる保存形式であればよい。

図４はレビューシステムの処理の流れを示すフローチャートの例である。

ステップ２５０でレビューシステムはソースコード情報、変更者情報、適用ブランチ名を受付け、ステップ２５１でソースコード情報から管理単位を求める。ステップ２５２で求められた管理単位から管理単位毎のスコアを管理単位の種別、変更者情報、変更内容等の情報から求める。レビュー依頼者から依頼されレビュー依頼に含まれる管理単位のうち最もスコアの高い管理単位を選択し、ステップ２５３で各々のレビュー依頼を選択された管理単位のスコアを基に降順に並べ替えて出力することにより関心の高いレビュー依頼を優先的にレビュアーがレビューすることが可能となる。この他にレビュアーの設定により受付順、ブランチ毎に出力しても良い。このような設定により受け付けた順序に処理することや、重要度の高いブランチからレビューをすることが可能となる。

出力したレビュー依頼に関するレビュアーのレビューが完了し、ステップ２５４でソースコードへの反映の可否を受け付けたときは、ステップ２５５反映依頼をしたユーザに当該ソースコードへの修正を反映する権限があることを確認し、修正を対応するソースコードへ反映する。

ステップ２５６で修正内容がソースコードへ反映された場合は管理単位、ステップ２５７で変更者情報、変更内容から修正に関連する管理単位のスコア、変更者のスコアを更新する。

図５は管理単位テーブル３００のテーブル構成図の例を示している。

管理単位テーブル３００の各レコードは管理単位ＩＤ３０１、管理単位の内容を記録している管理単位３０２、当該管理単位が含まれるファイル名を表すファイル３０３のカラムからなる。

この例では1行目に管理単位ＩＤ３０１として”mnbvc”という値が記録され、管理単位の内容が”int main(int, char *)”であり、対応するファイル名が”main.c”という値である。

管理単位ＩＤ” qazxs ”は管理単位がソースコードでない場合の例である。この場合管理単位の内容は無く、対応するファイル名”property.conf”だけが記録されている。

非ソースコードファイルの場合、ファイル全体で重要度を管理するため、管理単位フィールド３０８には有意な情報を含めない。管理単位テーブル３００では、この、管理単位３０２とファイル３０３の値を元に管理単位ＩＤ３０１を対応付けている。

図６スコア情報記録部にあるスコアテーブル４００の内容である。スコアテーブル４００の各レコードは、ソースコードのバージョンを表すバージョンＩＤ４１０と、当該バージョンに含まれる管理単位に対応する管理単位ＩＤ４０２、当該管理単位のスコアを表すスコア４０３が対応づけて格納されている。

フィールド４０４の値はソースコードリポジトリで利用されるバージョンＩＤと同様のものを利用する。

管理単位ＩＤ４０２を用いて、管理単位テーブル３００から管理単位の情報を取得する。

図７はレビュー依頼記録部２１２に保存されるデータを示している。レビュー依頼記録部にはバージョンＩＤ５０１、レビュー依頼ＩＤ５０２、レビュー依頼最新バージョン５０３、マージ先ブランチ５０４が対応づけられたテーブル、レビュー依頼ＩＤ５２１、レビュー依頼バージョン５２２、レビュー依頼バージョンＩＤ５２３が対応づけられたテーブル及び、レビュー依頼バージョンＩＤ５３１、要レビュー管理単位ＩＤ５３２、作業者名５３３が対応づけられたテーブルが含まれる。

記憶領域を削減するためにテーブルを分割しているが一つのテーブルで表現しても良い。

図８はレビュー依頼スコア情報記録部２１４に保存されるデータを示している。

レビュー依頼スコア情報記録部２１４にはバージョンＩＤ５５１とレビュー依頼ＩＤ５５２が対応づけて格納されたテーブルとレビュー依頼ＩＤ５６１、管理単位ＩＤ５６２、レビュー加算スコア５６３が対応づけて格納されたテーブルと、レビュー依頼ＩＤ５７１、レビュー依頼バージョン５７２、レビュー依頼バージョンＩＤ５７３が対応づけて格納されたテーブル及びレビュー依頼バージョンＩＤ５８１、要レビュー管理単位ＩＤ５８２、レビュー重要度スコア５８３、マージ時加算スコア５８４、レビューフラグ５８５が対応づけて格納されたテーブルが含まれる。

これらのテーブルも記憶領域を削減するためにテーブルを分割しているが一つのテーブルで表現しても良い。

図９はレビューコメントテーブル６００に格納されている情報を表している。レビューコメントテーブル６００の各レコードは、レビュー依頼を識別するためのレビュー依頼バージョンＩＤ６０１、レビューコメントがつけられた管理単位を表す管理単位ＩＤ４０２、レビューコメントがつけられた行を記録する行６０３、レビューでの指摘内容の分類を示す指摘内容分類６０４、レビューコメントを記録するレビューコメント４０５からなる。

スコア情報記録部２１４には開発差分適用先ブランチのブランチ名をあらわすブランチ名７０１、開発差分が適用された際のスコア補正値を表す補正値７０２が対応づけて格納されている。

図１０は スコア情報記録部２１４に含まれるスコア補正値テーブル８００に格納されている情報を表している。

スコア補正値テーブル８００は、変更の種類８０１、該当箇所のスコア８０２、影響箇所８０３、影響箇所のスコア８０４が対応づけて格納されている。

1行目のデータは変更の種類が“関数の追加”、変更の種類が“関数の追加”、追加された関数（管理単位）に加算するスコアが“10”であることを表している。

影響箇所８０３は、変更の種類”関数の追加“に対する影響箇所を表しており、この場合”呼出元関数“が影響箇所となる。影響箇所のスコア８０４は、影響箇所８０３で示された影響箇所に加算するスコアの値であり、スコア”5“を加算することを意味している。

スコア情報記録部２１４には作業者レビュー補正値テーブルが格納されている。

作業者レビュー補正値テーブルは、作業者名、レビュー時スコア決定用補正値、被レビュー時スコア補正値からなる。

たとえば、作業者名は作業者を識別する名前が格納されている。名前により作業者を識別してもよいが、ＳＳＨ公開鍵情報や、名前より生成されたハッシュ値など、作業者を一意に識別できる情報であればどのようなものでもよい。

レビュー時スコア決定用補正値は、レビュー依頼中に、複数の作業者の変更が含まれる場合、習熟度の低い、つまり重点的にレビューが必要と思われる作業者が行った変更にはレビュー重要度を高く評価するために用いられる。

被レビュー時スコア補正値の値は、レビューコメントが付いた際に使われる値である。習熟度の低い作業者が書いたコードには多くのレビューコメントが付くと予想されるため、対応する修正箇所のスコアが上がりすぎないよう調整するために用いられる。

図１１はレビュー依頼受付部２０６が受け取るレビュー依頼情報１０００の内容を表している。コメント受付部はネットワークデバイス等を通して、レビュー依頼情報を受け取る。レビュー依頼情報１０００には、レビュー依頼ＩＤ１００１、ベースバージョンＩＤ１００３、適用先ブランチ１００５、変更内容１００７からなる。

新たにレビュー依頼を行う場合はレビュー依頼ＩＤ１００１に空白や、ＮＵＬＬなどの、値がセットされる。

ベースバージョンＩＤ１００３はソースコードリポジトリで使われるバージョンＩＤがセットされ、このレビュー依頼に含まれる変更内容が、当該バージョンＩＤをベースに書かれたものであることを意味する。

適用先ブランチ１００５はこのレビュー依頼に含まれる変更内容が記載されたブランチに適用される。

変更内容１００７は変更内容の実体１００９へのポインタである。変更内容の実体は作業者１０１０と、変更内容１０１２が含まれる。

変更内容１０１２はどのような変更が加えられるかを示す差分情報が格納されている。形式はどのようなものでもよいが、本実施例ではＵＮＩＸ（登録商標）で使われるｄｉｆｆ形式で記載されている。

レビュー依頼情報１０００の形式は、ＸＭＬ，ＪＳＯＮ，ＹＡＭＬといったテキスト形式で表現してもよいし、ＧｉｔやＳｕｂｖｅｒｓｉｏｎの通信形式をそのまま利用してもよい。

図１２の管理単位変更情報１０２０は管理単位分割処理部２０８からスコア計算処理部２０９に処理を引き継ぐ際に渡す中間データ構造である。

管理単位変更情報１０２０は、レビュー依頼ＩＤ１０２１、ベースバージョンＩＤ１０２３、適用先ブランチ１０２５、管理単位ＩＤ１０２７、作業者１０２９、変更の種類１０３１、変更内容１０３３からなる。

レビュー依頼１０２１、ベースバージョンＩＤ１０２３、適用先ブランチ１０２５、作業者１０２９については、レビュー依頼情報１０００に含まれる同名のフィールドの値がコピーされる。

管理単位ＩＤ１０２７については、管理単位分割処理部２０８で分割された変更内容１０３３が、どの管理単位に属するかの情報が入る。

変更の種類１０３１は、当該変更内容がどのような変更であるかの要約情報が入り、「関数の追加」「コードの追加」「関数の削除」「コードの削除」「その他」の値を取りうる。変更内容１０３３は、レビュー依頼情報１０００に含まれる変更内容１０１３を、本システムで扱う管理単位に分割したものである。

レビュー依頼受付部２０６は、レビュー依頼情報１０００の受信を契機に実行される。

受信したレビュー依頼情報が新規かどうかを判定する。ここでは、受信したレビュー依頼情報１０００のレビュー依頼ＩＤ１００１の内容を参照し、既存のレビュー依頼の再投稿であるかどうかを確認する。レビュー依頼情報１０００のレビュー依頼ＩＤ１００１に、空白やＮＵＬＬといった値が格納されていた場合は、受け付けたレビューは新規と判断し、当該レビュー依頼のバージョンを１とし、レビュー依頼のために新しいレビュー依頼ＩＤを生成する。ここで生成するレビュー依頼ＩＤはシステム内で一意に識別できるものであればどのようなものでもよい。

たとえば、連番や、レビュー依頼に含まれるソースコード等から算出したハッシュ値などを利用してもよい。ステップ１１０１において、既存のレビューＩＤが存在すると判定された場合は、レビュー依頼記録部２２０のテーブル５００から、受信したレビュー依頼情報１０００に含まれるレビュー依頼ＩＤ１００１をキーに検索し、該当するカラムに記録されたレビュー依頼最新バージョン５０３に１を加算し、今回受信したレビュー依頼のバージョンとする。

受信したレビュー依頼情報が新規かどうかを判定処理が完了すると、新しいレビュー依頼バージョンＩＤの生成を行い、レビュー依頼記録部、レビュースコア情報記録部に受信したレビュー依頼情報の対応項目を記入し、処理を終了する。

管理単位分割処理部２０８では、レビュー依頼情報１０００を管理単位変更情報１０２０の形に成形し、スコア計算処理部２０９に処理を引き継ぐ。

まず、受信したレビュー依頼情報１０００に含まれる変更内容を、本レビューシステムで扱う管理単位に分割する。

次に、分割した管理単位に対する変更について、以降の処理を繰り返し実行する。

分割した変更内容に対する新しい管理単位変更情報１０２０を生成する。管理単位変更情報１０２０に含まれる、レビュー依頼ＩＤ１０２１、ベースバージョンＩＤ１０２３、適用先ブランチ１０２５、作業者１０２９は、受信したレビュー依頼情報１０００の同名カラムより値をコピーする。

当該変更内容がどの管理単位に属するかを判定するし、新規の管理単位に対する変更である場合は、新規管理単位IDを発行する。

既存管理単位に対する変更である場合は、管理単位テーブル３００より関数名をキーに検索し、管理単位ＩＤを取得する。

次に、変更の種類１０３１を判定する。変更の種類１０３１には、「関数の追加」「コードの追加」「関数の削除」「コードの削除」「その他」の値を取りうる。この分類は、たとえば、ＧＮＵ Ｃｏｒｅｕｔｉｌｓに含まれるｄｉｆｆコマンドで出力された結果を利用しこれを判断する。ｄｉｆｆコマンドの出力では行単位で「追加」「削除」を判別することができるが、ここではｄｉｆｆコマンドで出力された行単位の変更について、対応する変更元の行を見て、どのように変更されたかを分類する。

「関数の追加」ではｄｉｆｆの出力において関数のすべてが追加される場合、「コードの追加」では変更先の関数が存在し、かつコードを追加している場合、「関数の削除」ではｄｉｆｆの出力で関数がすべて削除されている場合、「コードの削除」では変更先の関数が存在し、かつコードが削除されている場合、そしてそれ以外が「その他」と分類される。

最後に、作成された管理単位変更情報１０２０をスコア計算処理部２０９に渡し、処理を終了する。

図１３はスコア計算処理部２０９で行われる処理である。

本処理は管理単位分割処理部２０８の処理の完了を契機に実行される。ステップ１１１０では、管理単位分割処理部２０８より、管理単位変更情報１０２０のリストを受け取る。ステップ１１１１では、前記ステップで受信したリストに含まれる各要素について以降の処理を繰り返し実行する。

ステップ１１１２では、変更の種類１０３１を参照し、変更内容の種別判断を行う。ステップ１１１３は「関数の追加」と判断された場合の処理である。つまり、変更の種類が「関数の追加」であった場合である。ステップ１１１３では新規追加された関数のスコアを計算する。ステップ１１１３で新規追加された関数のスコアは、呼出元関数のスコアと同じ値とする。たとえば”void new_func(void)”という関数が追加され、これが”int main(int, char *)”から呼び出されるのであれば、管理単位テーブル３００とスコアテーブル４００の情報を利用し、呼出元の関数”int main(int, char *)”のスコア”100”をそのまま新規追加された関数”void new_func(void)”に設定する。なお、複数個所から当該関数が呼ばれる場合は、そのなかの最大値を採用するものとする。呼出箇所の特定はｃｔａｇｓ，ｃｓｃｏｐｅ,ＯｐｅｎＧｌｏｋ，ＧＮＵ Ｇｌｏｂａｌのようなクロスリファレンスツールを用いる。

他に、プログラムスライシング、記号実行などの技術を用いてもよい。この呼び出し箇所の特定は、管理単位分割処理部２０８から受信した管理単位変更情報１０２０のみからでは判断できないため、ベースバージョンＩＤ１０２３で示されるバージョンのソースコードをソースコードリポジトリから取り出し、変更内容１０３４を適用したもので解析を行う。

次に、前記計算したスコアに、スコア補正値テーブル８００にある「コードの追加」のスコアと、作業者レビュー補正値テーブル９００の「作業者レビュー補正値」を乗じたものを加算し、レビュー重要度スコア５８３の値を決定する。同時に、スコア補正値テーブル８００から「コードの追加」相当のスコアをマージ時加算スコア５８４として保存する。

ステップ１１１４は「コードの追加」と判断された場合の処理である。つまり、変更の種類１０３１が「コードの追加」であった場合である。ステップ１１１４では、変更が加えられた関数のスコアをスコアテーブル４００カラム４０３から取得し、これにスコア補正値テーブル８００を参照し、「コードの追加」の値に作業者のレビュー補正値９０２を乗じたもの加算し、これをレビュー重要度スコア５８３とする。同時に、スコア補正値テーブル８００の「コードの追加」のスコアをマージ時加算スコア５８４とする。

ステップ１１１５は「関数の削除」と判断された場合の処理である。つまり、変更の種類１０３１が「関数の削除」であった場合である。ここではレビュー重要度スコア５８３は当該関数のスコアに、スコア補正値テーブル８００の「関数の削除」のスコアに作業者のレビュー補正値９０２を乗じたものを採用する。マージ時加算スコア５８４は呼出元関数に加算するものとする。

ステップ１１１６は「コードの削除」と判断された場合の処理である。つまり、変更の種類が「コードの削除」であった場合である。ここでは、レビュー重要度スコア５８３はコードが削除された関数のスコアに、スコア補正値テーブル８００の「コードの削除」のスコアに作業者のレビュー補正値９０２を乗じたものを採用する。マージ時加算スコア５８４は、スコア補正値テーブル８００の「コードの削除」の値を採用する。

ステップ１１１７は「それ以外」と判断された場合の処理である。つまり、変更の種類１０３１が「それ以外」または、変更が行われた管理単位がプログラムソースコード以外であった場合である。ここでは、スコア補正値テーブル８００に従い、レビュー重要度スコア５８３と、マージ時加算スコア５８４の計算を行う。たとえば変更の種類が「コメントの変更」であった場合は、スコア補正値テーブル８００を参照すると”+2”となっている。レビュー重要度スコアではこれに作業者レビュー補正値テーブル９００のレビュー時スコア決定用補正値９０２の値を乗じる。たとえば”プログラマＢ”は”1.2”というレビュー時スコア決定用補正値を持っているため、レビュー重要度スコア５８３に加算する値は2×1.2の2.4となる。マージ時加算スコア５８４には作業者レビュー補正値テーブル９００の値は使わず、単純に+2する。

ステップ１１１８では、管理単位分割処理部２０８より受信したすべての管理単位変更情報に対するスコア計算が終わったか確認し、未完了である場合はステップ１１１１に戻り、同様の処理を行う。すべての管理単位に対するスコア計算が終わった場合、ステップ１１１９では、前記計算されたスコアと、管理単位分割処理部２０８から受信した管理単位変更情報１０２０に含まれるレビュー依頼ＩＤ１０２１、ベースバージョンＩＤ１０２３、適用先ブランチ１０２５と使い、レビュー依頼記録部２２０とレビュー依頼スコア情報記録部２２０に、当該レビュー依頼の情報を格納する。

図１４はマージ処理部２０７で行われる処理のフローチャートである。本処理はレビュー受付部より実行される。ステップ１２０１ではマージに際し、コンフリクトが発生しないことを確認する。コンフリクトの確認は、ソースコードリポジトリにＧｉｔを採用した場合であれば、”git merge”コマンドによりマージを試み、その成否を確かめることで行う。または、変更差分をパッチファイル化し、ＵＮＩＸ（登録商標）のpatchコマンドによる変更適用の成否を確認してもよい。

これら前記方法が成功する場合はコンフリクトが起きないものとして扱う。失敗する場合は、コンフリクトが起きるものとして扱い、この場合はステップ１２０７にて作業者にコンフリクト解消を促す画面を出力し、処理を終了する。コンフリクトが起きないことが確認できたら、スコア計算処理を行う。

ステップ１２０２では、レビュー依頼記録部２２０およびレビュー依頼スコア情報記録部２１４から当該レビュー依頼情報および加算するためのスコア情報を取得する。ここではレビュー依頼ＩＤをキーに、マージ先ブランチ５０４、レビュー加算スコア５６３、レビュー依頼バージョンＩＤ５７３を得て、さらにレビュー依頼バージョンＩＤ５７３をキーに、作業者名５３３およびマージ時加算スコア５８４を得る。

ステップ１２０３では、ステップ１２０２で得た、各管理単位に設定されたマージ時スコア加算値５８４の値に、当該レビュー依頼の適用先ブランチのブランチ補正値７０２を乗じる。ここでのブランチ補正値７０２は、ステップ１２０２で得たマージ先ブランチ５０４の値をキーに、補正値７０２の値を取得している。ステップ１２０５では、ステップ１２０３で得られたスコアを、当該変更を行った作業者のスコアへ加算し、作業者評価値テーブル２１３に記録する。ここでは、ステップ１２０２で得られた作業者５３３をキーに、作業者評価値テーブル２１３を検索し、その値を記録する。

ステップ１２０５ではソースコードリポジトリに本レビュー依頼１０００がもつ全てのソースコード差分１０１３を該当するソースコードに反映する。ステップ１２０６では、ステップ１２０５でソースコードリポジトリに反映した結果得られたバージョンＩＤをもつレコードをスコアテーブル４００に追加し、ステップ１２０３で計算したマージ時スコア加算値を各管理単位に加算し、スコアテーブル４００に記録する。

レビュー受付部２０５ではレビュー画面を出力するためにまずレビュースコア情報記録部２１４より、レビュースコア情報を取得する。レビュー依頼ＩＤ５５２をキーにレビュー依頼バージョンＩＤ５２３を検索し、該当したレビュー依頼バージョンＩＤ５２３をキーにレビュー重要度スコア５８３を検索する。

次に、検索した結果の、各管理単位のレビュー重要度スコア５８３でソートを行い、レビューフラグ５８５で「完了」のついた管理単位を表示対象から除外する。レビューコメントテーブル６００より、レビュー依頼バージョンＩＤをキーに、レビューコメント情報を取得する。各管理単位の指摘内容分類を分類毎に数え、一番多い指摘内容を選択する。

レビュー画面にレビュー重要度順で変更が行われた管理単位を表示し、同時になぜその管理単位が重要であるかの参考情報として、指摘の多いレビュー内容分類を併せて表示を行う。

図１５がレビュー入力画面で表示される例である。レビュー入力画面１６００は、当該レビュー依頼で行われたファイル変更を示すフィールド１６０１と、当該変更を行った作業者名フィールド１６０２、当該変更内容を示すフィールド１６０３と、指摘の多いレビュー内容を知らせるフィールド１６０５が表示される。１６０４は変更があった行を点線で囲んで表示している様子である。本実施例では図１６のフィールド１６０５のように一番多い指摘内容分類を表示し、レビュアーに注意を促す。

レビュー入力部２０６は他の開発者からレビューを受け付ける。

開発者によりレビューコメントが付けられたことを契機に実行され、当該レビュー依頼にコメントする必要があるかどうかの選択を受付ける。
レビュー依頼にコメントする必要が無いという選択を受け付けた場合は、当該変更差分のレビューフラグ５８５を「完了」とする。レビュー依頼にコメントする必要が有るという選択を受け付けた場合は、スコア補正値テーブル８００から「レビューコメントが付いた」スコアと、作業者補正値テーブルから作業者の被レビュー時補正値９０３を取得し、乗じたものを当該管理単位のレビュースコア加算値とし、この値をレビュー加算スコア５６３に記録する。
次に、レビューを行った作業者を評価するため、評価値を加算する。ここではスコア補正値テーブル８００の「レビューを行った」ポイントを作業者評価値テーブル２１３の作業者評価値１５０２に加算し、処理を終了する。

作業者評価値テーブル２１３は作業者名を表すカラム１５０１と、作業者評価値を表すカラム１５０２を含んでいる。

図１６はレビュー依頼選択画面の例である。

レビュー依頼毎に、件名、登録日時、適用先ブランチ、レビュー依頼バージョン、スコア等が表示される。レビュー依頼はスコアの高い順や、登録日時の順番、ブランチ毎のようにレビュアーの目的に応じて並びを選択することができる。

表示されたレビュー依頼に対応づけられた「レビューをする」ボタンを選択することにより、当該レビュー依頼のレビューを実施することが可能となる。

以上説明した本実施例のソースコードレビューシステムによれば、次のような効果がある。
（１）スコア計算処理部を追加することで、ソースコード中の関数またはファイル毎に、開発チームにとって関心度の高さを定量化することができ、ソースコードのレビュー依頼が発行された際、関心の高いソースコードの変更箇所が優先的に表示されるため、レビュアーは本発明の表示する順に重点的にレビューを行えばよくなり、レビューコストの削減と、効果的なレビューを実現することができる。
（２）加えて、関心の高いと思われるソースコードの変更の量や、今まで行ったレビューの多寡により、作業者の作業量やその重要度を推測することができ、作業者の評価を行うことが可能となる。
（３）加えて、スコア計算処理部がバージョン管理システムのブランチ情報と連携することで、ソースコードの変更を行う適用先ブランチの情報により、その変更の重要度を推測することが可能となる。
（４）作業者レビュー補正値をスコア計算処理部に追加することで、多くのレビューが必要な習熟度の低い作業者が行った変更が、本システムにおいて必要以上に重要と誤認されることを防ぐことができる。

１０１ 計算機、１０２ ＣＰＵ、１０３ メモリ、１０４ ネットワークデバイス、１０５ ストレージデバイス、１１０ ＯＳ、１０６ ネットワーク、１０７ 開発者端末、２０１ レビューシステム、２０２ Ｗｅｂフロントエンド、２０３ ソースコード受付部、２０４ 作業者評価表示部、２０５ レビュー受付部、２０６ レビュー依頼受付部、２０７ マージ処理部、２０８ 管理単位分割処理部、２０９ スコア計算処理部、２１０ 作業者評価値計算部、２１１ レビュースコア情報記録部、２１２ レビューデータ記録部、２１４ スコア情報記録部、２１５ ソースコード記録部、２２０ レビュー依頼記録部、６００ レビューコメントテーブル、４００ スコアテーブル、９００ 作業者レビュー補正値テーブル、７００ ブランチ補正値テーブル、８００ スコア補正値テーブル、３００ 管理単位テーブル、２１３ 作業者評価値テーブル

Claims (14)

1. ソースコードを格納するソースコード記録部と
   前記ソースコードの修正のレビュー依頼を受け付けるレビュー依頼受付部と、
   前記レビュー依頼受付部で受け付けたソースコード修正をソースコード記録部に保持されたソースコードへ反映するマージ処理部と、
   レビュー依頼を受け付けた前記ソースコード修正を対応する管理単位に分割し、スコア情報記録部に格納された前記管理単位と前記管理単位に対する関心度を示すスコアと、ユーザ情報記録部に格納された前記レビュー依頼を発行したユーザＩＤに対応づけられたユーザスコア情報を用いて修正に対応する管理単位毎にスコアを計算するスコア計算処理部と、
   計算された管理単位のスコアとレビュー依頼を対応づけてスコアの降順に出力する出力部とを備え、
   前記スコア情報記録部に格納されたスコア情報は対応する管理単位が修正されたときに加算され、
   前記ユーザ情報記録部に格納されたユーザＩＤに対応づけられたユーザスコアはレビュー依頼を受け付けたときに加算されることを特徴とするソースコードレビューシステム。
2. 前記管理単位は少なくとも関数を含むことを特徴とする請求項１に記載のソースコードレビューシステム。
3. 前記ソースコード記録部は複数のバージョンのソースコードを格納し、
   前記複数のバージョンのソースコードの一つにソースコード修正のレビュー依頼を受け付けソースコードが修正されたとき、当該修正された管理単位を含む他のバージョンのソースコードについても対応する管理単位のスコアを加算することを特徴とする請求項２に記載のソースコードレビューシステム。
4. 前記ソースコードにソースコード修正のレビュー依頼を受け付けソースコードが修正されたとき、当該修正された管理単位に関連する他の管理単位のスコアを加算することを特徴とする請求項２に記載のソースコードレビューシステム。
5. 前記関連とはソースコードを修正した管理単位を含む関数の呼び出しであることを特徴とする請求項４に記載のソースコードレビューシステム。
6. 加算するスコアは前記修正された管理単位との関連性に基づいて異なる値を加算することを特徴とする請求項４に記載のソースコードレビューシステム。
7. 過去に依頼されたレビュー依頼の内容と数に基づき管理単位に対応づけてレビューコメントを出力することを特徴とする請求項１に記載のソースコードレビューシステム。
8. ソースコード記録部がソースコードを格納し
   レビュー依頼受付部が前記ソースコード修正のレビュー依頼を受け付け、
   マージ処理部が前記レビュー依頼受付部で受け付けたソースコード修正をソースコード記録部に保持されたソースコードへ反映し、
   スコア計算処理部がレビュー依頼を受け付けた前記ソースコード修正を対応する管理単位に分割し、スコア情報記録部に格納された前記管理単位と前記管理単位に対する関心度を示すスコアと、ユーザ情報記録部に格納された前記レビュー依頼を発行したユーザＩＤに対応づけられたユーザスコア情報を用いて修正に対応する管理単位毎にスコアを計算し、
   出力部が計算された管理単位のスコアとレビュー依頼を対応づけてスコアの降順に出力し、
   前記スコア情報記録部に格納されたスコア情報は対応する管理単位が修正されたときに加算され、
   前記ユーザ情報記録部に格納されたユーザＩＤに対応づけられたユーザスコアはレビュー依頼を受け付けたときに加算されることを特徴とするソースコードレビュー方法。
9. 前記管理単位は少なくとも関数を含むことを特徴とする請求項８に記載のソースコードレビュー方法。
10. 前記ソースコード記録部は複数のバージョンのソースコードを格納し、
    前記複数のバージョンのソースコードの一つにソースコード修正のレビュー依頼を受け付けソースコードが修正されたとき、当該修正された管理単位を含む他のバージョンのソースコードについても対応する管理単位のスコアを加算することを特徴とする請求項９に記載のソースコードレビュー方法。
11. 前記ソースコードにソースコード修正のレビュー依頼を受け付けソースコードが修正されたとき、当該修正された管理単位に関連する他の管理単位のスコアを加算することを特徴とする請求項９に記載のソースコードレビュー方法。
12. 前記関連とはソースコードを修正した管理単位を含む関数の呼び出しであることを特徴とする請求項１１に記載のソースコードレビュー方法。
13. 加算するスコアは前記修正された管理単位との関連性に基づいて異なる値を加算することを特徴とする請求項１１に記載のソースコードレビュー方法。
14. 過去に依頼されたレビュー依頼の内容と数に基づき管理単位に対応づけてレビューコメントを出力することを特徴とする請求項８に記載のソースコードレビュー方法。

Images