デザインとコードレビューに関する興味深い記事(source)でKirk Knoernschild氏(source)は、レビューを行うということは、ソフトウェアの品質を改善することを約束し、基準の順守を保証し、そして価値ある開発者の教育ツールとなると述べている。しかしながら、レビューの実施方法にその効果は左右される。レビューは、ある組織ではソフトウェア開発工程で本当に意味のあるものであるかもしれないが、その一方で別の組織では形式的なお役所仕事の一部となってしまっているかも知れない。
彼は最も酷いレビューのいくつかの例を次のように挙げている。
コーディングを行った開発者を脅したり攻撃したりする魔女狩りレビュー
深刻な問題は放っておいて、記述方法やインデントについて注力する中括弧論争レビュー
レビュアーが事前にコードを見ることがなく、また事前準備もない状態でレビューに臨む盲目レビュー
コードの一部のみをレビュー対象とし大事な箇所が対象として除外されてしまう除外レビュー
レビューを行うことが不可能である、またレビューをしたとしても効果のないくらいコードベースが大きくなってから行う紙の無駄使いレビュー
プロジェクト管理上こなさなければならない形式的に実施するトークンレビュー
大多数がプロジェクトに関係なく開発者を威嚇するために存在するような多人数で実施するワールドレビュー
Kirk 氏は効果的なレビューを行うために次のように考えている。チームはできるだけレビュープロセスの自動化に取り組みメトリクスを集めるべきである。また、チームは開発者がコードチェックの準備をする前に間違いに気が付くことができるように、開発環境にレビュー結果をフィードバックするメカニズムを組み込むことに取り組むべきである。
彼は客観性と明確なレビュー観点をレビュープロセスにもたらすための助けとなるいくつかのツールを紹介している。
- デザイン品質向上のためのJDepend(サイト・英語)
- コードをクリーンに保つためのPMD(サイト・英語)
- コード品質向上のためのJavaNCSS(サイト・英語)
- テスト網羅性確認のためのEmma(サイト・英語)
Kirk氏はさらに20%レビューという名の興味深いレビュー実践方法について言及している。
20% レビューは、開発の20%が完了した時点で一度レビューを行うべきである、という非常にシンプルな考え方に基づくレビュー手法である。いくつかのチームはイテレーションごとに20%レビューを実施することでその有効性に気が付くかも知れない。それは確かに効果的であるが、チームが継続的なレビューのためのメトリクスを使用して良い仕事をしていた場合、システムの主要機能ごとに20%レビューを行うことで十分であると私は思う。
20%レビューは初期のデザインやコードをクリーンにすることに集中すべきだ。コードの量が比較的管理できる間は、メトリクスはコードの進化と成長を促進させる。
レビューを行う助けとなるメトリクスを用いることはレビュープロセスに客観性と明確なレビュー観点をもたらすということを、彼は強調している。優れており、自動化されていて、且つ簡易なメトリクスを用いることは有効なレビューをすることにつながる。レビューはまた、開発者がレビューで得た知識を早期に活用できるように、そしてレビューの有効性を低くしないためにも、十分早期に行うべきである。
原文はこちらです：http://www.infoq.com/news/2008/03/code-review-antipatterns