対象別インスペクション攻略法！

コード、テスト計画の攻略法

　コードレビューを行う際に最初にするべきことは、プログラム全体本数のうち開発者が担当した部分はどこかを確認することです。全体中の位置づけを確認してからレビューを行わないと、正しいスコープの機能を開発しているかをレビューできないからです。これはプログラム一覧表や割り当て表でもかまいませんし、設計書上の全体像に赤丸をつけたレベルでもかまいませんが、レビュー担当者に「この位置の機能を作りました」と必ず伝達するようにしましょう。

　コードをインスペクションする1つのコツは、最初の1行目から読み始めないことです。これも「全てのインスペクションは全体像から」という原則どおり、まずざっとエディターをスクロールして全体を見て細かい内容に入り込まないようにしてください。筆者がオススメは次のようなポイントから確認することです。

1．総行数は何行か？
2．構造化されているか？
3．1人で書いているか？複数人で修正しているか？
4．難しいロジックか？難しい入出力か？

　例えば、1、2や3を確認する方法として、エディターを先頭から末尾行に向けてスクロールするのではなく、逆に末尾から先頭へスクロールする方法をオススメします。最終行番号の取得ができると同時に、大抵のプログラムは末尾に「最終変更したロジック」を追加する場合が多く、末尾の関数やメソッドだけ、他と書式が違うコードが入っていることがあります。このような書式・書法違いのコードを見つけたら「書き方が違う複数人数でこのコードを開発したのだな」と理解できます。

　またコードと設計書を付き合わせる検査などは、一見手間がかかりますが、コードあたり少なくとも数箇所は実施をオススメします。この検査で検出されるコードの欠陥は次図2のようなものが検出できるからです。

コードのインスペクションポイント

　もしも、図2のような仕様書からコード実装がなされていたときにどこがインスペクションポイントになりますか？そうです。S1からC1への解釈・変換にエラーがあることがわかります。というのも、よく注視して検査してみると、以下の文があります。

S1：もし、Xの値がAまたはBでない場合、

　文中の「～でない場合」は、注意しないと見逃す日本語のあいまいな文型・パターンです。この仕様は～でないという表現がどこまでかかるかのあいまいさを含んでいるため、以下の両方の解釈ができます。

C1：（Xの値がA）またはNot（Xの値がB）
C1a：Not（Xの値がAまたはB）

　つまり元の仕様書に欠陥が内包されており、短絡的にそのまま実装してしまったということがわかります。これは検出難易度が高く、抜本的な予防策がないというタイプの「日本語のあいまい性」に起因する欠陥ですので、複数の人数かつコードと設計書を付き合わせるインスペクション工程を設けることが何より有効です。

　このように、コードのインスペクション時には「コードだけを検査しないこと」というのも重要になります。複数人数でコードを個人ごとに事前インスペクションしておくことで、コード内のエラーは検出可能ですが、上記のような欠陥の検出に絞り込んでのインスペクションは必ず行うようにしてください。特に結合テスト以降の致命的欠陥数が圧倒的に違います。