第一回目の記事では、コードレビューがどのようにアジャイル開発プラクティスに関係しているかを説明しました。特に分散したチームを持っていたり、人員を変更したり、チームにまたがる調整が必要な場合においてです。
あなたのチームや組織内にコードレビューを導入してみようという気になりましたか？どうぞ読み進めて下さい。
誤解されていること
まず最初に、チームのためにコードレビューは何ができて、何ができないのかを明確に理解する必要があります。
コードレビューとは下記のことではありません：
- バグハント：参加した人数に関わらず、コードに存在する全てのバグを見つけることを、コードレビューは保証するわけではありません。良いソフトウェアにするために、自動化テスト、マニュアルテスト、静的解析等の他のツールを使用することを考慮してください。
- 責任のなすり合い：コードよりもむしろ人々に存在する欠陥を見つけることに集中してしまうとき、コードレビューはすぐに嫌われ、チームを助けるのではなく破壊するものになってしまうでしょう。その代わりに、学んだり教えたり、チームの集団としてのパフォーマンスを改善する機会として、コードレビューをとらえましょう。
コードレビューを始めよう
どのようにして、組織内のコードレビューを採用する意思決定者を説得するのでしょうか？それは場合により異なります。もし彼らが、コラボレーションにおける改善、イノベーション、そしてコードと従業員の両方における継続的な改善を奨励するような人々であれば、コードレビューの導入は簡単でしょう（驚くべきことに、ユニットテスト、リファクタリング、あるいはペアプログラミングといった人気のあるアジャイルプラクティスを導入するときとさほど変わりません）。もし意思決定者が、前向きな考え方ではない場合、チーム内部から始めてみるのがよいかもしれません – ボトムアップアプローチ。一つのチームが、生産性、士気、品質を向上させるようなプラクティスを導入したときには、遅かれ早かれ ときに、1つのチーム）は、遅かれ早かれ、他の人々も従うでしょう（チームの改善を自分の手柄にするかもしれない上司も含めて ;)）。
機会を広げよう
OK、あなたは始めました。どのように導入の失敗を避けられるでしょうか？ここでいくつか現実世界における経験をお話しします。
軽量に保つこと：多すぎるプロセスと多すぎるルールによりコードレビューを始めると、それはほとんど失敗を保証されたようなものです。チームからの反発に合うでしょう。レビューのプロセスはおそろしくシンプルにしてください。特別なルール、事前の承認、指定された意思決定者、正式な報告などはすべて無しにしましょう。
- 強制しないこと：チームのメンバーによりコードレビューの価値が認識されるのには時間がかかります。彼らは以前に、コードレビューについて嫌な経験があるかもしれませんので、いくらかの抵抗には驚かないようにしましょう。気のすすまないデベロッパーたちには、もっと軽量で、もっと時間のかからないアプローチで、もう一度コードレビューを行うよう奨励してください。
- 細かく管理しないこと：全てのチェンジセットをレビューするよう、あるいはコードレビューの間の厳格なプロセスに従うよう、チームに強制しないでください。注意：アジャイルコードレビューとは、ほぼ知識の共有です！他の全てのことは、良い副次的効果です。
- 非同期のレビューを奨励すること：コードレビュー会議は、デベロッパーを仕事から離れさせ、流れを断ち切るので、抵抗に合うでしょう。より良いアプローチは、都合のいい時間にコードをレビューさせるようにすることです。Eメール、RSSフィードなどを読むときと同じように。
- コードレビューを通して、興味深い発見、構成、設計上の決定を積極的に共有すること – チャンピオンになりましょう：コードレビューから簡単にアクセス出来る場所にナレッジベースを構築しましょう。
- コードレビューを、プロジェクトのワークフローにおける一つの状態として取り扱うこと：イテレーションの最後まで、コードレビューを待たないでください。遅くに実施するコードレビューは、コードレビューを全く行わないよりもしばしば悪い結果となります – 発見したことへの対応をするのに時間がないことが多いからです。代わりに、コードレビューを ‘To Do’ と ‘Done’ の間のもう一つのステップとして取り扱い、イテレーションにおいて継続的に実施できるようにしましょう。
- 大量にだけれど時々、よりも、少量にでも頻繁に行うこと：レビュー中のコードが比較的小さく、変更がよく定義されておりその理由も明確に見える（チェンジセットの差異にハイライトが追加されているととても助かる）とき、コードレビューに集中することはとても簡単になることを私たちは発見しています。継続的コードレビュー（私がそう呼んでいる用語）は、継続的インテグレーションの全てのメリットを同様に持っています – コードを前の状態に戻すのが遅すぎたり、誤解、予期しないリファクタリング、大きくて時間がかかりすぎるため長い間レビューしないこと、を避けることができます。そして何よりも、イテレーションの最後において “もっと重要なタスクがある” という名目でコードレビューを省略することを避けられます。
- コードと会話に集中すること、コードレビューツールとその無限の能力にではなく：コードレビューを容易にするために使あなたがどのようなツールを使用するとしても、それはより良いコミュニケーションと理解という目的に達するための手段です（まさにEメール、IM、その他のコミュニケーションツ
ールと同様に。
- レビューワーを増やしすぎないこと：多くの人々が関わるほど、レビューの時間はかかり、コストも大きくなります。実際には、コードレビューを効果的に実施するのには 2 – 4 人で十分であることが分かりました。参加者の数を増やすと、収穫が減少する結果に終わるのです。開発日における時間数が限定されていとすると、全てのレビューに全員が関わるよりも、各レビューに少ない人数が関わり多くのレビューを行う方が効果的だと分かりました。
コードレビューの価値と導入の測定 …
… はそれほど簡単ではありません。信頼性の高い、有意義な評価指標の収集を当てにすることはできません。コードレビューはソフトのプロセスで、人間が関わります – 非常に洗練され、予測不可能な作用因子です。コードレビューに関わるほとんどの評価指標は、素早く簡単に導くことができません。
測定できない便益は何でしょうか？少ないバグ、将来のやり直し作業と技術的負債の減少、チームの士気と協力の改善、トラックファクターの改善、そしてシステム間のよりスムーズなインテグレーションです。
コードレビューにおけるアクティビティの量（コメント数、作成されたレビュー数、発見された課題数、そのコードのレビューに費やされた時間、など）を単に測定するだけでは、有意義な評価指標を導きだすことは期待できません。しかし、これらの単純な評価指標は、コードレビューの導入度（とコスト）を測定するのには役立つかもしれません。もし評価指標が必要であれば – 使って下さい。しかし、忘れないで下さい：私は警告しましたよ！
あなたはいくつかの教訓を学び、またあなたからの助言を皆で共有できると、私は確信しています。どうぞコメントを残して下さい！
三回目で最後になる記事では、コードレビューとペアプログラミングを比較し、アトラシアンにおいて考案されたコードレビューに関わるいくつかのベストプラクティスを披露するつもりです。
“Fist” picture courtesy of tms. / CC BY-NC-ND 2.0
“Measuring Tape” picture courtesy of aussiegall / CC BY 2.0
*本ブログは ATLASSIAN blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2010 年 3 月 8 日投稿、”Code Review in Agile Teams – part II“