我们经常听到团队成员说，“这个项目做代码审查是在浪费时间。”“我没有时间做代码审查。”“发布被推迟是因为我那意味着同事还没有审查我的代码。”“你信不信我的同事让我改代码？我那优雅又血腥的代码哪里需要改。”为什么我们需要代码审查？任何专业软件开发人员最重要的目标之一就是不断提高其工作质量。但只有通过团队协作，才能发挥一地之长，发挥一地之长，提高软件质量。代码审查是实现这一目标的最重要方法之一。特别是，代码审查可以：从另一个角度发现缺陷和更好的解决方案。确保至少有其他人熟悉您的代码。通过浏览高级开发人员的代码来帮助培训新员工。促进知识共享。激励开发人员编写更好的代码并解决代码中的问题，以免在审查时被其他人抓住。CodeReview需要彻底但是，除非你花时间和精力进行CodeReview，否则很难达到上述目标。我的看法是，大约25%的原始开发时间应该花在代码审查上。例如，如果一个开发人员需要两天时间来实施一个程序，那么它应该花大约四个小时来审查。当然，时间不是最重要的，关键是看你能不能正确review代码。您必须理解您正在审查的代码。这意味着您不仅必须了解其语法，还必须了解代码如何作为组件或库的一部分融入应用程序的上下文。如果你不能把握每一行代码的含义，那么你的复习不到位，也不会有太大的价值。这就是为什么执行良好的代码审查大多不可能快速完成的原因：因为我们需要时间研究各种代码，例如可以触发给定功能的代码，以确保正确使用第三方API。审查时，除了寻找代码缺陷和其他问题外，您还应该确保：包括所有必要的测试。已经编写了适当的设计文档。即使是擅长编写测试和文档的开发人员在更改代码时也会忘记更新。代码审查应确保这些材料不会随着时间的推移变得无用。避免过多的代码审查开发人员应努力清除积压的审查任务。一种方法是在早上进行代码审查，以便在开始自己的开发工作之前完成审查。当然，您也可以在午餐时间或一天结束时查看代码。总而言之，你应该把代码当作你日常工作的一部分，而不是一种负担，所以你应该避免：没有时间处理reviewbacklog。由于审查不完整而延迟发布。傻傻的把不相关的代码再review一遍，交给你之后已经改得面目全非了。由于时间关系，我匆匆看了一段过场动画。编写可审查的代码对于失控的代码积压，审查者并不是唯一的责任人。例如，如果您的同事花了一周的时间向一个大型程序中添加乱码，那么出现的补丁就很难审查，有太多东西需要理解和深入研究。甚至代码的目的和基本结构都在迷雾中。这与编写代码无关。在编写可审查代码之前，需要做一些准备工作。如果需要做出一些艰难的架构决策，请先与审阅者讨论。这将使你的代码更容易审查和理解，因为他们已经提前知道你想要实现什么以及你打算如何实现它。它还避免了如果审阅者后来提出完全不同且更好的方法，您必须重写一大段代码的情况。项目架构应在设计文档中详细描述。这很重要，因为它可以让新项目人员更快地理解现有代码库，还可以帮助审阅者更好地完成工作。此外，单元测试允许审阅者更好地理解各个组件的使用。如果您的补丁中还包含第三方代码，请单独提交。试想一下，如果在代码中间插入9000行jQuery，会不会大大增加复习难度！创建可审查代码的最重要步骤之一是注释您的代码审查。这个需要自己预审，然后在你认为有助于审稿人理解的地方加上注释。我发现评论后代码审查花费的时间相对较少（通常只需几分钟）。当然，代码注释仍应在适当的地方使用。此外，研究表明，开发人员在对代码进行注释时，自己也会发现很多缺陷。代码重构有时，我们必须重构代码库。如果碰巧是一个大型应用程序，可能需要数天（或更长时间）并生成大量补丁。在这种情况下，进行标准流程代码审查可能是不切实际的。最好的解决办法是逐步重构代码。先给出一个合理的范围，确定相应的代码库，然后朝着目标的方向进行整改和重构。第一部分完成后审核发布，然后再做第二部分的重构……直到全部完成。这种分阶段的方法可能并不总是可行，但如果我们在思考和计划中使用它，我们就可以在重构时避免大量的单体补丁。当然，这种方法可能需要更多的重构时间，但它也会产生更高质量的代码和更容易的审查过程。如果代码的增量重构仍然不可行，另一种解决方案是结对编程。争议的解决毫无疑问，团队中的每一位成员都是人才，但在面对特定的编码问题时，也很容易导致意见分歧。作为开发者，我们应该保持开放的心态，对审稿人的不同意见持开放态度。作为审稿人，您必须机智。在提出建议之前，请考虑您的意见是真的更好还是只是品味问题。如果你选择了一个真正需要改进的代码区域，整个说服过程就会容易很多。而话应该这样说，“这里值得考虑……”，“有人建议……”而不是“我闭着眼睛写的算法可以比你的更高效”。当然，如果双方都不愿意妥协的话，可以请大家尊敬的开发者看看，提出意见。
