0130W Notes

Article

为什么我们需要stacked-prs

简要介绍一下stacked-prs概念及其用法,以及为什么今天我们更迫切需要它.

  • Notes
  • Computer

以往的单个PR存在什么问题

一般来说, 当我们需要上线一段代码的时候, 都是在本地编写代码后commit, 多个commit推送到远端分支之后, 发起PR, 邀请某(几)个Reviewer对代码进行审查, 确认无误后合并代码到主线分支. 这种方式在有上线一个big feature等代码修改量较大的需求的时候对Reviewer的心智负担极大. 这里引用一些社区中对large pr/code review的一些讨论供大家参考:

  1. Feature Request: Better tooling for large PRs

  2. Reviewing big pull requests in startups

  3. How Jane Street Does Code Review

TL;DR: 社区中大家遇到的一些问题大概可以概括为以下的部分:

  1. 作为写代码的人: 在写完代码后还需要将其拆分为若干个易于Review的部分单独PR, 是一件非常消耗精力的事情

  2. 作为Reviewer: 当面对一个代码diff极大的PR的时候

  • 难以下手, 不知道应该从哪里看
  • 在Review的过程中大段代码对注意力的消耗, 容易让人遗漏代码中存在的问题
  • 当我对代码中某个小部分的设计不满意时, 在同伴修复完后, 我希望仅关注于就上次而言不同的部分

就我个人经验而言, 还可能存在这样的一种情况: 单次的PR跨了多个模块的代码修改(这很正常, 因为我们大部分的仓库都属于monorepo), 而多个模块的负责人可能不同, 在邀请对应的负责人对代码进行审查的时候, 作为Reviewer当然是希望仅关注于自己模块的部分(换而言之, 写代码的人应该将代码切分成对Reviewer友好的多个Part, 按Part来邀请负责人进行Review).

为什么在今天这个问题显得更为重要

一个重要原因是AI的发展, 许多人应该已经在24小时连轴跑AI来完成各种任务, 各Coding Copilot也推出了如/goal模式等来让大家能够更方便的长时间跑AI任务, 这就非常容易导致AI的单轮任务代码 Diff极大. Review这样的代码对人的注意力和精力都是非常大的挑战.

Stacked-PRs是什么

其实就是字面意思, 可以将多个PR按照栈的方式进行排布,

参考文档