今月のテーマはコードインスペクション（コードレビュー）ということで、C言語のコードインスペクションを実施してみました。
今回は自分のコードインスペクションの能力を知ると言うのも趣旨のひとつです。
さて・・・埋め込まれたバグは見つかったでしょうか？？
場所は楽天さんをお借りました。いつもありがとうございます！
今回は12名＋特別ゲストが参加してくれました。
まずは福島さんから今回のコードインスペクションの説明です。
対象コードは「ソースコード行数をカウントする約500行のC言語プログラム」です。
今回はそのコードに仕込まれた欠陥を見つけます。
判定は以下の通り。
*****************************************************************
一本：明らかに欠陥。
想定されている仕様。およびそこから当然導かれる仕様を満たしていない場合。
コード上通るパスの間違いや論理矛盾・誤記
技あり：欠陥かもしれない。
仕様の想定不足（コード欠陥ではない）
明らかでない仕様があり、それによっては間違いであるコード。
コード上通らないパスの存在。そのパス上での間違いや論理矛盾・誤記
効果：欠陥ではないが、指摘としては有効
コード規約上許されていない記述
わかりにくい・ミスを生みやすい記述
論理が適切でない。効率的でない。
言語規約上許されていない記述。機種・コンパイラ依存
無効：間違いではない。
指摘内容は間違いとして認められない。
*****************************************************************
説明もそこそこに早速コードインスペクションを開始しました！！
みんな一気に無言になり、コードの世界にのめり込みます。
そして20分が経過したころ最初の指摘が入りました！！
そこから少しずつ指摘が入ってます。
判定チームは入った指摘に対して、「一本」「技あり」「有効」「効果」の判定をつけていきます。仕込まれた欠陥ではない、新たな欠陥も見つかりました（笑
45分経過後、一旦区切ってコードインスペクション（＝コードレビュー）の説明をしました。
最初はコードインスペクションのザックリとした歴史の説明。
昔は全て人間が目視で実施していたものを、コンパイラや静的解析ツールが普及することで、エンジニアが実施することが少しずつ変わっていきました。テストコードが標準装備されたアジャイル開発などでは、可読性（＝読みやすさ）というところに重点を置いてレビューされています。
一方、大規模のソースコードからバグが偏在している箇所を特定するというサンプリングの技術も紹介しました。
◇読みやすさ（Readable）をコードレビューに求める
参考書籍）
・リーダブルコード
・コードレビュー実践入門 Web+DB Press vol.72
◇大規模になったコードから不具合が偏在しているコードを特定する
参考書籍）
・バグを狙い撃つ技術 Software Design 2013年8月号
そして今回の目的である機能バグに特化したC言語のコードインスペクションのコツをお伝えしました。他にもあると思いますが、今回はベーシックなところに絞ってみました。
さて、今回のサプライズゲストであるIBM細川さん＠東京の登場です。
今回はiphoneを使いFaceTimeで接続してみました。
ネットワークの速度にもよりますが、今回はかなりサクサク動作しましたよー
細川さんからは、何点かアドバイス頂きましたので、覚えているものを書いておきます。
・このコードに求められる品質を考え、レビューの終わりを決めましょう
・コードを大きく見るようにしましょう
・1行ずつ見ていくと小さな欠陥は見つけられるけど、仕様等大きな欠陥は見つけにくい
・関数ヘッダと関数名は、見て役割が分かるようにしましょう。分かりにくいのは何か潜んでいる可能性があります。
・ネストが深いのは複雑なので何か潜んでいる可能性があります。
・ifの数とelseの数。ifに比べてelseが少ないときは例外処理がもれている可能性があります。
IBM-QIのコードリーディングのテクニックは以下のリンクの資料にありますので、興味のある方は読んでみてください。（P28以降）
http://www-06.ibm.com/software/jp/rational/events/innovate2010/day2/pdf/2a-4.pdf
話を聞いていて思ったのは、細川さんの場合はコードに加え、コードを書いた人かどういう癖があるかプロファイルすることで欠陥を推測しているのだと思いました。
正味15分くらいの短い間でしたが、参加者一同とっても刺激になりました！！
細川さん、忙しいところ本当にありがとうございました！！またよろしくお願いします（笑
コードインスペクションの時間が足りなかったのでここからさらに時間を取って、続きを実施しました。
少しコツを得たのか指摘が少しずつ増えていきます。
最後に福島さんの方からまとめです。
『今回わざと埋め込まれた5件の欠陥のうち、見つかったのは1件でした！！
欠陥の指摘件数が少なかったのですが、個人では実はそんなものかもしれません。
チームで実施し、効率よく欠陥を検出していくのが重要だと思います。』
指摘が少なかった件に関しては少し遠慮？があったのかもしれないですね。
気になってはいたが、完全なバグと分かるまで書かなかった人もいたようです。
せっかくなので、福島さんが紹介してくれたJaSST08 tokyoでのCapers Jonesさんの資料も掲載しておきます。Capersさんのデータによると、コードインスペクションが一番欠陥検出率が良いようですね！！
http://www.jasst.jp/archives/jasst08e/pdf/A1.pdf
コードインスペクションとは直接関係ないですが、「一本」と判定された参加者はとっても嬉しそうだったのを見て、コードインスペクションにも楽しくなる仕組みを入れるというのは重要だと感じました。
レビューで「影響度大」とか「Aランク」とか言われるよりも、「一本」の方がスッキリしませんか？
JaSST東北の基調講演で湯本さんがお話していた楽しくする仕掛け＝ゲーミフィケーションという概念がそれに当たるのかなとふと思いました。
最後はビアバッシュをしながらコードインスペクションの話や品質の話や色々な話をしました。
今月も本当にいい勉強会でした！！ありがとうございました！！