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

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

作为 PR writer 我会: 

保持 PR 够小

使用标签表明 PR 是许多部分之一

发布 PR 后在 Slack 上也提一下

作为 PR reviewer 我会:

一有空就 review。 

只要比以前好就批准吧。

尽量不要 reject 一个 PR, 有时可以发一个 ticket 来作为这个 PR 的补充, 或要求下一个 PR 来补充这个 PR。

建议而不是拒绝，特别是当用标签来标识多个部分的时候.

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

这也符合程序员的誓言:

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

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

请求越大，review 时间越长

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

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

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

PR越长，review的人就越累

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

给出上下文

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

防止上下文切换

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

审稿人也需要帮助

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

所以审查经常!

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

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

专注于重要的事情

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

不要太严肃

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

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

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

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

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

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

不要害怕

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

本文转载自公众号分布式研究小院，由张炎泼翻译。精致版可访问 https://blog.openacid.com/culture/pr/