PR 闲置时间太长？审查 PR 与创建 PR 同样重要

软件交付智能平台 LinearB 的数据科学团队研究了来自 2.6 万名开发者的 73.3 万个 PR 和 390 万条评论，发现：

• 50% 的 PR 在其生命周期的 50.4% 的时间里处于闲置状态 ；

• 33% 的 PR 在其生命周期中闲置了 77.8%（高达）的时间；

• 参与调查的开发人员的平均周期时间为 6 天 + 5 小时；

• 这些开发人员的平均 PR 审查时间为 4 天 + 7 小时。

对此，LinearB 的 COO 兼联合创始人 Dan Lines 则认为，PR 过程中的闲置时间就是开发者流程中的一个 killer。并表示，PR 悖论给自己和团队带来了很大的困扰。根据解释，所谓 PR 悖论（Pull Request Paradox）就是：我刚刚写了一些代码，可以对我们的客户产生积极的影响，我有动力尽快发布它。我需要你的帮助，但你却很忙，而且有动力继续写你自己的代码。这种冲突就是 PR 悖论。

Dan 称，研究所得的数据意味着：

• 每块工作平均有两天的闲置时间，造成了生产力浪费。
• 此举损害了开发团队合并和发布代码的能力，从而阻止价值交付。 
• 闲置的时间会导致情景意识的降低、代码质量的降低和努力的浪费。“在我们打开一个新的 PR 之后，每过一个小时，重新审视我们的代码的认知负荷就会增加。如果我在一两天后收到问题或修改请求，就很难再回到我原来的流程状态。闲置时间损害了质量，因为当生产中出现我几天或几周前写的代码的问题时，就更难调试了。”
• 导致团队承诺无法兑现。

不过 Dan 的观点也遭到了一些网友的反驳，以下是 Reddit 上网友讨论中的一些高赞回答：

IceSentry：

文章中提到，在任务之间很难找到时间进行 quick review。这就是你的问题所在。审查 PR 应该是一项与创建 PR 同样重要的任务。如果有公开的 PR，就不要开始工作。开始在一个新问题上工作只会使一切变得更糟，并使你的团队更加缓慢。

显然，要鼓励提交小的 PR；如果是大的 PR，则至少要尽量把它分成明确的提交。

grauenwolf：

审查 PR 应该是一项与创建 PR 同样重要的任务。

大众需要理解这一点。高质量的代码并不 cheap，尤其是在为项目定义设计模式的初期。

如果你在这一步上偷懒，你的代码将很快变得杂乱无章（big ball of mud）。

8BitSk8r：

请告诉我的同事这个​​。他们认为“agile”意味着“we don't plan we just react”。

此外，Dan 还在文章中列举了一些 PR 的替代方案。首先是"真正的"持续集成。现在很流行的一种说法是，CI 和 PR 是相互排斥的。基于主干的开发允许开发人员直接提交到主分支，而不需要任何形式的审查或合并过程。但 Dan 认为，这种方法可能只适用于最精英的团队；对 95% 的人来说，它的缺点要大于优点。

其次是有人提出了一种 Ship / Show / Ask 策略：这是一种分支策略，它结合了 PR 的功能和保持发送变更的能力。Changes 被归类为"Ship"（不经审查合并到主线）、"Show"（打开 PR 进行审查，但立即合并到主线）或 "Ask"（在合并之前打开 PR 进行讨论）。总的来说，此策略对于低风险的工作，选择直接合并而不审查或事后审查是有一定道理的。但是 Dan 指出它也存在一个问题，即目前大多数团队都没有适当的定义、流程和自动化来使其发挥作用。
 

此外还有结对编程（Pair programming），不过这一方法好像也不尽适用。“我知道很多开发团队使用结对来补充异步拉取请求审查，而我个人从未在一个使用结对来取代 PR 的团队工作过。”

Dan 表示，他不认为 PR 会消失。“根据我的经验，在合并之前让队友审查你的代码是提高质量和减少错误的最好、最实惠的方法。PR 在捕捉可维护性错误方面特别有效，而这些错误是很难通过自动测试发现的”。且很多开发人员都同意 PR 是提高学习和教学质量的好工具。 

而 LinearB 团队也针对 PR 悖论推出了一个相关的提升 PR 审查效率的方案，并表示已收获了积极地反馈。详情可查看文章。