建造宽阔，运输狭窄

优秀的工程师在建造之前做好计划。我从小到大看到的工作流程：编写一个描述功能的 RFC，将其分成更小的问题，然后构建它们，每个问题通常都会阻碍下一个问题。在一行代码出现之前，作品的结构就被锁定了。这是合理的。它使代码审查易于管理并避免大爆炸合并。它还要求您在对问题了解最少的时刻做出最关键的结构性决策。在构建任何东西之前，您会猜测：哪些部分是可分离的，每个部分有多复杂，第 3 步是否会迫使您重新考虑第 1 步。有时您是对的。通常情况下，你不是这样的，所以第 1 步就被扔掉了。你在构建它时学到了一些东西，但如果你先构建整个东西，你会学得更快。我们支付这笔费用是有充分理由的：另一种选择是构建所有内容并手动解决它，而解决一周的工作比提前计划更困难。预先确定边界从来不是为了让构建变得更容易。这是为了让审查成为可能，而且这是实现这一目标的唯一经济实惠的方式。这就是改变的部分。发生了什么变化 三件事变得更加便宜。构建：人工智能助手在几小时甚至几分钟内将一个明确的问题转化为工作代码。设计：您可以询问计划并以对话速度重新制定计划。这里最重要的是分解一个已完成的分支：将一周的混乱工作分解为一系列小的 PR 曾经是工作中最乏味的部分，这正是我们避免它的原因。现在是提示。有两件事并没有变得更便宜。首先是Code Review的判断部分。特工们使机械部分（一致性、缺陷、明显的错误）几乎免费，但他们没有解决微妙的正确性或围绕它的问题：这种变化是否属于它所在的位置，这个端点形状是否会在六个月后受到损害。机器人批准你的 PR 与你理解代码不同，如果你没有输入代码，阅读它就是你拥有它的方式。狭隘的 PR 使这种阅读成为可能。二是产品验证。运行这个东西并决定它是正确的构建仍然很慢。新鲜的是让整个功能尽早发挥作用，在任何人阅读其中一行之前向其他人展示。因此，停止预先确定边界以避免不再存在的成本。我的工作流程现在看起来像这样： 烧烤计划，直到其中有真正的决定 当设计新颖时，在任何代码之前提交规范 构建范围，在任何人阅读代码之前提交保存点 演示并迭代 沿着代码显示的边界拆分为 PR 合并，最后清理：在其最终 PR 中进行纯粹删除 设计仍然首先要明确：这不是“跳过计划并开始编码”。在接触编辑器之前，我有一个计划，每个功能都从审问开始。我会进行“烧烤”，这项技能会在对抗性回合中采访你的想法，直到做出真正的决定。如果 API 调用失败，后备措施是什么？我对所有事情都运行它，包括小的变化，它不断地出现我不知道的差距。当设计新颖时，计划就成为在任何代码之前提交的规范。在另一个项目中，第一个 PR 是一份文档：功能是什么、它将如何工作、信任边界在哪里。它在任何实施出现之前几天就合并了，因此团队可以先推迟。永远不会被提交的是分解为 PR。在构建之前决定构建什么；之后决定如何切片。广泛构建 一旦设计确定，我就开始构建。我经常按步骤工作，但我不会在每一步都停下来打开 PR 并等待审核。所有内容都保留在一个分支上，直到它端到端地工作，无论任何文件都在其中。承诺发生了，但对于其他人来说它们并不是里程碑。它们是保存点：一个概念已被证明，或者我正要尝试一些冒险的事情并想要一根绳子拉回来。我最近完成的一次重构在一天之内对数十个文件进行了十几次提交，并带有操作消息。航点让我可以看到我去过的地方，而不是评论者的故事。这是让一些工程师感到不舒服的部分，我明白为什么：git 历史应该是记录。但这段历史永远不会成为记录。最后的 PR 是从 main 上新鲜切下来的，构建分支是你扔掉的草稿纸。两个受众在时间上分开，我和审阅者，将他们分开可以让您针对两者进行优化。在任何人阅读代码之前进行演示 一旦工作完成，我就会停下来展示它。不是 PR 或代码审查，而是 Slack 中的短视频，或者预览部署（如果需要单击更改）。在单个代码审查开始之前，将使用该软件的人员对可用软件的反馈。现在审查很昂贵，因为便宜的一半是自动化的。在审查时发现您构建了错误的东西（令人困惑的 UI 模式，一个端点形状