软件交付智能平台 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 上网友讨论中的一些高赞回答：
文章中提到，在任务之间很难找到时间进行 quick review。这就是你的问题所在。审查 PR 应该是一项与创建 PR 同样重要的任务。如果有公开的 PR，就不要开始工作。开始在一个新问题上工作只会使一切变得更糟，并使你的团队更加缓慢。
显然，要鼓励提交小的 PR；如果是大的 PR，则至少要尽量把它分成明确的提交。
审查 PR 应该是一项与创建 PR 同样重要的任务。
大众需要理解这一点。高质量的代码并不 cheap，尤其是在为项目定义 设计模式 的初期。
如果你在这一步上偷懒，你的代码将很快变得杂乱无章（big ball of mud）。
请告诉我的同事这个。他们认为“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 审查效率的方案，并表示已收获了积极地反馈。详情可查看文章。
猜你喜欢: