Art of Pull Requests(翻译)

1 分钟阅读

本文链接: https://blog.openacid.com/culture/pr/

原文: Art of Pull Requests

img

正如我之前写的, 我们是一个远程团队,团队成员遍布世界各地。 这意味着code reviews 和 pull requests必须远程完成。

最近,我们团队的一位成员提出了这样的宣言:

作为 PR writer 我会:

  • 保持PR够小
  • 使用标签表明PR是许多部分之一
  • 发布PR后在Slack上也提一下

作为 PR reviewer 我会:

  • 一有空就review。
  • 只要比以前好就批准吧.
  • 尽量不要reject一个PR, 有时可以发一个tiket来作为这个PR的补充, 或要求下一个PR来补充这个PR.
  • 建议而不是拒绝,特别是当用标签来标识多个部分的时候.

我们来看看这个。 本质是:PR需要小而快!

这也符合程序员的誓言:

我会发布频繁和小的release,这样我就不会妨碍他人工作的推进

但是,我们都知道,PR的问题是通常它们要在review状态下持续一段时间。

请求越大,review时间越长

我们希望尽可能地接近head开发方法,在这种方法中,代码很容易进入master/develop。 我们应该致力于连续的产生好的代码。

我们需要与长期存在的feature分支作斗争,因为它们是所有邪恶的根源!

img

因此,PR需要能够快速地查看,以便快速地合并代码。 但这只适用于小的PR! 你不会在一个大的PR上得到一个好的review,它要花很长时间才能把它merge。 因此,一些公司对每一份PR的行数都有限制。一般来说,它们的长度应该少于300行,否则它们就不适合被review了。

img

PR越长,review的人就越累

如果review很累,开发人员就不想review了。 但是我们需要团队尽可能频繁地检查代码,所以不要让他们感到困难!

给出上下文

让review人员更容易理解您的更改。 他们可能不会像你一样熟悉你正在做的事情。 添加一个好的描述和一些截图:

img

防止上下文切换

让PR提交者尽早收到review评论,这样他就不需要从他已经在处理的下一个任务,切换回上一个任务. review花费的时间越长,开发者就越难以从其他任务中切换回来并进行更改。 所以,让你的PR尽可能小,并尽可能频繁地创建它们:至少一天一次! 或者更频繁!

审稿人也需要帮助

如果您一天只review一次PR,那么每天打开多个PR的想法对您的团队来说是行不通的。

所以审查经常!

在每一次休息之后,在你开始一张新ticket之前,在每一次番茄工作法 之后,或者每次你自己打开一个pull request之后。

我们的团队引入了打开的PR上限, 与看板中的WIP限制类似。 如果达到限制, 任何人都不允许打开一个PR,首先review别人PR来清空队列!

专注于重要的事情

所有的代码样式都应该首先由一些自动化的任务来检查—这不是一个人的任务。 CI应该帮助处理大量的代码检查(静态分析:反模式、复杂性、潜在的内存泄漏), 这样review可以很容易地集中在逻辑和体系结构上。

不要太严肃

PR是与团队成员的讨论。 不要把它当成教学课程。 提出建议不要要求他们。 友好。 使用表情符号和动图让读者对你的建议会心一笑:

img

评论是对同事的反馈,也有积极的反馈,如果某件事做得很好,你应该心存感激。

img

PR不适合进行长时间的架构讨论

不要过度使用PR讨论。 反正也太迟了,代码已经写好了! 使用其他渠道,如每日/每周的开发者会议。 PR的作用在于,确保质量水平提高,并发现潜在的bug和副作用。 如果你的团队中有下级,试着使用结对编程, 不要通过PR来教,否则会令人沮丧。

如果代码比以前更好,那么批准它

如果发现有什么东西可以变得更好,打开一个issue或ticket。 当然,这需要一种持续处理技术债务的工作文化,这样ticket就不会被积压淹没。 如果PR只是部分ticket,则它更容易被优先处理。 另一个PR肯定会很快到来,可以立即解决这个问题。

不要害怕

在像我们这样的远程工作环境中,当PR可能在一夜之间被合并时可能会很可怕——您甚至没有机会看到或评论请求。 当一个团队成长时,这是正常的。 您不能控制、检查或知道任何一行代码。 接受这一点需要勇气和信任!

原文: Art of Pull Requests

本文链接: https://blog.openacid.com/culture/pr/

openacid

留下评论