程序员提交 PR 的理想长度是多少？有人答：50 行代码！

【CSDN 编者按】你认为 PR 的长度多少最为合适，本文作者认为的理想长度是 50 行。

原文链接：https://graphite.dev/blog/the-ideal-pr-is-50-lines-long

未经允许，禁止转载！

作者 | GREG FOSTER       译者 | 弯月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

大多数工程都认为，代码变更规模越小越好。原因很简单，拉取请求（Pull Request，PR）越小越容易审查，出错的概率越低，部署的速度也越快。

但 PR 的理想长度究竟是多少呢？会不会出现 PR 太小的问题？如果说小 PR 更好，那么究竟有多好呢？

PR 的理想长度应为 50 行

我们认为，PR 的理想长度应为 50 行。

50 行代码变更的审核与合并速度比 250 行快约 40%。与 250 行的代码变更相比，50 行代码修改后被撤销的可能性低 15%，而且每行变更的审阅意见增加了 40%。此外，如果队友提交的 PR 的中位数为 200 行，而你的中位数为 50 行，那么你交付的总代码量将多出 40%。

50 行是确保编程速度、增加审核意见、降低撤销率以及提高提交代码总量的最佳选择。就可接受的范围而言，我推荐每个 PR 为 25~100 行代码。根据数据，我们发现 PR 越小，花费在审查、合并以及每行评论上的时间都越少。但有一个限制：如果代码修改行数低于 25 行，则修改被撤销的概率会提高，而且交付的总代码量也会降低。

下面，我们来谈谈原因，并看看支持这一结论的数据。

样本集

本文中所有基于数据的陈述都使用了通过 Graphite 同步的私有以及公共 PR 和代码库。为了找出理想的 PR 大小，我研究了以下四个主要指标及其与 PR 大小的关系：

• 审核与合并代码的时间；

• 撤销修改的概率；

• 平均评论数；

• 年度代码变化总量。

注意事项

根据我们收集的这些数据推断结论时，需要注意以下事项：

• 根据 PR 的大小进行分类时，分类的大小并不是统一的，也不是线性的，因为线性大小分类的粒度太细，指数大小的分类又会丢失很多细节。

• 我使用了 PR 大小的中值，而非平均值，为的是避免个别重构导致整个数据发生扭曲。

• 修改被撤销的判断标准是：PR 的标题中带有“Revert”（撤销）一词，因为 git revert 会自动将这个单词添加到标题前面。

• 我们发现 Graphite 用户通常倾向于创建较小的 PR，因为许多组织使用基于主干的开发风格（这会鼓励较小的 PR）。

审核代码的时间与合并代码的时间

下面，我们来深入挖掘数据。首先，我们来看看审核代码的时间与合并代码的时间，我们发现与包含 2~5千行代码的 PR 相比，代码量最少的 PR 的速度快了近 5 倍。这不难理解，因为 PR 越小意味着代码量越少，而代码量越少则意味着变更具有破坏性或涉及大量细节的可能性较低，因此审查的速度越快。

然而，当修改的代码量超过 5 千行后，PR 再次开始提速。我认为这是由多种原因造成的，包括安全的重构、添加包或生成的代码，也许是因为代码量太大，作者和审核者都无法详细阅读所有代码变更。

请注意，此处我们更关心的是每个 PR 的时间，而不是每行代码的时间。若只论如何尽快将 PR 合并到代码库，则通过数据我们可以看出 PR 的规模越小越好。但是，如果我们的目标是如何尽快交付代码，则 2000 行 PR 的合并速度约为每小时 12 行，而 10 行 PR 的合并速度约为每小时 0.25~2 行。

按 PR 大小划分的撤销率

撤销率反映出了相同的结论：PR 越小，修改被撤销的次数越少。撤销率最低的 PR ：代码修改量在 25~50 行之间。但是，一些边缘情况依然表现出十分有趣的特质。代码量少于 10 行的 PR 的撤销率明显多于 10~100 行的 PR。我猜，这是因为低于 10 行的 PR 大多为比较危险的配置更改，但我估计对修改行数进行规范化后这种假设应该就不成立了。

在 PR 的规模超过 1 万行后，“安全性”似乎会略有所提升。我怀疑这是大规模的 PR 一般都包括重构 ，功能变更较少，因此破坏性也更低。或者是因为在超过 1 万行后，由于抵触心理和合并冲突，工程师可能不太愿意撤销这样的 PR。

按 PR 大小划分平均评论数

根据优化的目标不同（提高合并速度，还是深度的代码审查），你可以选择是否拆分 PR。如果你想获取更多反馈，则可以选择将代码的变更规模控制在 1~2 千行代码。如果你只想尽快合并，请将代码变更保持在 10 行以下。如果你关心的是如何尽快地交付变更，不希望花费太多时间在唇枪舌战上，则了解此信息很有用。

我们还看到，随着 PR 规模的增长，评论的平均数开始逐渐减少。审查者究竟愿意阅读多少代码？这实际上有一个限制：我认为 2 千行应该是“阅读” PR 变成“浏览” PR 的临界点。

如果你关心的是从长远来看，最大限度地提高代码的参与度和反馈量，那么应该尽可能控制 PR 的大小。为了更容易理解，你应该每 39 行代码就添加一条注释。相反，如果你讨厌写反馈，则可以让 PR 超过 1 万行，这样每 6000 行代码变更也只会收到零星几个评论——这一点请自己体会，毕竟没有哪个程序员提交 PR 的最终目的是获取反馈或意见。

交付代码总量

你可能在想，编写小规模的 PR 是否会影响到交付的代码总量。我们都希望提高速度，但有时你需要高产出。持续编写 20 行以下的 PR 将对编程的速度产生重大影响，但有趣的是，编写超过 100 行以上的 PR 也会对编程的速度产生重大影响。为保证最大化产出，PR 大小的中值为 40~80 行。我认为这是因为代码的交付量 = 变更大小 * 变更速度。如果变更太小，即便提高合并速度，也无法最大化产出。相反，如果变更太大，审核代码和合并代码的周期就会变慢。

总结

开发人员应该以 PR 中值：50 行为目标。当然，我们也需要考虑到一些边缘情况，并根据实际的需要调整代码变更的大小，同时你需要明白调整 PR 的大小将对审核质量、速度以及撤销变更的可能性等方面造成巨大影响。

本文文字及图片出自 CSDN