软件交付智能平台LinearB的数据科学团队研究了来自26,000名开发人员的733,000个PR和390万条评论，发现：50%的PR在其生命周期的50.4%以内时间;33%的PR在其生命周期的77.8%（最多）时间内处于空闲状态；参与调查的开发人员的平均周期时间为6天+5小时；这些开发人员的平均PR审查持续时间为4天+7小时。对此，LinearB的COO和联合创始人DanLines认为，PR过程中的空闲时间是开发过程中的杀手。并表示公关悖论给自己和团队带来了很大的麻烦。根据解释，所谓的PRParadox（PullRequestParadox）就是：我只是写了一些可以对我们的客户产生积极影响的代码，我有动力尽快发布。我需要你的帮助，但你很忙并且有动力继续编写自己的代码。这种冲突就是PR悖论。据Dan介绍，研究数据表明：每件工作平均闲置两天，造成生产力浪费。此举损害了开发团队合并和发布代码的能力，阻碍了价值的交付。空闲时间会导致态势感知能力下降、代码质量下降以及精力浪费。“在我们打开一个新的PR之后，重新访问我们的代码的认知负担随着时间的推移而增加。如果我在一两天后收到问题或错误请求，就很难回到我的旧PR。过程状态。空闲时间会影响质量，因为当我几天或几周前编写的代码在生产中出现问题时，调试起来会更加困难。”导致团队承诺被打破。不过，Dan的观点也遭到了一些网友的反驳。以下是Reddit上网友讨论中的一些好评度很高的回答：reviewbetweentasks.这就是你的问题所在.ReviewingPR应该和创建PR一样重要.如果有publicPR不要开始工作.开始处理一个新问题只会让事情变得更糟并且变慢你的团队甚至更多。显然，鼓励提交小的PR；如果它是一个大的PR，至少尝试将其分成不同的提交。grauenwolf：审查PR应该与创建它们一样重要。公众需要理解这一点。高质量的代码并不便宜，尤其是在为项目定义设计模式的早期阶段。如果你在这一步偷懒，你的代码很快就会变成一团大泥巴。8BitSk8r：请告诉我的同事们这件事。他们认为“敏捷”意味着“我们不计划我们只是反应”。此外，Dan还在文中列出了一些PR备选方案。首先是“真正的”持续集成。现在流行的说法是，CI和PR是互斥的。基于主干的开发允许开发人员直接提交到master分支，而无需任何形式的审查或合并过程。但Dan认为这种方法可能只适用于最精英的团队；对于95%的人来说，它的缺点大于它的优点。第二种是有人提出Ship/Show/Ask策略：这是一种分支策略，结合了PR的功能和不断发送更改的能力。更改被归类为“发布”（合并到主线而无需审查）、“显示”（打开PR以供审查，但立即合并到主线）或“询问”（打开PR以在合并前进行讨论）。总的来说，这种策略对于低风险的工作是有一定意义的，选择不经审查直接合并或者事后合并。但Dan指出，它还有一个问题，即大多数团队目前没有适当的定义、流程和自动化来使其发挥作用。还有结对编程（Pairprogramming），不过这种方法好像不太适用。“我知道很多使用配对来补充异步拉取请求审查的开发团队，我个人从未在使用配对来代替PR的团队中工作过。”Dan说他认为PR不会消失。“根据我的经验，让队友在合并之前检查您的代码是提高质量和减少错误的最佳且最经济的方法。PR在捕获难以通过自动化测试发现的可维护性错误方面特别有效”。许多开发人员都认为PR是改进学习和教学的重要工具。针对PR悖论，LinearB团队也推出了提高PR审核效率的相关计划，并表示收到了积极的反馈。有关详细信息，请参阅文章。本文转自OSCHINA文章标题：PR是不是闲置太久了？审查PR与创建PR一样重要
