回答:
Googleには、これまで見たどの場所よりも優れたコードレビュープラクティスがあります。そこで出会ったすべての人は、コードレビューの方法について完全に合意しています。マントラは「早期かつ頻繁にレビューする」ことです。
グラハムリーが提案したようなプロセスを使用するとします。（これは私が以前自分で使用したプロセスです。）問題は、レビュー担当者が大きなコードの塊を調べるように求められていることです。それはより多くの努力であり、レビュアーにそれをさせるのは難しいです。そして、彼らがそれをするとき、彼らにそれを徹底的にさせることはより困難です。さらに、設計上の問題に気付くと、開発者が戻って作業コードをすべてやり直して改善することは難しくなります。あなたはまだ物をキャッチし、それはまだ価値がありますが、あなたはあなたが利益の90％以上を逃していることに気付かないでしょう。
対照的に、Googleはソース管理に入る前にすべてのコミットについてコードレビューを行います。単純に多くの人は、これは重いプロセスだと考えています。しかし、実際にはそのようには機能しません。コードの小さな断片を単独でレビューするのが非常に簡単になりました。問題が見つかった場合、そのデザインの周りにまだ大量のコードを記述していないため、デザインを変更する作業ははるかに少なくなります。その結果、徹底的なコードレビューがはるかに簡単になり、変更された問題を修正するのがはるかに簡単になります。
Googleのようにコードレビューを行いたい場合（本当にお勧めします）、そのためのソフトウェアがあります。Googleは、Subversionと統合されたツールをRietveldとしてリリースしました。Go（言語）は、Mercurialで使用するために修正されたRietveldのバージョンで開発されています。Gerritという名前のgitを使用する人々のための書き直しがあります。また、これに推奨される2つの商用ツールCrucibleとReview Boardを見てきました。
私が使用したのはGoogleの内部バージョンのRietveldだけで、非常に満足しています。
複数のチームで使用した手法は次のとおりです。
レビューを求めるのはコード作成者の責任であり、リリースされたブランチのメンテナーは、レビューされたコードのみがマージされるようにする責任があります。
コードレビューをサポートするツールはありますが、私はそれらを使用したことがありません。レポジトリ内で、マージのレビューを行った人を追跡できます。誰が何をレビューしたかを示すために、コミットにアタッチされたsvnプロパティとperforceジョブを使用しました。
レビュー用のコードをコミット/非コミット基準で分けたことはありません-遭遇した唯一の基準は、単体テストと統合テストが緑色であることです。
追跡に関しては、お気に入りの課題追跡システムでフローを更新することをお勧めします。代わりに例えば：
もう1つのステージを紹介することもできます（レビュー）。
したがって、Implemented状態のすべてのチケットにレビューアを割り当てることができ、レビュー済みのチケットのみがQAに進みます。
私はコードレビューの経験が1つしかないので、どれほど良いかは言えません。
私は小規模（〜10-15）のコーダーのグループと仕事をしていたので、VS Team Foundation Studioを使用していました。約1日1回コードをコミットするように求められ、その前に各コミットコードがグループの他の誰かによって（できればプロジェクトに関係する誰かによって）レビューされるようになりました。コミット時に、人の名前もフィールドに含まれていました。
私は、週に数回のレビューの間に、変更ごとにチェックインされたすべてをコードレビューするチームで働きました。これは、コードレビューが常に最新であるとは限らないことを意味しますが、目標を達成しました。
最初に、コードを確認して何を達成したいかを尋ねます。私たちの場合、それはばか開発者を捕まえることではなく、無能の仮定ではなく能力の仮定がありました。これにより、チームはシステムの他の領域の概要を把握することができ、いくつかの疑わしい設計決定が修正される前に修正することができました。疑わしいのは、猫の皮を剥ぐ方法は常に複数あるということです。いわば、ツールボックスに猫の皮をむくナイフがあることを誰もが知っているわけではありません。
コードレビューに取り組んだ方法は、プロジェクト追跡ソフトウェアのすべてのタスクがレビューされることでした。当時は、MantisとSVNを使用していました。プロジェクトのコミットは両方のシステムに結び付けられていました。すべてのコミットは、カマキリのタスクに結び付けられなければなりませんでした。タスクが完了すると、「レビューの準備完了」のステータスが割り当てられました。
次に、RFRアイテムは、レビューのために空き時間がある人がピックアップしたか、レビューのために特定の人に割り当てられました。金曜日には、すべてのRFRアイテムを翌日までにレビューする必要があったため、翌週まで持ち越されませんでした。
このプロセスで遭遇した唯一の問題は、大量のファイルを持つ大きなアイテムでした。これを処理するために、コーダーとレビュアーは集まり、レビュアーがそれらを理解するまでコーダーは変更を実行します。彼らは一緒にコードレビューを行います。
このプロセスは、管理者がピアプログラミングを行った場合、別のコードレビューは不要であると指示したときに故障しました。開発者はこのプロセスを怠り、小さな愚かなバグが導入され始めました。最終的に、元のプロセスに戻り、物事は一緒に戻りました。
私のチームでは、過去1年ほど練習を使用してきましたが、非常にうまく機能しているようです。
私たちの組織では、バージョン管理にPerforceを使用しています。Perforce（1年前）には、シェルビングと呼ばれる機能が含まれています。棚を使用すると、特定の問題に対する変更を「棚上げ」できます。それらはバージョン管理システムに保存されますが、チェックインされません。その後、チームの別の開発者にコードを確認するよう依頼します。
他の開発者は自分のコンピューターからPerforceの保留中の変更を表示し、変更を最新のリビジョンと比較できます。また、私の変更を試してみたい場合は、ローカルマシンに「シェルブ解除」できます。彼がレビューを完了したら、彼は私に知らせます。次に、コメントの最後に「Reviewed by Bob」とコードをチェックインします。
これは私たちにとって本当にうまくいきました。まず第一に、一般的なコードレビューは非常に役立つことが証明されています。さらに、Perforceのシェルフ機能を使用すると、チームが地理的に広範囲に広がっていても、チェックインや大きな困難を伴うことなくレビューを行うことができます。これは非常に重要です。そしてそれは素晴らしく機能します。