主张：理想的 PR 长度是 50 行

原文 ↗ Hacker News 讨论 ↗

一项主张认为，基于更快的合并和更少的回退等指标，“理想”的拉取请求大约应为 50 行代码，这引发了关于软件变更应如何组织和审查的讨论。许多工程师认为，行数并不是衡量质量的好代理指标，指出真实的功能、重构和测试通常需要数百甚至数千行，而且过小的 PR 会碎片化上下文、增加协作开销，并引发无谓争论。逐渐形成的共识是：好的 PR 应当代表一个连贯、可审查、能够安全部署的工作单元，而大小应被视为灵活的指导原则，而不是需要优化或强制执行的硬性目标。

关于“50 行理想值”说法的总体反应

  • 许多人认为这种说法缺乏上下文，过于泛化，甚至有点“可笑”。
  • 也有人认为其核心想法——更小、更聚焦的 PR 更容易理解，也更安全——大体成立，但应被视为指导原则，而不是规则。
  • 还有几位提到这篇文章来自一家会从更小/堆叠式 PR 中受益的公司，因此部分上把它看作一种产品宣传。

支持更小 PR 的理由

  • 更容易彻底审查；不太容易草率点头通过。
  • 在所引用的数据中，往往与更少的回退和更快的合并时间相关。
  • 对作者和审查者来说认知负担更低；更容易在零碎时间里安排快速审查。
  • 更擅长隔离行为变化，使回退和调试更简单。
  • 有助于防止“怪兽 PR”，这类 PR 经常混入 bug，而且很难推理。

反对严格按行数设定目标的理由

  • 代码行数被认为是衡量复杂度或价值的糟糕代理指标。
  • 任意限制（例如 5 行或 50 行上限）会破坏上下文、迫使 awkward 地拆分、鼓励省略测试，并让功能更难作为整体审查。
  • 过小的 PR 可能导致过度上下文切换、理解碎片化，以及“死于一千个 PR”。
  • 重构、重新设计、新子系统、模式变更，或大规模测试补充，往往合理地会跨越数百甚至数千行。

上下文、内容与“工作单位”

  • 许多人认为真正的“理想”是：每个 PR 包含一个连贯、可部署的行为单元，不管它有多少行。
  • 提交 vs PR：几位评论者更喜欢在较大的 PR 内包含小而逻辑清晰的提交，并保留干净的历史，便于回退和考古式追查。
  • 有些人强调测试代码通常也应该放在同一个 PR 中；另一些人则建议把非关键测试补充放到单独的 PR 里。

指标、因果与流程

  • 多位评论者强调相关性不等于因果性；小 PR 可能只是本来就更简单、风险更低的工作。
  • 也有人担心管理者会把它 Goodhart 化，变成脱离实际质量的目标（“PR 必须大约 50 行”）。
  • 经验差异很大：有些团队通过强制更小的 PR 提高了可靠性；另一些团队则发现严格限制拖慢了交付并恶化了审查。