提升团队绩效，找到瓶颈是第一步。实际上，最大的限制因素不是编码速度，而是代码审查。因此，为了加快审查过程，我比较了两种拉取请求：一种是评论很少且快速合并的拉取请求，另一种是评论很多，需要多轮审查的拉取请求。我的结论是有九种方法可以使审查拉取请求更容易。1.添加关于“why”的代码注释写一个新函数的时候，会有很多相关的信息。编写代码时，请考虑第三方系统的要求、限制以及与遗留代码库的交互。但是其他人不了解它的上下文来源，所以当他们看到这段代码时，他们会问“为什么会在这里？”或“你为什么选择这种方法？”因此，通过添加解释性注释，让阅读代码的人提前知道“Why”。笔者不同意某些人宣扬的观点：评论是有害的，应该忽略。有许多类型的注释。那些描述代码目的的确实很繁琐。使用精心选择的名称提取方法可以消除这种麻烦。另一方面，在解释代码为什么这样写的时候，也增加了代码读者的信息量。这些注释理想地将读者的认知水平提高到与编码人员相同的水平，这有助于提高代码理解力。作者的评论通常会给出类存在的原因、相关资源的链接以及代码的前因后果：#FirstCrewDragonlaunchwaspostponedduetobadweather，#andnowweneedaneventforthe"second"firstlaunch。#Hencethestupidname.classSecondFirstCrewDragonLaunch...End2。清楚的描述拉取请求的描述是为审阅者提供的提供任务的初始上下文，包括：标签链接。已完成事件的摘要（如果从pullrequest的标题中看不出来的话）。相关拉取请求的链接（例如，另一项服务中的相关更改）。不要把你认为理解代码所需的信息放在pullrequest的描述中，而是代码注释：它们更有效，对未来的代码阅读者更有帮助。3.简化pullrequests是一项非常强大的技术，Google甚至专门写了一篇关于小型pullrequest的好处的文章(https://google.github.io/eng-practices/review/developer/small-cls.html)。以下是我最喜欢的小型拉取请求的功能：审查更彻底审查更快、更容易合并（频繁合并减少冲突）如果被拒绝，浪费的精力更少重构为单独的拉取请求分解大的功能（即使它们不是用户-facing)学习一些gittricks有帮助，gitadd--patch和gitrebase--interactiveasfriends分支出长期运行的特性设置为pullrequest的目标，而不是master的目标：4.快速响应审查处理审查评论通常很耗时，需要修正拼写错误、添加缺失的测试用例、重命名方法等。如果您快速完成，您的同行将花费更少的时间来记住与拉取请求相关的信息。但是这种方式的缺点是会增加上下文切换的工作量。另一种方法是使用番茄工作法（Pomodorotechnique）：每工作25分钟就穿插短暂的休息。它使人们更专注、更有效率、更健康、更少疲劳，休息后的情境切换感觉更自然。负面的破坏效果不会消失，反而会大大降低。5.注释您自己的拉取请求为某些更改（例如删除和重构）添加解释性代码注释没有意义，您应该考虑注释您自己的拉取请求以向审阅者提供更多上下文。6.在创建pullrequest之前rebase新的master有很多好处：测试可能在本地分支通过，但在应用最新更新时失败。能够使用新添加的功能（例如新的实用程序类）。如果审稿人没有找到最近的更改，他们会感到困惑。我更喜欢变基而不是合并，因为变基使分支只包含相关的提交。7.不要修改已审核的提交——发送新的提交以在单独的提交中处理审核评论，而不是修改或删除更改。这使得审阅者更容易检查自上次审阅以来发生了什么变化：8.在实施该功能之前讨论总体方法这可以节省大量时间。在处理更复杂的重构和功能之前，与同事讨论该方法。与其他开发人员讨论，解释任务和你的想法，他们可能会同意，他们可能会提出更好的方法。很多时候笔者都面临着前期协调不力，几天的工作成果付之东流。想象一下，连续五天都在做某事，却听到“抱歉，我们不需要……”为了避免失望，尽早获得反馈。9.感谢审稿人的建议深入理解别人所做的修改并提出有用的建议需要付出很多努力——请承认并感谢这一事实。请记住，代码更改是短暂的-与队友的关系是永恒的。花更少的时间在代码审查上，您的团队的绩效将迅速提高。将这些技巧应用到您的下一个拉取请求中，结果将产生很大的不同。
