大幅减少代码审查时间的 7 种方法

1：保持拉取请求较小

1：保持拉取请求较小

代码审查可能会很痛苦。软件工程师经常抱怨审查过程缓慢，耽误了后续任务，并且需要不断切换上下文，在未完成的拉取请求 (PR) 和下一个任务之间来回切换。代码审查还可能充斥着吹毛求疵和敷衍塞责，给所有参与者带来糟糕的体验。

为了解决这个问题，一些工程师甚至建议我们彻底取消拉取请求和代码审查。虽然这可能对初创公司的小团队有用，但我认为这并不适合所有人，尤其是企业级公司。

相反，我们有很多方法可以让代码作者和代码审阅者都获得更好的代码审阅体验。让我们一起探讨其中的七个最佳实践。

#1：保持拉取请求较小

每个工程师都害怕审查代码修改超过 1000 行的拉取请求。这些审查可能需要几个小时才能完成，而且通常情况下，审查者只是粗略地浏览代码，而不是仔细审查。

解决方案是保持你的 PR 规模较小。小型 PR 更容易、更快速地审核，因为审核者无需花费太多时间构建所有变更如何协同工作的思维模型。代码修改也更少，这意味着更少的错误、更少的评论，以及作者和审核者之间更少的反复沟通。

保持 PR 规模较小乍一看可能很难，但只要你将工作分解成小任务并保持专注，就能做到。不要在实现新功能或修复错误的同时进行大规模重构。在代码中使用功能开关，这样你就可以把新功能的一小部分合并到主分支中，而不会在生产环境中显示出来。

保持你的 PR 简短。你的审阅者会感激你的。

#2：使用拉取请求模板

另一个恼人的事情是被要求在没有任何上下文的情况下审查拉取请求。当一个PR毫无解释地丢到你面前时，你常常会疑惑：“这个PR是干什么用的？它解决了什么问题？有相关的任务吗？为什么要采用这种方式？”

拉取请求模板是一个小型的可配置表单，您可以将其设置为每个新拉取请求的默认文本。拉取请求模板会提示代码作者提供其拉取请求的相关详细信息。通常，拉取请求模板会要求您提供已完成操作及其原因的简要描述、任务单链接以及用于验证更改的测试计划。

好的 PR 模板通常还会包含一个简短的清单，供代码作者检查，以确保他们没有遗漏任何基本内容。这份清单可能包含单元测试、文档、国际化、跨浏览器支持和可访问性等内容。

下面是一个示例拉取请求模板，我喜欢将其用于我的所有存储库：

＃3：实施响应时间SLA

如果您发现拉取请求未审核的时间比预期的要长，那么现在是时候作为团队设定新的拉取请求审核速度的预期了。换句话说，一个拉取请求在必须被采纳之前最多可以存在多久？一小时？两小时？还是24小时？您对这个问题的答案可能取决于您的团队规模。对于您团队的内部拉取请求和其他团队的外部拉取请求，您的答案可能也不同。

在选择响应时间 SLA（服务级别协议）时，您需要找到合适的平衡点。期望每个人在您发布新的 PR 时立即放下手头的工作来审查您的代码是不合理的，但您也不希望 PR 连续数小时都得不到审查。找到合适的平衡点，让您的团队成员能够进入心流状态。他们应该能够在一天中的自然休息时间点处理自己的代码并审查 PR。

就我个人而言，我喜欢对内部团队 PR 设定两小时响应时间 SLA，对外部团队 PR 设定 24 小时响应时间 SLA。

无论你和你的团队成员做出什么决定，团队协议都能让你们彼此负责。如果每个人都同意了特定的 SLA，并且你的某个 PR 的期限已经过去，你就知道可以开始就此事向大家发出请求了。

4. 培训初级和中级工程师

培训机会无处不在。指导经验不足的工程师不仅包括教授他们所使用的技术和语言，还包括教授他们一些软技能，例如如何进行有效的代码审查。

教会你的队友在代码审查过程中需要注意哪些方面。帮助他们理解哪些重要，哪些不重要。教会他们如何在代码审查注释中有效地沟通，比如在非阻塞建议前加上“nit”。

关于如何成为更高效的代码审查员，有很多很棒的资源。谷歌的《代码审查开发者指南》值得一读。该指南为代码作者和代码审查员提供了非常棒的建议。至于更有趣的资源，《如何让你的代码审查员爱上你》无疑是开发者创建拉取请求时最棒（且有趣）的建议之一。

＃5：设置持续集成管道

如果大多数注释都是“缺少分号”或“此处缩进似乎不对”之类的，代码审查就会变得乏味。不要在代码审查期间花时间处理那些代码格式化程序和代码检查工具可以帮你处理的事情。让计算机自动处理这些琐碎的事情，这样你就可以专注于需要人工处理的重要事情。

对于 JavaScript 项目，为你的仓库配置像Prettier这样的格式化程序和像ESLint这样的代码检查器非常简单。然后，你可以使用Travis CI、CircleCI、GitHub Actions或GitLab CI/CD等工具为你的仓库设置持续集成。

您的 CI 流水线将为您运行这些格式化和 linting 任务以及单元测试。如果 CI 流水线在拉取请求的任何步骤中失败，它将阻止该拉取请求合并。

现在您已经自动化了代码审查的几个重要部分，从而节省了您的时间。

#6：使用 Pull Request 审查应用程序

有时，不仅需要审查拉取请求中的代码，还需要手动查看应用程序中的更改，以验证一切正常。对于设置步骤复杂的应用程序，拉取其他人的代码并在本地计算机上运行可能需要五分钟到一个小时。真是令人头疼！

拉取请求 (PR) 审核应用用于在新的 PR 生成时自动将代码部署到短期测试环境中。这使得审核人员可以轻松检查 UI 更改，而无需拉取代码并在本地计算机上运行。这不仅节省了时间，还能通过简化流程来促使审核人员更加全面地进行审核。

#7：生成图表来可视化代码更改

在 GitHub 或 GitLab 中审查代码时，文件通常按字母顺序显示。对于相对较小的 PR，这可能不是问题。但是，当一个 PR 涉及数十个文件时，有时将这些更改按逻辑分组会很有帮助，这样您就可以从整体上了解它们是如何组合在一起的。

CodeSee 评审图 (CodeSee Review Maps)可帮助您直观地了解哪些文件发生了更改，以及这些更改如何影响其上游和下游依赖项。它与 GitHub 集成，可自动在您的 PR 上发布评论和图表。您甚至可以创建交互式代码导览，以帮助指导代码评审人员。最重要的是，CodeSee 评审图对开源组织及其公共代码库免费开放。

结论：加速代码审查的最佳实践

总结一下，以下 7 个技巧可以大大减少代码审查的时间：

1. 保持拉取请求较小。
2. 使用拉取请求模板来提供审阅者所需的所有上下文。
3. 实施响应时间 SLA。
4. 对初级和中级工程师进行代码审查期间需要注意的关键事项的培训。
5. 设置 CI 管道来运行 linters、格式化程序和单元测试。
6. 使用拉取请求审查应用程序，以便您可以轻松检查 UI 更改。
7. 使用 CodeSee Review Maps 等工具生成图表来可视化您的代码更改。

感谢您的阅读，祝您编码愉快！