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🔗 聲明：「應該盡量避免長期存在的分支」，透過頻繁推送更新至主幹來開發，不過多了解一種解決問題的思路也不錯。

延伸閱讀