代码审查可能很痛苦。软件工程师经常抱怨审查过程缓慢、下游任务延迟，以及在打开请求(PR)和下一个任务之间来回导航时导致上下文切换。代码审查也可能充满吹毛求疵和自行车作弊，这对所有相关人员来说都是一种糟糕的体验。为了解决这个问题，一些工程师甚至建议我们完全取消拉取请求和代码审查。虽然这可能适用于初创公司的小团队，但我认为这不是适合所有人的解决方案，尤其是企业级公司。相反，我们有很多方法可以使代码审查过程成为代码作者和代码审查者的更好体验。让我们考虑其中的七个最佳实践。1.尽量少问。每个工程师都害怕审查修改1000多行代码的请求。这些审查可能需要几个小时才能完成，通常最终发生的是审查人员开始浏览代码而不是仔细审查它。解决方案是让您的拉取请求保持较小。小的PR更容易和更快地审查，因为审查者不需要花费那么多时间来构建所有变化将如何协同工作的心智模型。代码更改也更少，这可能意味着错误更少、评论更少，作者和审阅者之间的来回更少。一开始保持PR较小似乎很困难，但如果将工作分解为小任务并保持专注，则可以做到。不要在实施新功能或修复错误时进行重大重构。在您的代码中使用功能标志，以便新功能的小子集可以合并到master分支中，而不会出现在生产应用程序中。保持你的PR小。你的考官会很感激的。2.使用拉取请求模板的另一个烦恼是要求在没有任何上下文的情况下审查拉取请求。当公关无缘无故出现在你面前时，你常常会想：“这个公关是干什么用的？它要解决什么问题？这有什么使命吗？为什么要采用这种特殊的方法？”拉取请求模板是一种可配置的小型表单，您可以将其设置为每个新拉取请求的默认文本。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映射
