コードレビューの道具、使っていますか?

コードレビューをはじめとしたソフトウェアレビュー/ソフトウェアインスペクションをスムーズに実施できる道具(技法、仕組み、ツール)を紹介します。レビュー/インスペクションは人手によるところが大きく自由度の高い活動ですが、技法、仕組み、ツールの利用によって半自動化、定型化、効率化できる部分が多くあります。本記事では、それらの道具をレビュー/インスペクションのフェーズ毎に紹介します。また、その一端を他のレビュー/インスペクション技術者とともに実感できるイベント「ソフトウェアインスペクションワークショップ2009」(7月2日開催)の紹介もします。

森崎 修司, 工学博士, 国立大学法人 奈良先端科学技術大学院大学 情報科学研究科

森崎 修司 奈良先端科学技術大学院大学情報科学研究科にて工学博士を取得後、情報通信企業にてオンラインストレージサービスの企画~開発、運営に従事。文部科学省リーディングプロジェクト「e-Society基盤ソフトウェアの総合開発EASEプロジェクト」においてソフトウェアの高信頼化、開発の効率化に関する検討を130社超の企業とともに実施。ソフトウェアレビュー/ソフトウェアインスペクション、エンピリカルソフトウェア工学、ソフトウェア計測を研究の主軸とする。ブログ(http://blogs.itmedia.co.jp/morisaki/)



2009年 6月 19日

概要

ソフトウェアレビュー/ソフトウェアインスペクションといえば、人手による目視の検査というイメージが強いのではないでしょうか?そのため「技術的エキスパート、カリスマが参加しなければあまり意味がない」と考えられてしまうことも多いようです。もちろんそうしたエキスパートによる指摘は極めて重要なのですが、全てのコードレビューでエキスパートのスケジュールや工数を確保して、意見をもらうのは現実にはなかなか難しいでしょう。

ソフトウェアレビュー/ソフトウェアインスペクションは始まりから終わりまで、完全に職人芸の域の技術かというと必ずしもそうではありません。実はソフトウェアツールやそれ以外の便利な道具(チェックリストや役割分担)でスムーズに進めることができたり、自動化できる部分も多く存在します。うまく道具に頼ればもっと本質的で人手でしかできない指摘のために時間を使えますし、単純なミスを減らすこともできます。時間に余裕ができれば自身の技術やスキルを磨くこともできるでしょう。

道具による有効性を報告した文献もありますので、読まれてみてはいかがでしょうか(文献[6] [10] )。本記事では具体的な例としてコードレビューの道具を紹介していますが、必ずしもソースコードを対象としたレビュー/インスペクションだけに限定した道具の紹介ではありません。設計ドキュメントをはじめ、他のドキュメントのレビュー/インスペクションでも利用できるものが多くあります。


コードレビューのフェーズ

まず、コードレビューにどのようなフェーズがあるか整理します。図1は文献[4]でFagan氏が定義したレビュー/インスペクションのフェーズと活動内容です。「道具」の項目は筆者が追記したものです。

それでは、各々のフェーズでどのようなコードレビューの道具があるかをみていきしょう。

図1. ソフトウェアレビュー/ソフトウェアインスペクションのフェーズ 文献[4]

ソースコード静的解析ツールでレビュー箇所を見極める(準備、実施フェーズ)

ソースコード静的解析ツールはプログラムを実行せずソースコードの字面から情報を抽出するツールの総称です。たとえば、ソースコードメトリクスの算出、定義されたパターンに基づく潜在的不具合箇所の検出、コーディング規約の逸脱の検出などがあります。これらは、いずれも不具合が入りやすい場所を探すために役立ちます。たとえば、複雑な場所には不具合が入りやすいことが知られています。ソースコード静的解析ツールはその複雑な場所を特定できます。複雑な場所を重点的にレビューすることで効率化が期待できます。他にも、メモリ領域やファイル等のリソースを確保した後に解放し忘れている可能性のある部分を静的解析ツールで検出し、レビュー(目視)でチェックするといったことができます。

ソースコードメトリクスには分岐やループの数、関数/メソッドへの引数の数、呼び出している関数/メソッドの数、ソースコード行数等、様々なものがあります。これらのメトリクスと品質にはある程度の相関関係が確認されており、たとえば、分岐やループが多い部分(複雑な部分)には、不具合が混入しやすいことが複数の事例で確認されています。ご自身の開発においても経験があるのではないでしょうか。ソースコードメトリクスだけで不具合があるソースコードを特定することはできませんが、不具合を含む可能性の高いソースコード(Fault-proneソースコード)を挙げることはできます。たとえば文献[1][9]等で検討されています。また、Metrics Data Program NASA IV&V FACILITYでは、NASAが開発したソースコードのソースコードメトリクスと不具合の発生の有無を一覧表にしたデータをダウンロードできます。ここでもその傾向が確認できます。

他にもソースコードから実行フローを推測し、配列の境界を越えたアクセスやNULLポインタのアクセスの可能性がある箇所を検出するものもあります。ソースコード静的解析は以下のdeveloperWorks記事でも紹介されています。

現時点では、研究段階にありますがソースコードからデザインパターンを抽出する静的解析ツールとして、以下のものがあります。デザインパターンはレビューアがソースコードを理解する際の大きな助けになります。また、デザインパターン固有の潜在的不具合を探す際に役立てることができるでしょう。

このようにソースコード静的解析ツールを使えば、どこを重点的にレビューすべきか(準備フェーズ レビュー部分決定)のヒントを得ることができ、不具合箇所の候補(実施フェーズ)を効率的にみつけることができるでしょう。


レビュー/インスペクションでは役割分担も道具の1つ(準備、実施フェーズ)

レビュー/インスペクション実施時の役割分担が明確になっていないせいで、スムーズな進行ができない場合があります。図1の準備フェーズであらかじめ役割を決め、実施フェーズでその役割にもとづいて指摘することにより、欠陥指摘に集中できます。役割の定義もレビュー/インスペクションの道具の1つといえるでしょう。表1はIEEE 1028 Standard for Software Reviews and Auditsや論文”An Encompassing Life Cycle Centric Survey of Software Inspection”をもとに筆者がまとめたものです。1人がこれらの複数の役割を担当することもできますし、1つの役割を2人以上で担当することもできます。レビューア/インスペクタは複数人で担当することが多いでしょう。

(IEEE 1028 Standard for Software Reviews and Audits[8], 文献[11]をもとにした)

表1 ソフトウェアレビュー/ソフトウェアインスペクションの役割定義
役割説明
進行役(モデレータ)目的に沿って参加者を誘導します。通常1人で担当し決められた時間内で参加者が欠陥をみつけやすくするための環境を作ったり、進行したりします。話が横道にそれた場合に本題に戻したり、記録係の記録が指摘に追いついていない場合に、記録が追いつくまで待ったりします。時間配分も進行役の重要な役目の1つです。進行役のスキルはレビュー/インスペクションの結果に大きく影響を与えます。
レビューア/インスペクタ欠陥を指摘します。
記録役レビューア/インスペクタが指摘した内容を書きとめていきます。通常1人で担当します。レビューア/インスペクタの指摘を漏れ、誤りなく記録するには経験が必要です。メールベースで指摘を集める場合には、指摘の重複をなくしたり、整理することも記録役が担当します。
オーガナイザレビュー/インスペクションがどのタイミングでどのように実施されるか、開発計画全体を含めた計画を立てます。オーガナイザはレビュー/インスペクションの結果、工程移行を検討したり、アウトプットを他の手順でどのように使うかを決めたりします。オーガナイザはプロジェクトリーダやマネージャであったり、他のレビュー/インスペクションのオーガナイザを兼任していたりすることもあります。
作成者(オーサ)レビュー/インスペクションの対象物の作成者です。機能やサブシステム毎に分類すれば、通常1人になります。
リーダ(Reader)、プレゼンタレビュー/インスペクション対象を説明します。作成者以外が担当し、作成者になりかわって説明します。

コーディング規約はコードレビューの手間を減らす(準備フェーズ)

コーディング規約に準拠させることでソースコードは読みやすくなります。レビュー前にコーディング規約への準拠をチェックしておくことによりレビューアがソースコードを理解する時間を短くできます。コーディング規約はソースコードの表記上のルールを決めたものです。通常、プログラミング言語には、コンパイラやインタプリタが解釈するための最低限のルールを定めた言語仕様が存在します。コーディング規約は読みやすさやミスを減らすことを目的として言語仕様とは別にソースコードの表記、変数名の命名規則等に制約を加えたものです。言語仕様に従っていないソースコードやプログラムは通常、実行ができませんが、コーディング規約に従っていないソースコードやプログラムは言語仕様に従っていれば実行はできます。

コーディング規約には様々な目的が存在しますが、代表的な目的は可読性、拡張性、信頼性の向上です。可読性向上には、改行位置、タブやスペース等の空白文字の扱い、条件文の書き方等が含まれます。これらが一定の書き方で揃えられていると読みやすくなります。拡張性の向上には、複数箇所に出てくる定数をそのまま使うのではなく定数定義(C言語だと#defineマクロ)してから使う等が含まれます。定数定義しておけば、定数値の変更の際に一括してモレなく変更できます。信頼性の向上には、構造が複雑になり不具合が入り込みやすいgoto文や再帰関数呼出しを使わない等が含まれます。

コーディング規約には様々なものが存在し、同一組織内で使うことを前提としたもの、産業用のもの、納品の条件になっているもの、公開されているもの等があります。自動車産業むけC言語ソースコードのコーディング規約であるMISRA-C[3]、GCC Coding Conventions[5]をはじめとして多数のコーディング規約が存在します。また、IPA SEC(独立行政法人情報処理推進機構 ソフトウェアエンジニアリングセンター)のコーディング作法[7]のように指針を示したものも存在します。

コンパイラのウォーニング(警告)でもコーディング規約と同様の効果が得られる(準備フェーズ)

コンパイラの多くは、コンパイルエラーではないけれども潜在的な問題箇所を警告する機能を持っています。専用の静的解析ツールと比較すると機能は限られていますが、試してみるには適しているでしょう。オープンソースのコンパイラgccだと「-Wall」コマンドラインオプションを指定すると詳細な警告を出力します。

警告には、たとえば、関数/メソッド内で使われていないのに宣言されているローカル変数の指摘、値が初期化されていない変数を利用しようとしている(代入文の実行よりも前に値を参照しようとしている)、推奨されないライブラリを利用しようとしている、等をソースコードの具体的な位置(行番号など)と共に警告として出力してくれます。警告が出ないようになるまでソースコードを改善することで読みやすさを向上したり、欠陥の作りこみを防ぐことができます。


リーディング技法(実施フェーズ)

欠陥を指摘する際の読み進め方としてリーディング技法があります。もっともよく使われているリーディング技法はチェックリストを使ったものでしょう。チェックリストには「確保したリソースを正しく解放しているか?」「必要以上の繰り返し処理で性能問題を引き起こさないか?」等の欠陥をみつけるための質問が記されており、レビューアがその質問に答えるためにソースコードを読んでいくことで、欠陥を見つけられるように作られています。対象ソフトウェアにあわせて、チェックリストの一部を選んで使うこともあります。

表2 パースペクティブベースドリーディングの観点の例 文献[2][12]より
観点初級プログラマエキスパートプログラマ
読み進め方の指示自身を対象システムに関する知識が少ないプログラマだとしてユースケースを中心に読み進めてください。自身を対象ソフトウェアに関する豊富な知識をもつプログラマだとしてシステム全体でどのクラスがもっとも重要か、またどのクラスがもっとも複雑かを考え、最も複雑、重要なクラスから進めてください。
質問
  • 機能を理解するときやソースコードが正しいかどうかを判断するためにソースコードのコメントやドキュメントは十分でしたか?
  • ユーザの操作が関与する部分全てにおいてエラー処理や例外処理はありますか?
  • エラー時やデバッグのためのログ出力は適切な場所で行われていますか?
  • データ構造は適切に使われていますか?また、そのデータ構造は実行速度やメモリ使用量とのトレードオフが考慮されていますか?
  • これまでの経験からこのクラスで実現されている機能は今後の開発でも必要になりそうですか?もしそうなら、再利用性を高めるための追加コストを投じる価値がありそうですか?

他にも、読み手に「ユーザ」「テストエンジニア」等の観点(パースペクティブ)を割り当てて、読み進めていくパースペクティブベースドリーディングという技法もあり、様々な観点からレビューするので網羅的な欠陥指摘ができることが報告されています。「ユーザ」の観点が割当てられれば、ユースケースに沿って読み進めたり「テストエンジニア」であれば、どのようなテストケースで正しく動作したと判断するかを考えながら読み進めることができ、通常のレビュー/インスペクションよりも広い視点から欠陥を指摘できます。観点は必ずしも実際に開発に携わる立場と一致している必要はなく、プロジェクトリーダが顧客側のユーザの観点を担当することもできます。また、同じプログラマやテストエンジニアでも、スキルによって観点をかえることもあります。表2に文献[2]で紹介されているプログラマのスキル別の観点を示しています。また、その内容の詳細は文献[12]や「技法とテンプレート!第5回:インスペクションを自在にカスタマイズ」(ThinkIT, 2009/03/30)でも紹介しています。

また、要求仕様書を対象としたパースペクティブベースドリーディングが過去のdeveloperWorks記事でも紹介されています。

Getting requirements right: The Perspective-Based Reading technique and the Rational Unified Process

これらのリーディング技法を実際にやってみようとする方むけに筆者らの研究グループのWebページで記録フォーマットを公開しています(奈良先端科学技術大学院大学 ソフトウェア工学講座)。


レビュー支援ツールは指摘の記録と管理を効率化する(実施フェーズ)

コードレビュー支援ツールは、ソースコード閲覧機能、ソースコード中の任意の場所に欠陥の指摘やメモを記録する機能、指摘した欠陥やメモを一覧する機能をもちます。図2, 3はEclipseのコードレビュー支援プラグインJupiterの画面写真です。図2は29行目に「アクセス修飾子publicをprivateにすべき」という指摘を画面下「レビューエディタ」ペインに入力している様子を表しています。図3の下部では、これまでの指摘を「レビューテーブル」ペインで一覧形式で表示しています。

また、他にもReview Board, Rietveldをはじめとして、様々な支援ツールがあります。バグ管理ツールやIssue tracking system(課題管理ツール)に指摘された欠陥を入力するだけでも欠陥の記録、管理に役立ちます。「バグ種類」のような項目に「コードレビュー指摘」という項目を追加するだけなので、もしテキストファイルや表計算ソフトで記録をとっている場合には、試してみてください。記録、管理の手間が大幅に減るでしょう。

今回紹介した道具はコードレビューに関するものでしたが、紹介した道具のうち、役割定義、リーディング技法、指摘記録ツール、指摘管理ツールは、必ずしもコードレビューに限定されるものではなく、プロジェクト計画、要件定義書、仕様書、各種設計書、テスト計画、運用マニュアル、ユーザマニュアル等ありとあらゆるドキュメントのレビュー/インスペクションに使えます。

図2. Jupiterコードレビュープラグインによる指摘の記録

クリックして大きなイメージを見る

図2. Jupiterコードレビュープラグインによる指摘の記録

図3. Jupiterプラグインによる指摘一覧(下部)

クリックして大きなイメージを見る

図3. Jupiterプラグインによる指摘一覧(下部)


まとめにかえて

レビュー/インスペクションを実施する前に道具によって「見てもらうための準備をしている」ことは、レビューア/インスペクタの心理的にも大きな安心になります。レビューア/インスペクタは「なんでこんな状態で読ませようとするんだよ」という気持ちに陥りがちで、その結果として本質的でない指摘を多発したり、作成者の個人攻撃をしたりすることがあります。「見てもらうための準備」はレビューアがその気持ちに陥ってしまうのを防ぎます。

レビュー/インスペクションの道具がそろい、ツールによる自動化や半自動化が進めば、道具の間を補完するような統合ツールが必要になってきます。レビュー/インスペクションの結果や進行状況を統合管理するワークフロー管理ツールも大きな意味でのレビュー/インスペクションの道具立てといえるでしょう。

レビュー/インスペクションは多くの組織の商用開発やオープンソース開発で定着しつつあるといえます。重要社会インフラと呼ばれるようなシステム開発においてレビュー/インスペクションが実施されていないソフトウェアは存在しないでしょう。しかしながら、他のソフトウェア開発活動と比較して、レビュー/インスペクション活動に関する情報共有はまだまだ十分でないと筆者は考えています。本稿がそのような情報共有を少しでも促せることができればと願っています。


コードレビューを実感できるイベント

本稿で紹介した内容の一部を「ソフトウェアインスペクションワークショップ2009」(2009/7/2(木) 13:30~ 東京三田)で実際に紹介する予定です。他にも、ワークショップでは参加者の方に実際にJavaソースコードをコードレビューしていただき、それをもとに参加者間でディスカッションいただきます。また、日本IBMのインスペクションのスペシャリスト、インスペクション研究の国際連携メンバからインスペクションの技法や動向を紹介する予定です。開催プログラム、申込み方法等詳細はこちらをご覧ください。


謝辞

本稿の執筆にあたって、服部 京子氏、保田 裕一朗氏、伏田 享平氏、亀井 靖高氏に多大なご協力をいただきました。本稿で紹介した研究の一部は文部科学省「次世代IT基盤構築のための研究開発」の委託に基づくものです。また、本稿で紹介した研究の一部は、文部科学省科学研究補助費(若手B:課題番号21700033)の助成を受けました。

参考文献

  • [1] L.C. Briand, V.R. Brasili, C.J. Hetmanski, "Developing Interpretable Models with Optimized set Reduction for Identifying High-Risk Software Components," IEEE Transactions on Software Engineering, vol. 19, no. 11, pp. 1028-1044 (1993)
  • [2] C. Denger, F. Shull: A Practical Approach for Quality-Driven Inspections. IEEE Software Vol. 24 No. 2, pp. 79-86 (2007)
  • [3]Guidelines for the Use of the C Language in Vehicle Based Software
  • [4] M.E. Fagan, “Advances in Software Inspection,” IEEE Transaction on Software Engineering, vol. 12, no. 7, pp. 744-751 (1986)
  • [5]GNU Code Convention
  • [6] 細川 宣啓, "Smoke Sensor System" としての Quality Inspection の適用事例"プロジェクトマネジメント学会研究発表大会予稿集2003, pp. 279-284(2003)
  • [7]IPA ソフトウェアエンジニアリングセンター: 組み込みソフトウェア開発向けコーディング作法
  • [8] IEEE 1028 Standard for Software Reviews and Audits (2008)
  • [9] 亀井 靖高, 森崎 修司, 門田 暁人, 松本 健一, “相関ルール分析とロジスティック回帰分析を組み合わせたFault- Proneモジュール判別手法,” 情報処理学会論文誌, Vol.49, No.12, pp.3954-3966 (2008)
  • [10] Nagappan N., Williams L., Hudepohl J., Snipes W., Vouk M., "Preliminary Results On Using Static Analysis Tools For Software Inspection,"International Symposium on Software Reliability Engineering, pp.429-439 (2004)
  • [11] O. Laitenberger and J. M. DeBaud: “An Encompassing Life Cycle Centric Survey of Software Inspection, Journal of Systems and Software, Vol. 50, No. 1, pp. 5-31 (2000)
  • [12] 森崎 修司, “ソフトウェアインスペクションの動向,” 情処処理学会誌, Vol.50, No.5, pp.377-384 (2009)

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Java technology
ArticleID=396674
ArticleTitle=コードレビューの道具、使っていますか?
publish-date=06192009