彼は最も酷いレビューのいくつかの例を次のように挙げている。
コーディングを行った開発者を脅したり攻撃したりする魔女狩りレビュー
深刻な問題は放っておいて、記述方法やインデントについて注力する中括弧論争レビュー
レビュアーが事前にコードを見ることがなく、また事前準備もない状態でレビューに臨む盲目レビュー
コードの一部のみをレビュー対象とし大事な箇所が対象として除外されてしまう除外レビュー
レビューを行うことが不可能である、またレビューをしたとしても効果のないくらいコードベースが大きくなってから行う紙の無駄使いレビュー
プロジェクト管理上こなさなければならない形式的に実施するトークンレビュー
大多数がプロジェクトに関係なく開発者を威嚇するために存在するような多人数で実施するワールドレビュー
InfoQ: デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
(少なくとも僕が経験したプロジェクトでは)公式のレビューがこういうの以外だった試しがない。
みんな1回でもレビューを経験すると、レビューが嫌になっちゃう。
ここでひとつ、とても大切なことがわかる。
レビューは何をするものか、どのように進めるか、考えたことも調べたこともないままレビューが行われ、その結果レビューという工程は大いに誤解されている、ということだ。
逆に僕は非公式のレビューをずっとやっていて、それは「できる限り早いタイミングで適当なときにレビューする」ということだった。
まず、完成しないとレビューできないということはない。
特に、方向性の違いは作業を進めれば進めるほど違いが大きくなるのだから、完成まで待っていて仮にそうしたことが発覚すると手戻りも大きいし、担当者のモチベーションも大きく下がる。
レビューは数回しかできない、なんてこともない。何度でもできる。
レビュワーもすべての不備を見つけなければならないということもない。
レビューは手軽なものでなければならない。そして、レビューは数時間もかけるものでもない。
InfoQでは20%レビューとなってた。
# 英語圏は20%が好きなの？Googleの20%ルールとか。
20% レビューは、開発の20%が完了した時点で一度レビューを行うべきである、という非常にシンプルな考え方に基づくレビュー手法である。いくつかのチームはイテレーションごとに20%レビューを実施することでその有効性に気が付くかも知れない。それは確かに効果的であるが、チームが継続的なレビューのためのメトリクスを使用して良い仕事をしていた場合、システムの主要機能ごとに20%レビューを行うことで十分であると私は思う。
20%レビューは初期のデザインやコードをクリーンにすることに集中すべきだ。コードの量が比較的管理できる間は、メトリクスはコードの進化と成長を促進させる。
InfoQ: デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
レビューなんてものは、「時間あるとき見といてくれへん？」ぐらいの気楽なものを何度も重ねて(そのためのリポジトリじゃない？)、必要ならその後で公式のレビューをすればいい。
とにかく、完成してからとか、会議室で何十人も集まって何時間もとか、レビューを大仰なものにしないこと。
あと、サイアクなのがレビューの時間になって初めてレビューの対象(設計書、ソースコード)をレビュワーが読み出すこと。
それはレビューじゃないよ。読書の時間。
事前に読んで調べて考えてはレビュワーの責務だよ。
