その1 を書いてから随分時間が経ってしまった。次はどうなったというツッコミはもちろん無いが、気分新たにその2である。
前回は人のコードを読むと必ず出てくる「気に入らない部分」に対してどう対応するかというのをテーマに挙げ、「自分の癖は押し付けないが直感に合わない部分は最低コメントはつけてもらう」を一つの答えとして導いてみた。無理に押し付けないというのが一番の心がけポイントで、でも全部引くわけではないというところがもう一つのポイントだった。これについては、以前まつもとゆきひろさんが 「基本的に自分に関係ないところは気にしない」と言っていた話も参考に。
さて、今回はコードレビューの実施タイミングをテーマにしてみる。コードレビューの目的はバグを減らすことであり、みんなの認識を合わせることである。教育や勉強面でも効果がありペアプログラミングを実践している環境もあるだろうが、いろんな制約で実施はなかなか難しく、一般にはコードを書いてからレビューすることが多いだろう。その場合よくありがちなのが、こうした方が良いねという議論は出るものの、せっかく作ったんだからとりあえずそのままでいこうとなってしまうケース。明らかな間違いとして見つかったバグは直されるが、一度 OK となった部分はレビュー済みという証しが残る分、見直されることは少なくなる。でもこれ、よく考えると何のためのレビューだったのかよく分からない。
そこで「20% レビュー」のすすめである。この言葉はこちらで紹介されていて知った言葉だが、
20% レビューは、開発の20%が完了した時点で一度レビューを行うべきである、という非常にシンプルな考え方に基づくレビュー手法である。
20% というタイミングはモノがあるのでイメージしやすく、しかも出戻りが十分間に合う時期。20% の段階なのでメインは方針の確認になるが、方針の確認を全部出来てからやろうとすると、書いた人は例外ケースなど自分が苦労した部分を多く語りがちなのでむしろ時間がかかったりする。また 20% レビューは、その後行う 100% レビューに大きな効果をもたらす。量としては8割残っているのだが、方針が確認できている分効率がよいし修正も細かい部分で済むので十分間に合う。細部に部分に目を光らせる余裕が出て濃いレビューができる。
ただしレビューの回数が増えるというデメリットがあるので何よりもチームの理解が重要。勝手にやってもうまくいかない。そういう意味でまず響きのよい20%レビューという単語を広めてしまってもよいかもしれない。また 20% という数字だが、クラス設計の詳細度としての 20% なのか、ユースケースとして 20% なのか、とりあえず動かしてみるという時期の上での 20% なのかも認識を合わせておく必要がある。上記の Web にはこうある。
20%レビューは初期のデザインやコードをクリーンにすることに集中すべきだ。コードの量が比較的管理できる間は、メトリクスはコードの進化と成長を促進させる。
ちなみにこの話はコードレビューにとどまらないのかもしれない。やる前に文句を言うのではなく、終わってから文句を言うのでもない。少し走り出したときにこんな感じでいいよねと確認することは日常生活にも活かせる心がけだと思う。
