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

开发 前端
软件交付智能平台 LinearB 的数据科学团队研究了来自 2.6 万名开发者的 73.3 万个 PR 和 390 万条评论,发现:50% 的 PR 在其生命周期的 50.4% 的时间里处于闲置状态 ;33% 的 PR 在其生命周期中闲置了 77.8%(高达)的时间;参与调查的开发人员的平均周期时间为 6 天 + 5 小时;这些开发人员的平均 PR 审查时间为 4 天 + 7 小时。

软件交付智能平台 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

责任编辑:未丽燕 来源: 开源中国
相关推荐

2011-06-13 14:54:35

PageRank算法

2013-08-14 17:11:32

PR移动游戏移动应用

2011-05-10 17:20:52

PR

2011-06-24 10:23:33

PR值

2011-07-21 16:32:27

PR

2021-08-05 08:18:02

开源项目 PR

2021-08-04 09:33:22

Go 性能优化

2012-04-05 10:27:49

GooglePR之赛

2011-05-10 17:11:46

PR值

2022-07-04 09:17:37

Flask开源

2011-06-30 16:01:48

2011-06-15 17:55:29

PR值

2011-06-20 17:39:19

PR值

2013-08-20 14:14:29

海外市场移动游戏移动应用PR推广技巧

2011-05-10 14:00:54

2022-03-30 08:36:32

Node.jsPRHTTP

2018-09-12 15:11:35

微软GitHub开发者

2023-04-27 09:55:09

分类器ROC曲线混淆矩阵

2023-09-15 09:00:00

GitHub开源ChatGPT

2020-02-17 11:05:27

GitHub代码开发者
点赞
收藏

51CTO技术栈公众号