软件不是工厂

很多人都在谈论软件工厂——黑暗的，光明的......见鬼，我也一直在谈论软件工厂。

我甚至自己也在做一些小型版本。任务放进去。有人读取，有人设计，有人实现，有人审核，有人测试，有人部署。在前面加块板子，中间放几个特工，嗯......你就得到一个工厂。

这是一个很有吸引力的想法，尤其是现在：代码生成变得异常快。我们可以并行实现。我们可以让专业代理审查其他代理。我们可以自动运行测试，自动部署，自动监控生产，并自动将事件反馈到系统。

传送带几乎可见，非常诱人，因为我们建造一次它，就能看到它产生成果，同时观看、喝咖啡或睡觉。

而且因为我喜欢自动化，显然我的第一反应是：我们能做到多远？它真的能在没有我的情况下完成工作吗？没有监督？

但最近工厂的比喻让我有些困惑。

因为我们到底在这里生产什么？工厂到底是什么?..

工厂非常擅长生产我们已经理解的东西

想象一家生产椅子的工厂。

在我们开始优化生产之前，我们已经做出了一个相当重要的决定：我们知道需要椅子，并且知道在一定公差下椅子应该是什么样子。我们知道哪些部件放进去。

我们可以测量这些部件是否正确。我们可以提高这些部件在工作站间移动的速度。我们可以减少缺陷。我们可以发现瓶颈。

显然，真正的制造远比这复杂得多，但基本关系依然成立：你知道自己想生产什么，然后优化如何生产它。

软件很奇怪，因为很多时候会有意外的建造是我们发现自己想要建造的东西的方式。

我们实现一个功能来看看用户是否真的想要，然后与某个系统集成，但文档说的是一件事，现实却不可避免地会说稍有不同，我们构建了版本A，查看它（或者说给用户看），然后说“不，不是这个。”

有时开发的产出是软件。

有时输出简单地为：好了，现在我们更好地理解了问题。

如果是这样，把每次迭代都当作低效的最终产品尝试，就忽略了迭代的初衷。

这让“浪费”这个概念变得有趣

工厂讨厌不必要的变化：标准化组件和工艺。减少不必要的流动和缺陷。让输出变得可预测。

而且很多软件开发也绝对应该这样运作。

我希望每个开发者都发明自己的部署方式吗？- 天哪，绝对不。

我希望我们每周都花三个小时手动做一套流程完全一样的事吗？- 不想。

我希望工程师亲手写第47个基本相同的配置文件吗？因为软件开发是工艺?

请不要。

软件有一个椅子没有的可怕特性

离开工厂的椅子通常不会转身走回去，然后连接到装配线。软件会。我们生成的每一段代码都成为系统的一部分，下一段代码必须与之对应。

一开始显而易见的瓶颈是写代码——所以你自动化了更多实现。然后突然你没时间好好审查所有内容。然后你可以自动化更多审核。太好了。

现在瓶颈可能是决定什么东西值得被开发。“品味才是关键”。你可以一直追逐系统里的瓶颈。说实话，这基本上就是我的爱好......

但如果在普通工厂里，生产速度超过下一个工位，会导致库存在工位间堆积，而在软件中，多余的产出不会只是存放在仓库里。它增加了环境的复杂性。

你添加了一个服务。很好，现在未来的每次更改都可能需要考虑这个服务。

你加个抽象，也许接下来的十次变化会更容易。也许会让变化更难。我们拭目以待。

你添加了另一个依赖、另一个API、另一个配置选项、另一个代理、另一个仓库、另一个数据库、另一个巧妙的框架，它将“简化一切”。

所有这些都成为下一个开发者——无论是人类还是智能体——必须理解的世界。下一次变化意味着更多代码需要搜索，更多行为需要推理，更多交互需要考虑，更多测试，更多可能受影响的事物。

这意味着工厂已经不再是真正的工厂了......它成了一个可怕的自我改造工厂，每一个从输送带上出来的物体都会被固定在机器上。

所以我开始认为，“软件工厂”理念背后的一个危险假设是：

更多代码生成=更多软件生成

我不这么认为。

多不代表更好

我们在理智上知道这一点。每个有经验的工程师都看过删掉4000行代码的PR时，觉得：真是太美了。

没人希望系统有更多的依赖。没人会进入一个十年前的代码库，想：要是这些人实现了两倍的功能就好了。

然而，目前围绕代理发展的巨大兴奋点在于加快我们能够产生变化的速度。

更多的平行特工，完成更多任务，更多的公关......

但每一个变化都是关于系统的假设。每一个被接受的变化都会改变下一个主体需要推理的系统。

这让我怀疑代码生成吞吐量是否其实是个有风险的优化因素。因为被生成的内容参与了生成下一个内容所需的上下文。

自动化无聊的部分

我不认为我们应该完全放弃工厂的想法。我只是觉得我们需要更加谨慎地画工厂墙的位置。可重复的东西，已知的转化，我们已经学到足够多，以至于手动操作不再提供有用信息。

我真不敢相信还需要说这些，但：

自动化那些变得无聊的事情

我不是说情感上无聊。因为自动化就是很诱人（就像我尝试过的那样）。我的意思是信息意义上的无聊.

我们理解它，做过足够多次，输入也足够清楚，甚至预期输出也足够清楚。

另一个是”这样做能教会我什么吗?”.不是技能方面，因为那也很诱人（我们推Kubernetes吧，因为我的简历需要这个）。但就实现这个功能能帮助我更好地理解产品、架构、权衡和下一步吗？

不知道它是怎么构建的，会不会阻止我凌晨3点调试？如果答案是肯定的——不要自动化.

我想要的工厂方向正好相反：

构建环境。运行测试。部署。当风险被理解时更新依赖。生成已知的样板。收集上下文。检查已知约束。好吧，甚至在已知、经过验证的部分实现功能，只是再加一块砖。

做那些人类几十年来抱怨的重复机械操作。

拜托，彻底毁掉它。

但另一部分呢？就是我们还在问这种制度应该存在吗？,为什么会这样？,这个系统到底是做什么的？,我们到底漏掉了什么？,A比B更好吗？

...我不确定提高生产速度在这方面有没有帮助。事实上，可能会让情况更糟。不，它确实会让情况更糟。