数百万年前，猿类从树上进化而来，进化出可对生的拇指，最终成为人类。让我们从类似的角度来看一下强制代码审查：在广阔的软件开发领域中，这似乎将人与野兽区分开来。然而，我有时会听到我们团队成员的评论如下：“这个项目的代码审查是浪费时间。”“我没有时间进行代码审查。”“我的项目发布延迟了，都是因为我那个懦弱的同事没有做任何review。”“你能相信我的同事要我改变代码中的某些东西吗？请向他们解释：如果我原来优雅的代码以任何方式改变，那意味着宇宙微妙的平衡将被打破。”我们为什么要做代码审查？首先，让我们记住为什么要进行代码审查。任何专业软件开发人员最重要的目标之一就是能够不断提高他们的工作质量。即使您的团队中满是优秀的程序员，您也不能将自己与有能力的自由职业者分开，除非您能够团队合作。代码审查是最重要的方法之一。特别是，他们：给你第二只眼睛来发现缺陷和更好的做事方法。确保至少有一个人熟悉您的代码。通过向新员工展示来自更有经验的开发人员的代码来帮助培训新员工。通过允许审阅者和被审阅者相互展示好的想法和实践来促进知识共享。鼓励开发人员在他们的工作中投入更多的精力，因为他们知道他们的代码将来会被他们的一位同事审查。进行彻底和深入的审查但是，如果不在审查过程中投入一些时间和精力，就无法实现这些目标。只是滚动浏览补丁，确保缩进正确并且所有变量都采用驼峰式，并不构成彻底的审查。受行业启发，还可以考虑结对编程，这是一种相当流行的做法，但也会在所有开发时间上增加100%的开销来基准代码审查工作。您可能会在代码审查上花费大量时间，但总体工程时间仍远少于结对编程。我认为花在codereview工作上的时间应该是原来开发时间的25%左右。例如，如果开发人员花了两天时间实施一个小项目，那么审核人员应该花大约四个小时来审核它。当然，复习工作花多少时间并不是最重要的，只要能准确完成复习即可。特别是，您必须能够理解您正在审查的代码。这不仅意味着您只需要了解编写代码所用语言的语法，还意味着您必须了解代码如何适应更大的应用程序、组件或库的上下文。如果您没有抓住每一行代码的全部含义，您的评论就没有多大价值。这就是为什么不能很快完成良好审查的原因：时间花在调查触发给定功能的不同代码路径，确保正确使用第三方API（包括任何边缘情况）等。除了在您审查的代码中寻找缺陷或其他问题外，您还应该确保：包括所有必要的测试。已经编写了适当的设计文档。即使是擅长编写测试和文档的开发人员也不总是记得在代码发生变化后进行更新。代码审阅者在适当的时间进行小的调整对于确保代码不会随着时间的推移而恶化至关重要。防止代码审查过载如果您的团队要求代码审查，这是有风险的，因为您的代码审查积压最终可能变得难以管理。如果你在两周内没有做任何复习工作，你可以很容易地花几天时间赶上它。但这也意味着，当你最终决定对付它们时，你自己的开发工作会因为一些意外而搁浅。这也使得做好审查工作变得更加困难，因为适当的代码审查需要紧张、持续的脑力劳动，这很难维持几天。因此，开发人员应该竭尽全力每天清理积压的审核工作。一种方法是在早上第一件事就是处理审查。通过在开始您自己的开发工作之前完成所有良好的审查工作，您可以防止审查情况在以后失控。有些人喜欢在午休前后或一天结束时进行复习。无论您何时做这些事情，通过让代码审查成为例行公事而不是分散注意力，您可以避免：没有时间处理审查积压工作。由于您的审查尚未完成而延迟项目的发布。进行一些不再相关的评论，因为代码在此期间发生了很大变化。评论最终做得很差，因为它们是在最后一刻才处理的。编写审查友好的代码无法管理的审查积压也不能全部归咎于审查人员。如果我的同事们花了一周的时间为一个大型工程项目添加代码，他们发布的补丁将真的很难审查，因为在一个阶段有太多的工作要做，代码的目的和系统的底层架构将也难以理解。这是为什么将您的工作划分为可管理的单元非常重要的众多原因之一，我们使用scrum管理方法，因此对我们来说正确的单元是重点。通过一起工作，按单元组织我们的工作，并提交仅与我们正在处理的单元相关的评论，我们可以编写更易于审查的代码。您的团队可能会使用另一种管理方法，但原理是相同的。为了编写易于审查的代码，还有一些其他先决条件。如果要做出一些艰难的架构决策，提前讨论它们以满足审阅者的要求是合理的。这将使审阅者更容易理解您的代码，因为他们会知道您试图在代码中实现什么以及您计划如何实现它。它还有助于避免在审阅者建议不同且更好的方法后您必须重写大量代码的情况。项目架构应该在你的设计文档中详细描述。无论如何，这都很重要，因为它可以让新项目成员快速跟上进度并理解现有的代码库。它还可以帮助审稿人更好地完成工作，这是另一个好处。单元测试还有助于向审阅者解释应该如何使用组件。如果您的补丁包含第三方代码，请单独提交。例如，当代码中间插入了9000行jQuery代码时，要做好codereview工作就更难了。编写可审查代码的最重要步骤之一是向代码审查部分添加注释。这意味着您可以自己浏览审查部分，并在您认为有助于审查者理解代码含义的任何地方添加注释。我发现这样的评论只需要相对较少的时间（通常只需几分钟）就能产生巨大的不同，使代码审查更快更好。当然，代码注释有许多相同的优点，应在适当的地方使用，但通常更明智的做法是审查注释。最后，作为奖励，研究表明，当开发人员重新阅读和评论代码时，他们会在自己的代码中发现许多缺陷。大量代码重构有时需要重构影响许多组件的代码库。对于大型应用程序，此过程可能需要数天（或更长时间）并会产生大型补丁。在这些情况下，标准的代码审查工作可能不切实际。最好的解决方案是逐步重构代码。在实现您的目标的工作代码库的范围内找到一个变化点。一旦改动，审核通过，再进行下一次改动，直到完成整个重构工作。这种方法可能不会每次都奏效，但经过深思熟虑和规划，在重构时避免大补丁通常是可行的。像这样重构代码可能会花费更多的开发人员时间，但它也会产生更好的代码质量和更容易的审查。如果真的不可能逐步重构代码（这可能说明源代码编写和组织得有多好），一种可能的解决方案是在进行重构工作时使用结对编程而不是代码审查。解决纠纷您的团队无疑是一群聪明的专业人士。当人们在某个编码问题上存在分歧时，基本上就会出现争议。作为开发人员，如果您的审阅者更喜欢不同的方法，请保持开放的心态并准备妥协。不要对你的代码抱有专有的态度，也不要带上个人评论。仅仅因为有人认为您应该将一些重复的代码重构为可重用的函数，并不意味着您没有吸引力、才华横溢和魅力。作为审查员，要有技巧。在改变你的建议之前，认真考虑你的报价是真的更好还是只是你个人风格的问题。如果您选择一个专注于明显需要改进的源代码区域的战场，您将获得更大的成功。说“这可能值得考虑”或“有人建议......”之类的话比“即使我的宠物仓鼠也能写出比这更有效的排序算法”更合适。如果无法达成中间立场（即双方都不愿意妥协），那就请双方都尊重的第三方开发者过来，请他们提意见和建议。
