Pull Request 的艺术
正如我之前写的， 我们是一个远程团队，团队成员遍布世界各地。这意味着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/
参考阅读：
长按二维码 关注「高可用架构」公众号