How Stacked PRs Improve Code Review Quality?

Stacked PR 如何改善代码审核质量？

#unsorted

前言

当只有 10 行代码改动时可能会细心检查留言，10000 行改动一切都 LGTM（Looks Good to Me）！

最近留意到审核代码能量有限，可能是没有测试覆盖带来信心，或是程序难以理解维护，也有可能请假等因素，总之好好集中精神审核几千行的代码改动本身就是很难得的事，身为提交代码的一方，有没有可以改善审核效率的方式？或许能试试看 Stacked PR。

切分出更能被审核的代码提交审核（PR）

各种研究和经验都表明太长或太多的代码审核都会降低效率🔗，所以最好是能将大型的 PR 切割成独立且更好懂的修改提交，但有时候修改是相依的且会阻挡进度。

举例来说，一个复杂的功能可能牵扯到数据库调整、商业逻辑修改、用户界面的变动、甚至文档或测试改写。这时候如果一次把所有改动塞进单个提交审核，容易提升审核难度。

这时可以采用 Stacked PR 的技巧，将大型功能拆解成一系列小步骤的 PR，每个 PR 都有明确的目的并基于上一层 PR，最终将一条复杂的分支切割成能管理的多条分支进行审核。

Stacked PR 实践细节

由最先开启的 PR 最先开始审核
PR 都被视为进行中（Work in Progress, WIP）状态，审核完也还不能合并
直到最后创建的 PR 完成审核才开始由最后创建的 PR 依序合并

Stacked PR 只是一项手段

Stacked PR 也会带来维护上的负担，最明显的问题就是分支之间进度同步的问题，不管是借助 merge 或 rebase 都会带来额外的操作负担，这也是许多工具想解决的其中一个问题：

虽然我会偏好如 Trunk Based Development🔗 声明：「应该尽量避免长期存在的分支」，通过频繁推送更新至主干来开发，不过多了解一种解决问题的思路也不错。

延伸阅读