目录- 有何改变- 设计仍需先行- 全面构建- 在他人阅读代码前进行演示- 小范围交付- 收益与成本- 适用场景全面构建小范围交付优秀的工程师在构建前会进行规划。以往常见的工作流程是怎样的呢是撰写一份描述功能的 RFC请求注释将其拆分为更小的问题然后逐个解决每个问题通常会阻碍下一个问题的解决。在编写第一行代码之前工作结构就已确定。这是合理的做法它使代码审查易于管理避免了大规模合并。但它也存在问题它要求你在对问题了解最少的时候做出最关键的结构决策。在还未构建任何东西时你只能靠猜测哪些部分可以分离每个部分的复杂程度如何第三步是否会让你重新思考第一步。有时你猜对了但很多时候并非如此第一步的工作可能会被推翻。虽然在构建过程中你学到了一些东西但如果先构建整个功能你会学得更快。我们付出这样的代价是有原因的另一种选择是先构建所有内容然后手动梳理而梳理一周的工作比提前规划要困难得多。提前确定边界从来都不是为了让构建更容易而是为了让审查成为可能这也是当时唯一可行的方法。但现在情况发生了变化究竟有哪些改变呢有何改变有三件事的成本大幅降低- 构建AI 助手可以在数小时甚至数分钟内将一个明确的问题转化为可用的代码。- 设计你可以快速审视和重塑一个计划。- 分解已完成的分支这是最重要的一点。过去将一周混乱的工作拆分成一系列小的 PR拉取请求是最繁琐的工作这也是我们一直避免的原因。而现在只需一个指令就能完成。有两件事的成本并未降低。首先是代码审查中的判断部分。AI 代理使机械性的审查如代码一致性、小错误和明显的 bug几乎变得免费但它们无法解决微妙的正确性问题以及相关疑问比如这个更改是否应该放在这里这个接口形状在六个月后是否会有问题。机器人批准你的 PR 并不等同于你理解了代码如果你没有亲自编写代码阅读代码是你掌握它的途径。小范围的 PR 让阅读代码成为可能。其次是产品验证。运行产品并确定它是否值得构建仍然很耗时。新的变化是现在可以在任何人阅读代码之前让整个功能提前运行起来并展示给他人。所以不要再为了避免一个已经不存在的成本而提前确定边界了。现在的工作流程是怎样的呢1. 审视计划直到计划中有明确的决策。2. 提交规范当设计新颖时在编写代码之前提交规范。3. 全面构建在构建过程中设置保存点。4. 演示与迭代在任何人阅读代码之前进行演示并迭代。5. 拆分为 PR根据代码呈现的边界进行拆分。6. 合并与清理最后进行纯删除操作放在一个单独的最终 PR 中。设计仍需先行需要明确的是这并不是“跳过规划直接编码”。在打开编辑器之前会有一个计划每个功能都从一次审视开始。使用 [grill - me] 这个工具它会以对抗性的方式询问你的想法直到有明确的决策。比如如果 API 调用失败备用方案是什么对所有事情都会使用它包括小的更改它总能发现之前没意识到的问题。当设计新颖时计划会变成一个规范在编写代码之前提交。在另一个项目中第一个 PR 是一个文档描述了功能是什么、如何工作以及信任边界在哪里。它在任何实现代码之前就合并了这样团队可以先提出意见。永远不要提前确定 PR 的分解方式。在构建之前确定要构建什么在构建之后再确定如何拆分。全面构建一旦设计确定就开始构建。通常会分步进行但不会在每一步都打开一个 PR 等待审查。所有工作都在一个分支上进行直到整个功能端到端都能正常工作无论涉及多少文件。会有提交操作但这些提交对其他人来说不是里程碑它们只是保存点比如证明了某个概念或者即将尝试有风险的操作需要一个回退点。最近完成的一次重构一天内在几十个文件中进行了十几次提交并带有操作信息。这些提交点让自己知道进度而不是为了给审查者讲故事。这可能会让一些工程师感到不舒服原因是什么呢因为 git 历史记录通常被认为是一种记录。但这个构建分支的历史记录不会成为最终的记录。最后的 PR 是从 main 分支上重新创建的而构建分支就像草稿纸完成后就可以扔掉。这里有两个不同的受众自己和审查者将他们分开可以让你同时为两者优化。在他人阅读代码前进行演示一旦工作达到一个较好的状态会停下来展示成果。不是以 PR 或代码审查的形式而是在 Slack 上发一个简短的视频或者进行预览部署如果更改需要实际操作。在开始任何代码审查之前从使用者那里获取对可用软件的反馈。现在由于机械性审查部分已经自动化审查变得更加耗时。如果在审查时才发现构建了错误的东西如混乱的 UI 模式、不适合前端数据使用方式的接口形状会浪费审查者和自己的时间。而演示可以在更改成本较低的时候发现问题。如果演示中出现需要重新思考的问题会先用 grill - me 工具分析反馈这样迭代就不是凭感觉进行的。小范围交付构建顺序只是拆分的一个粗略草案步骤会被重新组合和切割。删除 PR 就是一个明显的例子它是一个只有在新功能就位后才会存在的单元。使用一个指令“将当前工作拆分成最小的、可独立审查的 PR 集合每个 PR 都可以安全地单独合并并且在工作允许的情况下每个 PR 都能为用户带来价值。为每个 PR 创建一个 git 工作树并从 main 分支派生。只有在存在实际依赖关系时才进行堆叠否则从 main 分支派生。任何被替换代码的删除操作都放在一个单独的最终 PR 中。在创建任何东西之前展示建议的拆分方案。”拆分所需的时间取决于工作的混乱程度从几分钟到几次来回沟通不等。无论如何都不需要手动挑选提交。那次重构最终拆分成了五个 PR两个后端接口作为 main 分支的兄弟分支两个前端视图分别依赖对应的后端接口 PR最后一个 PR 是纯删除旧路径的操作。删除的代码行数比整个新功能添加的代码行数还多几百行。这就是按照这个顺序进行重构的样子。通过反复实践总结出两条规则- 仅在存在实际依赖关系时进行堆叠前端视图 PR 依赖于其后端接口 PR分支结构应反映这一点。其他所有内容都从 main 分支派生。为了方便而进行堆叠会创建一个变基链一旦底层 PR 收到反馈你就会后悔。- 清理工作最后交付旧代码在新功能上线后放在单独的 PR 中删除。将删除操作与创建操作混在一起会让审查者感到困惑使回滚操作不明确并且会将清理工作淹没在功能开发的噪音中。拆分也是阅读自己工作的时候。逐个查看 PR 的差异以能理解的规模进行这让自己不仅交付了 AI 编写的代码还真正理解了它。更希望在这里发现自己的问题。一个实际的注意事项管理堆叠会很快消耗注意力所以将拆分工作交给子代理让它们向主代理报告。在 Cursor 中split - to - prs 工具可以实现这一点。收益与成本大型 PR 仍然很重要也应该如此。后端的 PR 承担着真正的架构风险新的数据模型、新的 API 接口、信任边界这是审查者应该关注的地方。而消费这些后端接口的前端 PR 几分钟就能审查完。小而专注的 PR 流程顺畅大型 PR 则容易停滞。在这个规模下AI 代理的审查循环也更快。在 Adapt 公司使用 Adapt 本身作为审查者它是一个具有过往工作业务背景的 AI 代理。它会在 PR 打开后几分钟内进行评论并且交流提问、澄清、小修复在十分钟内就能解决。但这只有在 PR 足够小能够快速阅读时才有效一个包含多个问题的 2000 行代码的 PR人类审查者根本无法这样处理。逐步合并也使部署更容易管理。如果出现问题可以回滚一个专注的更改错误跟踪系统会指向这个更改而不是整个合并的代码堆。这些是收益但也伴随着两个成本- 变基操作当审查者要求对一个被其他 PR 依赖的 PR 进行更改时所有依赖它的分支都需要进行变基操作。这种情况并不常见因为审查者通常会关注最上层的 PR但一旦发生会很头疼。保持生成拆分方案的聊天会话打开因为它仍然保存着拆分信息可以重新使用指令来更新上面的分支而不是手动操作。- 拆分并不等同于交付在写这篇文章时那次重构的五个 PR 仍然处于打开状态。一个好的拆分应该使每个 PR 既易于审查又值得单独合并。AI 代理可以帮完成前者而后者取决于决定每个 PR 包含的内容以及团队决定是否合并。PR 停滞不前是因为只完成了前者。即使五个 PR 在同一天合并仍然能获得审查的好处和每个更改的清晰回滚目标但失去了增量交付的优势因为没有任何功能提前交付给用户所有部署一次性完成。适用场景- 适合场景跨后端和前端的多界面功能、在完成之前不知道最终形状的重构以及任何需要猜测问题边界的工作。- 不适合场景必须在生产环境中按顺序进行的迁移和架构更改这种情况下顺序是实际存在的应该提前规划。还有那些有明显拆分点的工作以及第一步永远不能单独交付的功能如果所有内容一次性交付后期分解只能让获得增量审查的好处没有更多的优势。判断方法是如果在编写 RFC 时在还未构建任何东西之前就猜测如何将其拆分成问题那么这段时间可能更适合用来构建。最后会得到更好的答案。已经在几个项目中测试了这种方法效果不错。结构决策仍然需要做出只是当面前有代码时做出这个决策的成本会大大降低。那么在不同的项目中如何更好地运用这种新的工作流程呢