コードレビューはどうやるのがいいんだろう

技術

僕自身はコードレビューの経験はほとんど無いですが、やったほうがいいのは間違いない。

やり方としては一個のモニタをレビューする人とされる人が見ながら、レビューされる人が説明していくのがいいと思ってる（Web上のコードレビューシステムは運用が難しい気がしている）。ほとんどペアプロなのだが、このやり方だと工数がかさむのは間違いない。レビュー箇所をしぼるのもいいがプロセスを変えてみるのもいいかもしれない。

例えば、

まずコーディング基準書を配布して、コーディングに取りかかる前に開発者に読んでもらう。
ただしコーディング基準書には多く書かない。多く書かれていても右から左に抜けるだけだから。つうか僕がそうだw
命名規約とかいらんと思ってる。後で書くインスペクションツールやEclipseでチェックできるものは除く。

とりあえず変数のスコープをなるべく小さくすることだけ書いてあればいいのではないか。
具体的にいうとグローバル変数は使わないとか、Javaなら

String hoge = null;

if(...) {
    ...
    hoge = "piyo";
    ...
}

...//このあとhogeは使わない。

みたいにC, JavaScriptライクな書き方じゃなくて

if(...) {
    ...
    String hoge = "piyo";
    ...
}

のように変数は使う場所で宣言する。Eclipse+Javaならまず右辺を書いてCtrl+2+Lする。

その次にインスペクションツールを活用する。
僕は仕事が静的解析ツールの担当なのだが、よく聞く話としては指摘の数が多すぎて結局使わなくなるというもの。
＃さらにいうとFindbugs等のフリーのツールはどう直せばいいかわかりにくいと思ってる。
だからどこを直すかはかなり現場調整が必要だと思う。

たしかにいいコードでも指摘の数を0にするのは現実的でないし、基盤部分だと指摘が多くなると思う。
また例えばメトリクス関連のルールだとどう直せばいいか途方にくれるだろう。
とくにエンハンスだったら既存コードはまずいじれない。

ただしメソッドの行数は長くならないように抑えた方がいい。そうじゃないとエンハンスが辛くなる。
新規に作っている部分でメソッドの行数が長くなるようなら、EclipseのAlt+Shift+Mでメソッド分割すればいい。
まだテストしていない段階なら、これぐらいの負担は大丈夫だとおもう。
優秀な開発者ならこんなこといわれなくてもやっているだろうが。

コーディング基準書配布、インスペクションツールときて最後が人によるレビューになる。
前のプロセスがそれなりに回っているならレビューの負担も減るはず。

コードに限らずレビューアがボトルネックになるとかなりマズいのでいいやり方を考えていきたい。