优秀的工程师在构建之前会进行计划。我成长过程中看到的工作流程是：写一个RFC描述功能，将其拆分成更小的问题，然后依次构建它们，每个问题通常会阻塞下一个。在编写任何代码之前，工作的结构就已经锁定。这是合理的。这使得代码审查可以管理，也避免了大范围的合并。它还要求你在对问题了解最少的时刻做出最关键的结构决策。在你还未构建任何东西之前，你实际上是在猜测：哪个部分是可分离的，每个部分的复杂程度如何，步骤3是否会迫使你重新思考步骤1。有时你是对的，但往往不是，步骤1会被丢弃。你在构建时学到了东西，但如果首先构建整个东西，你会学得更快。我们付出了这个代价是有充分理由的：否则就是构建所有东西然后再手动理顺，而整理一周的工作比提前规划要困难得多。提前决定边界从来不是为了简化构建。这是为了使审查成为可能，而这是到达那里的唯一可承受的方法。这里发生了变化的部分是：三件事情的成本显著降低了。构建：一个AI助手可以在几小时，有时几分钟内将一个明确的问题转化为可工作的代码。设计：你可以快速审视一个计划并以对话的速度重新塑造它。而这里最重要的一点，解构一个完成的分支：将一周的复杂工作拆分为一系列小的PR曾经是工作中最乏味的部分，这正是我们避免它的原因。现在它成为了一个提示。有两件事情的成本并没有下降。首先是代码审查的判断部分。代理使机械性的部分（一致性、琐事、明显的错误）几乎变得免费，但它们并不能解决微妙的正确性或与之相关的问题：这个改变适合它所在的位置吗？这个端点的形状会在六个月后造成问题吗？一个机器人批准你的PR并不等同于你理解代码，如果你没有编写代码，阅读它是你必须掌握代码的方式。狭窄的PR使阅读成为可能。第二个是产品验证。运行这个东西并决定它是正确的构建内容仍然是缓慢的。新的地方在于有整个功能足够早地运作，可以在任何人阅读其中一行之前展示给某人。所以停止为了避免一个不再存在的成本而预先决定边界。我的工作流程现在是这样的：深入探讨计划，直到其包含真实的决策；在任何代码之前提交规范，当设计是新颖时；广泛构建，在进行中提交保存点；在任何人阅读代码之前进行演示和迭代；在代码揭示的边界处拆分为PR；合并，最后进行清理：纯删除在自己的最终PR中；设计仍然优先。需要明确的是：这不是“跳过规划，开始编码”。在我接触编辑器之前，我有一个计划，每个功能都以探讨开始。我运行grill-me，这是一个技能，它会通过对抗性轮次面试你关于你想法的问题，直到形成真实的决策。如果API调用失败，后备方案是什么？我在所有事情上都运行它，甚至是小的变化，它不断浮现出我不知道的空白。当设计是新颖的，计划成为在任何代码之前提交的规范。在不同的项目上，第一PR是一个文档：功能是什么，它将如何工作，信任边界在哪里。它在任何实现存在之前几天就进行了合并，以便团队可以首先提出反对意见。绝对不会被提交的就是拆分为PR的过程。先决定构建什么，再决定如何切分。广泛构建一旦设计确定，我就开始构建。我通常分步骤工作，但不在每一个步骤结束时打开PR并等待审查。一切都保持在一个分支上，直到它的端到端工作，跨越所有阻碍的文件。虽然会有提交，但对其他人来说它们并不是里程碑。它们是保存点：一个概念被证明，或者我即将尝试一些冒险的东西，想要有个可以拉回来的绳索。最近完成的一个重构在单日跨越数十个文件中达到了十几个提交，且附有操作性信息。路标使我可以看到我去过哪里，而不是给审查者的故事。这部分让一些工程师感到不安，我理解原因：git历史记录应该是记录。但是，这个历史从未成为记录。最终的PR是在主分支上新切的，构建分支是你随意丢弃的草稿纸。两个时间上分开的观众，我和审查者，保持分开让你可以优化整体。代码阅读之前进行演示一旦工作达到一个好的状态，我便停止并展示它。不作为PR或代码审查，而是通过Slack发送一个简短视频，或者在更改需要点击时进行预览部署。在单个代码审查开始之前，来自将使用该软件的人的反馈是在工作软件上得到的。现在审查是昂贵的，因为便宜的部分已经自动化了。在审查时发现你构建了错误的东西（混乱的UI模式、一个在几个月后可能有问题的端点形状），是多么令人沮丧。