---
title: "PR应该有多少行？追溯400行建议的来源"
canonical: "https://siyuanailab.com/curation/translations/0db04a184d6e31819da2b5cd6f17bb6e-bc79e4a8adb34ef35d7c0df485e9b5cb5f144ea3cc8f3af97ed3df253295e035/"
dateModified: "2026-10-18"
datePublished: "2026-10-18"
---

[返回日报条目](https://siyuanailab.com/curation/#entry/0db04a184d6e31819da2b5cd6f17bb6e)

 

资料节译

 

# PR应该有多少行？追溯400行建议的来源

 

[阅读原文](https://dev.to/debtdraft/how-many-lines-should-a-pull-request-be-we-traced-the-400-line-rule-to-its-source-398c)

 

现有资料无法确认原文完整，本页只翻译已取得的材料。

 

现有原件无法确认图片是否齐全。

 

搜索“拉取请求应该有多少行”时，你会一遍遍看到同一个答案：控制在 400 行以内。有时说是 200 到 400 行，有时说“几百行”。这些说法总是被当作定论。

 

我们想知道这个数字从何而来。追根溯源并不费事。

 

这个数字可以追溯到一项[研究](https://www.stickyminds.com/article/largest-case-study-code-reviews-ever)。代码审查工具供应商 SmartBear 与思科的一个团队合作开展了这项研究。十个月里，三大洲的 50 名开发者在每次变更进入版本控制前都要对其进行审查。研究收集了 2,500 次审查的数据，涉及 320 万行代码，所有审查都通过 SmartBear 自家的审查工具进行。

 

研究的主要发现是：审查行数超过约 200 行后，缺陷密度会大幅下降。[SmartBear 目前的指导建议](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/)据此提出：每次审查不超过 200 到 400 行，因为超过 400 行后，发现缺陷的能力会减弱。

 

这是一项有真实数据支撑的研究。但大部分证据也就到此为止。

 

这项研究中的缺陷密度，指的是每单位审查代码中发现的缺陷数。因此，超过 200 行后数值下降，意味着审查者每行代码发现的缺陷更少。SmartBear 将其解读为审查者注意力开始涣散。我们的理解也一样。

 

它无法告诉你代码中的 Bug 是否更少，也无法判断这个 PR 是否不该发布。它衡量的是人们读代码的效果，而不是变更本身的风险。

 

还有几点值得了解：

 

- 这是 2006 年一个产品中的一个团队，在提交前使用专用工具进行审查。如今在 GitHub 上，带有 CI 和长讨论串的拉取请求，是另一回事。
 
- Jason Cohen 对这项研究的介绍说，统计方法和实验控制写在书里，而不是文章中。
 
- SmartBear 页面上常与 400 行说法一同出现的“70% 到 90% 的缺陷发现率”，没有注明来源。
 
- 发布这个数字的公司，也在销售用于审查代码的工具。

 

这些情况并不能证明这个数字有误，但说明它只是一个起点，不是定律。

 

有两家供应商公布了较新的数据，乍看之下两者互相矛盾。

 

[LinearB 的 2026 年基准数据](https://linearb.io/library/engineering-benchmarks-and-research)涵盖了 4,813 个团队的 8,109,244 个拉取请求。他们按第 75 百分位数评定 PR 大小：少于 100 行为卓越，100 到 155 行为良好，156 到 228 行为一般，超过 228 行则有待改进。页面没有说明行数统计的是新增行、删除行，还是两者都算。

 

Graphite 在一篇[2023 年的文章](https://graphite.com/blog/the-ideal-pr-is-50-lines-long)中提出，理想的 PR 中位数是 50 行，范围为 25 到 100 行。他们发现，50 行的变更比 250 行的变更审查和合并快约 40%。他们根据 1,000 万个 PR 的样本制作的回退图表显示，回退最少的 PR 有 25 到 50 行。不过，绝对差距很小：几乎所有大小的 PR，回退率都在约 1% 到 1.6% 之间。他们也指出，自家用户的 PR 倾向于较小。

 

两者其实并不冲突。LinearB 报告的是团队 PR 大小的第 75 百分位数，Graphite 报告的是中位数。一个团队四分之三的 PR 少于 100 行，同时中位数为 50 行，这两种情况完全可以并存。它们是同一分布的两种观察方式。

 

两家供应商都在销售用于衡量 PR 大小和审查速度的工具。数字不会因此就变错，但发布这些数字的人，确实会从你关注这项指标中获利。

 

[LinearB 的数据](https://linearb.io/library/engineering-benchmarks-and-research)还有一点值得一提。在他们的细分数据中，第 75 百分位 PR 的行数，未经辅助时约为 157 行，由智能体编写时约为 293 行，经 AI 辅助时约为 408 行。他们明确指出，这只是相关性，不代表因果关系。这的确说明，“合适”的大小取决于代码是如何编写的。

 

我们找到的来源中，没有一个显示超过 400 行的 PR 更可能带有 Bug 发布。思科的研究关注的是审查质量，供应商的数据关注的是速度和回退。两者都没有追踪代码合并后的情况。

 

行数衡量的是代码行数，而不是审查所需的精力。一个移动目录的 2,000 行 PR，比修改支付流程的 60 行变更更容易审查。生成文件、锁文件和迁移文件会抬高计数，却不会增加审查负担。Graphite 自己的回退图表还有一段奇怪的长尾：超过 10,000 行的 PR 看起来稍微更安全，作者猜测这是因为最大的变更多半是重构。

 

- 把 200 到 400 行视为一次审查时段的合理上限，而不是硬性规定。这是证据支撑最充分的数字，衡量的是阅读，而不是发布。
 
- 衡量你们自己的中位数和第 75 百分位数。这正是供应商报告的指标，也是唯一能描述你们团队的数据。
 
- 统计时排除锁文件、生成文件和纯移动操作。
 
- 变更必须很大时，说明应该从哪里开始读。在描述中写一句简短的“从这里开始”，比随意拆分 PR 更有用。
 
- 关注代码行里写了什么。一个加入分支繁多函数且没有测试的小 PR，比一个主要由删除代码组成的长 PR 问题更大。

 

最后这一点正是我们开发[DebtDraft](https://debtdraft.dev/)的原因。它是一个 GitHub Action，会在每个拉取请求上发布一条持续更新的评论，其中包含健康评分，以及仅展示该 PR 修改行的视图。这个工具是我们做的，所以请据此权衡我们的看法。

 

那么你们的数字是多少？你会把一个拉取请求控制在多少行？到多少行时，PR 会让你觉得难以应付？

 

AI 翻译；具体表述请与原文对照。