www.ydisp.cn/oss/202207/13/44cb1d02001e44998f5231531e89665b78c13c.jpg"style="width:600px;能见度：可见；height:400px;"data-type="block">为了解决这个问题，一些工程师甚至建议我们完全取消拉取请求和代码审查。虽然这可能适用于初创公司的小团队，但我认为这不是适合每个人的解决方案，尤其是企业级公司。相反，我们有很多方法可以使代码审查过程成为代码作者和代码审查者的更好体验。让我们考虑其中的七个最佳实践。1.要求尽可能少工程师害怕审查修改1000多行代码的请求。这些审查可能需要几个小时才能完成，通常最终发生的是审查者开始浏览代码而不是仔细审查它。解决方案是保持你的Pull请求很小.小型PR审查起来更容易和更快，因为审查者不需要花费太多时间来构建所有更改如何协同工作的心智模型。代码更改也更少，这意味着错误更少，更少评论，减少作者和审稿人之间的来回。保持小的PR起初看起来很难，但如果你将工作分解成小任务并保持专注，就可以做到。不要在实施新功能或修复错误时进行重大重构。在您的代码中使用功能标志，以便新功能的一小部分可以合并到主分支中，而无需将它们分解到生产应用程序中保持您的PR小。您的审稿人会很感激的。2.使用拉取请求模板另一个麻烦是要求在没有任何上下文的情况下审查拉取请求。当一个PR无缘无故出现在你面前的时候，你常常会想：“这个PR是干什么用的？这个解决什么问题？有没有与此相关的任务？为什么要采用这种特殊的方法？”拉取请求模板是一种可配置的小型表单，您可以将其设置为每个新拉取请求的默认文本。PR模板会提示代码作者为其PR提供相关详细信息。通常，PR模板会要求简要说明您做了什么以及为什么这样做、任务单的链接以及验证更改的测试计划。好的PR模板通常还包括一个简短的清单，供代码作者审查，以确保他们没有遗漏任何基本内容。该清单可能包括单元测试、文档、国际化、跨浏览器支持和可访问性等项目。这是我喜欢用于我所有回购协议的拉取请求模板示例：拉取请求模板示例3.实施响应时间SLA作为一个团队，这是一个很好的时间来设定对新拉取请求的审查速度的期望。换句话说，一个PR在被抓取之前最多能活多久：一个小时？两个小时？24小时？您对这个问题的回答可能取决于您团队的规模。对于来自您团队的内部拉取请求和来自其他团队的外部拉取请求，您可能有不同的答案。在选择响应时间SLA（服务水平协议）时，您需要找到合适的平衡点。当你发布一个新的PR时，期望每个人立即放下他们正在做的事情并审查你的代码是不合理的，但你也不希望PR持续数小时而不被审查。找到合适的平衡点，让你的队友融入其中。他们应该能够处理自己的代码，然后全天在自然停止点检查PR。就个人而言，我喜欢内部团队PR的两小时响应时间和外部团队PR的24小时响应时间。无论您和您的队友做出什么决定，达成团队协议都会让你们对彼此负责。如果每个人都同意某个特定的SLA，并且时间已经过去，那么您的一个PR，您知道可以开始窃听人们关于它的信息。4、培训初中级工程师培训机会无处不在。指导经验不足的工程师不仅仅是教他们使用的技术和语言。它还包括教他们软技能，比如如何进行有效的代码审查。在代码审查期间，告诉你的队友你在寻找什么。帮助他们了解什么是重要的，什么不是。教他们如何在代码审查评论中有效地沟通，比如在非阻塞建议前面加上“nit”关于如何成为更有效的代码审查者的资源有很多。Google的开发人员代码审查指南值得一读。该指南为代码作者和代码审阅者提供了很好的建议。对于更厚颜无耻的资源，HowtoMakeYourCodeReviewersLoveYouEasily是为开发人员创建拉取请求的一些最佳（和有趣）建议。5.在你处理的事情上建立一个持续集成管道。让计算机自动处理琐碎的事情，这样您就可以专注于需要人力的重要事情。对于JavaScript项目，为repo配置像Prettier这样的格式化程序和像ESLint这样的linting很简单。然后，您可以使用TravisCI、CircleCI、GitHubActions或GitLabCI/CD等工具为存储库设置持续集成。CI管道将为您运行这些格式化和连接任务，以及单元测试。如果CI管道在请求的任何一步失败，它将阻止该请求被合并。现在您已经自动化了代码审查的几个重要部分，从而节省了时间。6.使用拉取请求审查应用程序有时不仅需要检查拉取请求中的代码，还需要手动审查应用程序中的更改以验证一切正常。对于具有复杂设置步骤的应用程序，可能需要5分钟到一个小时的时间来提取其他人的代码并在您的计算机上本地运行它。头疼！每当创建新的PR时，拉取请求审查应用程序会自动将代码部署到临时测试环境。这使得审阅者可以轻松地审阅UI更改，而无需下载代码并在他们的机器上本地运行。这样不仅可以节省时间，还可以激励审稿人在审稿时更全面，更容易。7.生成图表以可视化代码更改在GitHub或GitLab中查看代码时，文件通常按字母顺序显示。对于相对较小的PR，这可能不是问题。但是，当PR涉及数十个文件时，有时将更改按逻辑组合在一起会很有帮助，这样您就可以看到它们如何在更大的画面中组合在一起。CodeSee视图映射帮助您可视化更改了哪些文件以及这些更改如何影响它们的上游或下游依赖项。它们与GitHub集成以自动在您的PR上发布评论和图表。您甚至可以创建交互式代码导览，以帮助指导代码审阅者。最重要的是，CodeSeeMaps对开源组织及其公共存储库是免费的。CodeSee映射
