软件交付智能平台 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 审查效率的方案，并表示已收获了积极地反馈。详情可查看文章。
本文转自OSCHINA
本文标题：PR 闲置时间太长?审查 PR 与创建 PR 同样重要
本文地址：https://www.oschina.net/news/176589/pull-request-review
