一ヶ月前に「ソフトウェアインスペクションの試行」(http://dev.ariel-networks.com/Members/inoue/software-inspection)の記事を書きました。 実施を始めて、約一ヶ月経ったことになります。

実経験と合わせて読めば何かヒントをつかめるかと思い、「ピアレビュー」を読んでみました。

• http://www.amazon.co.jp/exec/obidos/ASIN/489100388X/arielnetworks-22/

結論から言えば、読んでも役に立ちません。最初の4章ぐらいは読んで楽しい(役には立たないですが)ところもありましたが、後半は読むのもつまらない本でした。

2章の最後の「レビューの原則」は知っておいて損はありません(ぼくは、読む前から知っていたので特に感銘は受けませんでしたが)。次の5つです。

• 始める前に自身のエゴをチェックせよ(改善提案に受容的であれ)
• レビューチームは小さくせよ(参加者は3-7人。呼ぶのはブタだけ、ニワトリを場に呼んではいけない)
• レビューでは問題の発見に努め、解決を試みるな
• レビューミーティングは約2時間に制限せよ
• 事前準備を要求せよ

繰り返し書いてあるプロセス上のポイントが次の3点です。

• インスペクションを計画せよ
• インスペクションの結果を記録せよ
• インスペクションを(部下の)評価に使うな

これもまあ本を読む前から自明です。

興味深いと思った部分が、「単体テストの前にコードインスペクションせよ」の部分でした。単体テストの後に実施すると、どうせバグは無いだろうという心理的バイアスがかかるため、らしいです。ここは異論がありそうな部分です。

3章に「インスペクション」、「レビュー」、「ウォークスルー」の比較表があります。 誰が定義したんだ、と言いたくなる比較表で、この定義に従う必要性は感じませんが、この3つの用語、日常の中であまりに曖昧すぎて何を指しているのか分からないのも事実です。

比較表を見る限り、モデレータ、作成者、読み手の役割の部分が明らかな相違です。

• インスペクション: モデレータ、作成者、読み手を、それぞれ別の人が行う。
• レビュー: インスペクションとウォークスルーの中間形態(モデレータと読み手が一致する場合など)。
• ウォークスルー: 作成者がモデレータかつ読み手を兼ねる。

コードインスペクションをしていて思うのが、本当は、デバッガで動的にコードを追いながらコードを見る方が効率的だろうな、という思いです。 デバッガを使わず、頭の中だけでコードを動かしてバグを見つけられる自分のスキルを誇らしく思う気持ちは、正直に告白すれば、あります。しかし、自分のささやかなプライドを満たすことがコードインスペクションの目的ではありません。

基本的にデバッガは好きです。gdbは好きなUnixコマンドの2番目ぐらいです(1番はemacs)。マイクロソフト製のソフトの中で一番良いと思っている(あるいは、Windowsにあって一番羨ましいと思っているのが)Visual C++のデバッガの部分です。

残念ながら、Javaでは事情が異なります。eclipseでコードを動かしながらコードインスペクションをしたら、ミーティングの20%ぐらいが待ち時間になりそうです。イライラして集中できなくなるので、実施できません。