软件开发的类比

作者：Max Kanat-Alexander
日期：2025年3月7日

有时，我需要向非软件开发人员解释软件开发。多年来，我想出了一个类比，可以解释软件开发及其流程是什么样的。我曾成功用它向一个9岁的孩子解释软件开发，包括网络安全等高级概念。我觉得其他人也可能从中受益，所以分享如下：

想象你生活在一个没有计算机的世界。你是一家定制汽车工厂的老板，人们可以在纸上写下他们想要的任何汽车，你的工厂会为他们制造。然而，这些汽车不是由人类建造，而是由特殊的机器人建造，这些机器人可以阅读并遵循指令（但不会自己思考）。

机器人知道如何建造汽车的方式是，有一本特殊的指令书，描述了如何建造每个部件，以及如何将这些部件组装成任何人可能想要的任何汽车。这本书非常庞大——有10万页的精确指令，详细说明了机器人需要执行的每一步，考虑到机器人在建造汽车时可能遇到的任何情况。（例如，如果其中一个机器人在建造部件时坏了怎么办？如果工厂用完了他们正在建造的部件的材料怎么办？如果客户要求组装两个以前从未有客户要求过的部件，而指令书中没有如何做的说明怎么办？等等——你能想象的每一种可能情况。这就是为什么这本书如此之长。）

显然，一个人不可能创建一本10万页的指令书。所以这本书是由1000人共同编写的，所有人都在同一本书上合作。有些人编写如何建造汽车发动机的指令，其他人编写如何建造车门的指令，等等，覆盖汽车的每一个部件和每一种组合方式。书中的所有指令都必须彼此“一致”——例如，如果我建造一扇门，它必须能够连接到汽车的车身。如果我建造轮胎，它们必须适合车轮。所以这本书的所有作者不断合作，确保书中的所有指令能够正确协同工作。

随着新类型的汽车部件出现，必须编写新的指令。当作者发现机器人可能遇到的新情况时（“哦，我们没意识到下雨时有些部件会生锈！”），他们必须更新书中的指令。换句话说，这本书不仅需要编写一次，实际上还在不断变化。事实上，保持这本书更新的工作几乎总是比编写新指令的工作更多。

如果这听起来像是一个不可能解决的问题，别担心。没有一个人能理解整本书。所以如果你对这个问题感到不知所措，那是正常的！世界上每个人都对这个问题有同样的感觉。这是10万页不断变化的指令。那么我们如何做到呢？我们制定关于如何编写这本书的规则。例如，我们说“门总是以相同的方式连接到车身”。就像，门总是有相同类型的钩子连接到车身，而车身总是有相同的位置让这些钩子插入。这样，无论你建造什么门或什么车身，它们总是能配合在一起。现在我们不必再考虑那个问题了。我们制定许多这样的规则，这样每个编写这本书的人都可以安全地处理他们的部分，而不必担心他们通过更改关于车轮或发动机的一条指令就会破坏整个汽车。只要每个作者遵循规则，他们可以更改书中的任何内容，而整个汽车将继续工作。这限制了我们可能建造的汽车类型，但它使得解决问题成为可能，否则是不可能的。

这些作者，编写和维护这本书的人，就是软件开发人员。他们遇到的问题几乎与软件开发人员和开发团队遇到的问题相同。例如，你如何知道你编写的指令实际上有效？当有新的人开始在这本书上工作时，他们如何学习规则？当规则太多以至于作者无法记住所有规则时会发生什么？作者如何了解客户想要建造的新汽车和新汽车部件？你可以使用这个类比向任何人解释软件开发的所有流程、问题和原则。

我希望它有所帮助！

-Max

评论

Filis Futsarov 说：2025年3月7日上午5:03
哦！！我很高兴我一直使用那个类比 :))

回复 留下回复取消回复

其他内容摘要（非文章主体部分）

• 关于AI代理输出：Max认为AI代理的输出质量和数量取决于模型质量、代理质量、输入质量（如提示或其他上下文）以及代理可以独立运行的确定性、客观验证的质量。他强调验证是关键，例如通过测试、linter等工具确保输出正确。
• 技术债务：Max认为技术债务有价值的想法大多是神话。糟糕的软件工程决策会在几小时、几天或几周内拖慢进度，而做正确的事通常只需几小时或一天，且时间很快收回。切割角落几乎从不节省时间，反而增加混乱和调试时间。
• 建议质量：Max估计每看到或听到一万条坏建议才有一条好建议。互联网充满坏建议，因为文明如此，教育大多教人 memorization 而非思考。他建议通过“它是否有效？”来评估信息的重要性或有用性。
• 变更管理：任何系统变更都会收到负面反馈，因为用户习惯现有方式，不喜欢变化。区分“变更厌恶”（通常持续3-10天，情绪化）和真实反馈很重要。避免大规模变更，逐步 rollout 以减少抵触。