你的 PR 变得臃肿的真正原因
我曾经在一家习惯于提交海量 Pull Request (PR) 的公司工作。一个 PR 可能会挂在那里好几周。评审它需要你在脑海中构建起整个子系统的逻辑。Bug 堆积如山，截止日期不断延后。最终，我们不得不重构系统的很大一部分，因为已经没有人敢在不引起风险的情况下对其进行修改了。
那些工程师并不差。他们很聪明，也很努力。PR 变得臃肿，原因其实很枯燥。
没有人教过他们如何拆解工作。
我们经常把大型 PR 视为纪律问题。我们会说：“把 PR 做小一点就行了。” 我们表现得好像 1,500 次改动和 150 次改动之间的唯一区别就是意志力一样。
这并不是意志力的问题。将庞大的工作拆解成细小、独立的模块是一项技能。大多数人从未接受过这项训练。当一个任务单（ticket）写着“添加计费功能”时，它看起来像是一个单一的任务。而难点在于，如何界定一个 PR 在哪里结束，下一个又从哪里开始。
我以前也提交过大型 PR。我当时认为“完成”意味着一次性解决整个问题并提交评审。我花了数年时间才明白，小规模改动才是更好的选择。
小规模 PR 改变了我的一切：
- 评审人员能发现更多 Bug。人类可以理解约 200 行改动，但无法理解 2,000 行。面对海量改动，他们只能走马观花地扫一眼然后点通过。
- 合并速度更快。PR 不再在队列中堆积。
- 我不再感到压力山大。我可以一次专注于一个部分。
- 我成了一个更好的规划者。你必须理解工作的整体轮廓，才能将其拆解。
我开始把系统看作乐高积木。它们是能够拼接在一起的小零件。一旦你看到了这些“积木”，拆解工作就会变得顺理成章。
我现在的团队提交的都是小规模 PR。效果显而易见：
- 我们的平均合并时间为 1.5 天。
- 我们能快速发现并修复 Bug，因为改动非常清晰易读。
- 我们的交付节奏非常稳定。
拆解工作是一项需要指导的技能。你无法通过制定规则来解决大型 PR 的问题。你只能通过教会人们如何看到那些“积木”来解决问题。
AI 让这项技能变得更加至关重要。
过去，编写 2,000 行代码需要付出巨大的努力。这种阻力使得 PR 保持在较小的规模。而 AI 消除了这种阻力。你只需一个提示词（prompt）就能生成海量的改动。
工作量并没有消失，它只是转移到了评审人员身上。作者无需付出任何代价，但评审人员却要承担全部代价。
如果规模不再能预示作者的工作量，那么规模也几乎无法告诉你风险所在。你必须决定哪些部分值得你投入最细致的关注。
教会你的团队去观察“砖块”。这是工程领域中杠杆率最高的习惯。
你的团队是如何决定哪些 PR 需要深度评审，而哪些可以快速通过的？
来源：https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
可选学习社区：https://t.me/GyaanSetuAi