我从来没有找到执行代码审查的理想方法，但是我的客户经常需要它们。每个客户似乎都以不同的方式来做他们，而我从未对其中的任何一个感到满意。
您执行代码审查的最有效方法是什么？
例如：
Answers:
在我的工作中，我们有一个非常简单的规则：在合并或提交到主干之前，至少必须由其他一名开发人员检查更改。在我们的情况下，这意味着其他人实际坐在您的计算机旁，并浏览更改列表。这不是一个完美的系统，但是它仍然显着提高了代码质量。
如果您知道要检查您的代码，这将迫使您首先查看它。那时许多问题变得显而易见。在我们的系统下，您必须向审阅者解释您做了什么，这又使您注意到以前可能遗漏的问题。另外，如果您的代码中的某些内容对于审阅者而言尚不明确，则表明您需要更好的名称，注释或重构。并且，当然，审阅者也可能会发现问题。此外，除了查看更改之外，审阅者还可能注意到附近代码中的问题。
该系统有两个主要缺点。当变化不大时，对其进行审查几乎没有意义。但是，我们绝对必须遵守规则，以避免在没有变化的情况下宣布更改为“琐碎”的草率步骤。另一方面，这不是检查系统的重大更改或添加新的大型组件的好方法。
之前，我们曾尝试过更正式的审查，当时一位开发人员将通过电子邮件将代码审查给团队的其他成员，然后整个团队将聚在一起讨论。这花费了每个人很多时间，结果这些审查很少而且相去甚远，只有一小部分代码库得到审查。“另一个人在提交之前检查更改”对我们来说要好得多。
我喜欢代码审查，尽管可能会很痛苦。我喜欢它们的原因是，他们对代码和其他观点有更多的关注。我相信，即使使用结对编程，也应检查代码。两个人在同一个代码上共同犯下相同的错误就很容易了，不同的眼睛可能不会错过。
如果与放映机作为一个小组一起完成，则应在会议之前逐个进行审查。否则，那只是时间的烦人。
我只通过电子邮件和小组方式进行过代码审查。一般来说，我不认为应该亲自进行。当有人抬头看着你时，您会感到有些压力要匆忙执行代码。我确实相信为代码检查而设计的工具将是一项很好的资产，因为它可以帮助解决一些平凡的方面，并且与通过电子邮件相比，它应该更容易标记代码的问题位。
一个人进行所有代码审查的问题在于这可能是一个瓶颈。有了充分记录和设计的编码标准，就没有必要了。根据环境/发布时间表的不同，最好总是让某人作为备用代码审阅者。
我确实认为代码所有权是个好主意，因为该人员可以将理解代码的优先级作为优先考虑，并可能扮演网守的角色。
在SmartBear，我们不仅制作代码审查工具，而且每天都在使用它。这是我们开发过程的重要组成部分。我们会检查所有已签入的更改。
我认为，由于多个原因，只有一个网守代码审查员是一个坏主意。这个人成为瓶颈，他们必须进行过多的代码审查（只是为了保持项目进展），才能真正发挥作用（每次限制60-90分钟是有效的）。代码审查是共享想法和知识的好方法。无论您的看门人有多少超级巨星，他们都可以向团队中的其他人学习。同样，让每个人都进行代码审查还会创建一个“集体代码所有权”环境-人们会觉得自己拥有代码的质量（不仅仅是质量保证或关守者）。
我们提供了有关“ 对等代码审查的最佳实践 ”的免费白皮书，其中包含11条使代码审查有效的技巧。其中大部分内容与约翰以提炼形式提及的书中的内容相同。
别找借口。练习配对编程。它可能是最好的代码审查。任何其他机制都会导致责备游戏。结对编程会激发团队合作精神和集体所有权。此外，您还需要与一对讨论想法，快速失败，采取纠正措施，只有对编码和审阅过的代码才会提交给配置管理系统（CMS）。幸福的一对编程！
在我目前工作的地方，我们生产硬件设备以及与其连接的软件，这些软件已进入关键基础架构。因此，我们非常重视发布质量。我们使用了Fagan Inspection的一种变体，并有一个正式的审查程序。我们已通过ISO 9001认证，还有其他认证。
关键基础设施行业对其可靠性和可重复性非常感兴趣。:-)
在我公司，我们有针对初级程序员的强制性代码审查，以及针对高级程序员的自愿性代码审查。没有指定的代码审阅者，审阅请求将发送给所有开发人员。
该系统运行良好-在时间允许的情况下进行审核，并且可以通过几组眼球来审核更改。
优秀且免费的评论委员会工具对我们来说非常有效，并且被证明是传达评论的绝佳方式。
在我公司中，除非签约人员正在修改一些非常关键的产品并且没有时间执行我们的标准质量检查流程，否则我们永远不会在签入之前进行正式的代码审查。
我们要做的是，每当我们觉得对代码审查有用时，就会在修改后的代码中添加“ // todo：joe进行代码审查”注释。通常，我们选择Joe是因为他拥有修改后的代码，但是如果此选择标准不适用（通常适用），我们只是随机选择其他人。当然，如果乔那时恰好有空，我们将使用旧的“肩上审阅”方法。
作为一名审阅者，您唯一需要做的就是定期在整个代码中搜索“ // todo：我的代码审阅”，查看所做的更改，然后在不带“ todo ...”注释的情况下签入代码。
如果有问题，我们将改回传统的通讯方式（邮件/聊天/等）。
此方法为我们提供了我们要在审查系统中寻求的两个主要素质：
是一个人被认为是质量的守门员并审查代码，还是团队拥有该标准？
您是否使用投影仪作为团队练习来检查代码？
是亲自完成，通过电子邮件还是使用工具完成的？
您是否避免使用代码编程和集体代码所有权等评论来确保代码质量？
与所有编码项一样，正确答案应考虑到：
我曾在许多公司工作过，看到过许多流程。我目前的团队正在处理迄今为止我所见过的最好的团队。
我们使用敏捷的开发过程，其中一部分是每个故事都必须经历的门。这些门之一就是代码审查。在完成代码审查之前，故事不会继续进行测试。
另外，我们将代码存储在github.com中。因此，在开发人员完成更改后，他们将链接发布到故事中的提交。
然后，我们标记其他开发人员进行审核。Github有一个注释系统，允许某人在有问题的代码行中注释。然后，Github将电子邮件发送到发行版，因此有时我们实际上会引起我们其他一些团队的关注。
这个过程对我们来说非常有效。我们确实使用了一个敏捷的过程工具，该工具使发布提交变得容易并且促进了沟通。
如果问题特别棘手，我们将坐下来讨论。之所以行之有效，是因为它是我们流程不可或缺的一部分，每个人都对流程的运作方式有所认同。如果代码审查导致需要的返工，我们可以将工单移回进行中，然后在进行更改后可以再次进行审查，或者审查者可能会在故事中指出，修复这些项目就足够了，不需要再次审查。
如果测试可以解决问题，它将一直持续到进行中，并且还会审查任何进一步的更改。