コードレビューの仕方

今日自分の書いたコードをレビューしてもらった。

ほんの数十行のコード。
コードレビューをお願いする直前に、もう一度よく見直した。そしたら1つバグが見つかった。
で、ちょっと思った。このバグはコードレビューに出したら見つかっただろうかと。
見つかったかもしれないし、見つからなかったかもしれない。

それは分からないのだけれど、もし自分がこのコードのレビューをしたとしたら、見つけられた可能性は・・・やっぱり5分5分だと思う。（少なくとも僕は見逃しそうになったわけだし）

問題はコードレビューの意図だと思った。僕が見つけたバグはそのコード全体の全体の動きに比べると小さなもので、ある意味そのバグがあっても、ほとんどの場合うまく動いてしまう。

1つ1つの命令の詳細をレビューで追っていくと、ものすごく時間がかかるから、たいていの場合、自分が普段気をつけているいくつかのポイント（ポインタがNULLだったらどうかとか、メモリは開放されているかとか）を中心に見ていくことが多い。
やっぱり細かいところを1つ1つ追っていくのは骨が折れる・・・って最初から思って、やっぱりあんまり真剣に頭を使ってひとつひとつ追っていかない。（これは人のコードを修正するときの、最初のオーバーヘッドの重たさに似ている）

で、ちょっと考えた。なんとか頭を使って読んでもらう方法はないか。レビューアーには嫌われる方法かもしれないけど、以下の方法。

「あらかじめバグを仕込んでおいて、それを伝える」

最低1個はバグがあると言っておけばいい。そうすれば少なくとも1つはバグを見つけてもらえる。同じ所かもしれないし、違うところかもしれない。でも、きっと頭を使ってやってくれるはずだ。

コード量がある程度多いなら、3つとかでもいいと思う。最低3つはバグが存在するのだから見つけられる。コード領が多ければ、別の3つを見つけてくれる可能性が高い。
バグが見つからなければ、見つかるまでやってもらう。でも、見つけられるだけの情報（関数の仕様とか）はちゃんと伝えなくちゃいけない

あと、埋め込むバグは難しいものにしなくてはいけない。簡単なのだとみんなそれを見つけてくる。

整数オーバーフローとか、オフバイワンとか、ちゃんと考えないと見つからないやつがいい。

誰かやってみてください。で、どれくらい嫌がられるか報告ください。