Answers:
Google在我所见过的任何地方都拥有最佳的代码审查实践。我遇到的每个人都完全同意如何进行代码审查。口头禅是“经常复习”。
假设您使用类似于Graham Lee建议的过程。（这是我以前自己使用的一个过程。）问题是，要求审阅者查看大量代码。这需要付出更多的努力，而且很难让审稿人去做。而且，当他们这样做时，很难让他们彻底地做到这一点。此外，当他们注意到设计问题时，很难让开发人员返回并重做所有工作代码以使其更好。您仍然可以捕获东西，它仍然很有价值，但是您不会注意到您错过了90％以上的收益。
相比之下，Google会对每个提交进行代码审查，然后才能进入源代码管理。天真的许多人认为这将是一个繁重的过程。但这在实践中并不可行。事实证明，单独查看小段代码要容易得多。发现问题后，更改设计的工作量将大大减少，因为您尚未针对该设计编写大量代码。结果是，进行彻底的代码审查变得容易得多，并且更容易解决已更改的问题。
如果您希望像Google一样进行代码审查（我真的非常建议），那么可以使用软件来帮助您。谷歌已经发布了与Subversion集成的工具Rietveld。Go（语言）是使用Rietveld版本开发的，该版本经过修改可与Mercurial一起使用。对于使用git的人，有一个重写，名为Gerrit。我还看到了为此推荐的两个商业工具，坩埚和评审委员会。
我唯一使用过的是Google内部版本的Rietveld，对此我感到非常满意。
我在多个团队中使用的一种技术是：
寻求评审是代码作者的责任，而发布分支维护者的责任是确保仅合并经过评审的代码。
有一些工具支持代码审查，但我从未使用过。可以在仓库内部跟踪对任何合并进行审核的人员。我使用了svn属性和提交所附加的perforce作业来显示谁查看了哪些内容。
我从未按提交/未提交的标准来分离代码以进行审查-我遇到的唯一标准是单元测试和集成测试是绿色的。
至于跟踪，我建议您在自己喜欢的问题跟踪器中更新流程。例如，而不是：
您可能想再介绍一个阶段（回顾）：
因此，在每票实现的状态，你可以指定一个评论家，仅来自门票将提前到QA。
我只有一种代码审查的经验，所以我不能说它有多好。
我当时与一小群（〜10-15）的编码人员一起工作，而我们使用的是VS Team Foundation Studio。我们被要求每天提交一次代码，然后再由小组中的其他人（希望也由参与该项目的人）审查每个提交代码。提交期间，该人的姓名也包括在字段中。
我们处理代码审查的方式是，审查项目跟踪软件中的每个任务。当时我们使用的是螳螂和SVN。我们的项目提交被绑定到两个系统中。每次提交都必须与螳螂相关联。任务完成后，状态分配为“准备审阅”。
然后，RFR项目要么被有空闲时间进行审核的任何人拿走，要么被分配给特定人员进行审核。在星期五，必须在一天结束之前检查所有RFR项目，以免结转到下周。
我们在此过程中遇到的唯一问题是有大量文件的大型物品。为了解决这个问题，编码人员和审阅者会聚在一起，编码人员将遍历所有更改，直到审阅者理解它们为止。他们将一起进行代码审查。
当管理人员指示如果完成对等编程时，不需要进行单独的代码审查，则此过程中断。开发人员对此过程变得松懈，并开始引入一些小愚蠢的错误。最终，我们回到了原始流程，一切又恢复了。
在我的团队中，过去一年左右，我们一直在使用一种练习，效果似乎很好。
我们的组织使用Perforce进行版本控制。Perforce（截至一年前）包括一项称为“搁架”的功能。通过搁置，我可以“搁置”针对特定问题的更改。它们存储在版本控制系统中，但未检入。然后，我请团队中的另一位开发人员检查代码。
另一个开发人员可以在自己的计算机上查看我在Perforce中待处理的更改，并将更改与最新修订进行比较。如果他想尝试我的更改，他也可以“搁置”到本地计算机上。他完成审查后，会通知我。然后，在评论的末尾用“鲍勃评论”检入我的代码。
这对我们来说真的很好。首先，事实证明，代码审查通常是非常有用的。此外，Perforce的货架功能使我们能够进行检查，而无需检入或遇到任何重大困难，即使我们的团队在地理上分布广泛-这也非常重要。而且效果很好。