代码检查可能是痛苦的。软件工程师经常抱怨评审过程缓慢，延迟下游任务，并导致在打开请求(PR)和下一个任务之间来回导航时上下文切换。代码审查也可能充满了吹毛求疵和自行车欺骗，使其成为每个参与者的糟糕经历。
为了解决这个问题，一些工程师甚至建议我们完全去掉拉请求和代码审查。虽然这可能适用于初创企业的小型团队，但我不认为这对每个人都是正确的解决方案，尤其是企业级别的公司。
相反，我们有很多方法可以使代码审查过程对于代码作者和代码审查者来说都是一种更好的体验。让我们一起考虑其中的七个最佳实践。
1.尽量少要求
每个工程师都害怕审查修改了1000多行代码的请求。这些评审可能需要几个小时才能完成，通常最终发生的情况是，评审人员开始浏览代码，而不是仔细地评审代码。
解决方案是保持您的拉请求很小。小型公关更容易、更快地进行评审，因为评审人员不需要花费那么多时间建立一个关于所有变更如何协同工作的心理模型。代码更改也更少，这可能意味着更少的错误、更少的注释以及作者和审阅者之间更少的来回。
保持你的公关规模小起初可能看起来很困难，但是如果你把你的工作分解成小任务并保持专注，这是可以做到的。在实现新特性或修复 bug 的同时，不要进行重大重构。在代码中使用特性标志，这样就可以将新特性的一小部分合并到主分支中，而不会在生产应用程序中显示出来。
保持你的PRs小。你的审查员会感激你的。
2.使用拉请求模板
另一个麻烦是要求在没有任何上下文的情况下检查拉请求。当一个公关人员无缘无故地出现在你面前时，你经常会想: “这个公关是干什么的？这是在解决什么问题？是否有与此相关的任务？为什么要采取这种特殊的方法?”
Pull 请求模板是一个小型的、可配置的表单，您可以将其设置为每个新 pull 请求上的默认文本。PR 模板提示代码作者为其 PR 提供相关细节。通常情况下，公关模板会要求简要描述您所做的工作以及为什么要这样做，任务票据的链接，以及验证更改的测试计划。
好的公关模板通常还包括一个简短的清单，供代码作者检查，以确保他们没有遗漏任何基本内容。此检查表可能包括单元测试、文档、国际化、跨浏览器支持和可访问性等项目。
下面是一个例子拉请求模板，我喜欢使用的所有我的回购协议:
拉请求模板示例
3.实现响应时间 SLA
如果您发现拉请求未被审查的时间比您希望的要长，那么现在是一个好时机，作为一个团队来设置对新的拉请求应该被审查的速度的预期。换句话说，一个公关在被提取之前最多可以存在多长时间: 一个小时？两个小时？24小时？你对这个问题的回答很可能取决于你团队的规模。对于来自团队的内部拉动请求和来自其他团队的外部拉动请求，您可能有不同的答案。
在选择响应时间 SLA (服务水平协议)时，您需要找到正确的平衡。当你发布一个新的公关时，期望每个人都立即放下手头的工作并审查你的代码是不合理的，但是你也不希望公关连续几个小时都没有被审查。找到正确的平衡，让你的队友进入流动状态。他们应该能够处理自己的代码，然后在一天中的自然停止点检查 PR。
就个人而言，我喜欢对内部团队公关有两小时的响应时间，对外部团队公关有24小时的响应时间。
不管你和你的队友做出什么决定，拥有一个团队协议可以让你们彼此负责。如果每个人都同意一个特定的 SLA，并且时间已经过去了，你的公关之一，你知道这是可以开始窃听人们关于它。
4.培训初级和中级工程师
培训机会无处不在。指导经验不足的工程师不仅仅是教他们正在使用的技术和语言。它还包括教他们软技能，比如如何进行有效的代码审查。
在代码检查过程中，教会您的队友您所寻找的东西。帮助他们明白什么是重要的，什么是不重要的。教他们如何在代码评审注释中有效地交流，比如在非阻塞建议前面加上“ nit”
有大量关于如何成为一个更有效的代码审查员的资源。谷歌的代码审查开发人员指南值得一读。该指南对代码作者和代码审查者都有很好的建议。对于一个更厚颜无耻的资源，如何让你的代码审查员爱上你很容易是一些最好的(和有趣的)建议，为开发人员创建拉请求。
5.建立连续集成管道
当大多数注释是“丢失分号”或“这里似乎没有缩进”时，代码检查就变得乏味不要在代码检查期间花费时间在代码格式化程序和代码行程序可以为您处理的事情上。让计算机自动处理琐碎的事情，这样你就可以专注于需要人力的重要事情。
对于 JavaScript 项目，为回购配置一个像 Prettier 这样的格式化程序和一个像 ESLint 这样的行程很简单。然后，您可以使用诸如 Travis CI、 CircleCI、 GitHub Actions 或 GitLab CI/CD 之类的工具为回购建立持续集成。
CI 管道将为您运行这些格式化和连接任务以及单元测试。如果 CI 管道在请求的任何一个步骤中失败，它将阻止合并该请求。
现在您已经自动完成了代码审查的几个重要部分，从而节省了您的时间。
6.使用拉请求审查应用程序
有时候，不仅需要检查请求中的代码，还需要手动查看应用程序中的更改，以验证情况是否良好。对于具有复杂设置步骤的应用程序，下拉其他人的代码并在您的计算机上本地运行它可能需要5分钟到1小时。头好痛！
每当创建一个新的 PR 时，拉请求审查应用程序都会自动将代码部署到一个短暂的测试环境中。这使得评审员可以轻松地检查 UI 更改，而不必下拉代码并在他们的机器上本地运行。这不仅节省了时间，而且还促使评审人员在评审时更加全面，使其更加容易。
7.生成可视化代码更改的图表
在 GitHub 或 GitLab 中查看代码时，文件通常以字母顺序显示。对于相对较小的公共关系，这可能不是一个问题。但是当一个公关涉及到几十个文件时，有时候看到这些变化有逻辑地组合在一起是很有帮助的，这样你就可以看到它们是如何在一个更大的图片中组合在一起的。
CodeSee 查看地图帮助您可视化哪些文件被更改，以及这些更改如何影响它们的上游或下游依赖关系。它们与 GitHub 集成，可以自动在您的 PR 上发布评论和图表。您甚至可以创建代码的交互式导览，以帮助指导代码审查人员。最棒的是，CodeSee Maps 对开源组织及其公共存储库是免费的。
CodeSee 映射
