软件开发的类比

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

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

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

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

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

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

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

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

希望这对你有帮助！

-Max

分享点击在Facebook上分享（在新窗口中打开） Facebook 点击在LinkedIn上分享（在新窗口中打开） LinkedIn 点击在Hacker News上分享（在新窗口中打开） Hacker News 点击在Reddit上分享（在新窗口中打开） Reddit 点击在Threads上分享（在新窗口中打开） Threads 点击在X上分享（在新窗口中打开） X

1条评论 发表回复

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

联系关于 书籍：《理解软件》 书籍：《代码简洁性》

输入您的邮箱… 订阅

Max Kanat-Alexander 9月17日 通常，解决软件系统问题的方法是分配软件工程师去解决问题。将问题分配给软件工程师的危险在于，他们会编写软件来解决它。当你在软件系统中看到长期未解决的问题时，通常意味着没有人被分配去解决那个具体问题。当你看到不必要的软件被编写时，几乎总是因为软件工程师被分配去解决某个问题，并决定编写软件是解决方法。阅读更多 427分享

Max Kanat-Alexander 7月28日 非常兴奋地宣布，我将在2025年开发者生产力工程峰会上发表主题演讲之一。我将谈论什么造就了伟大的开发者体验。我自1995年以来一直在技术领域工作，从2004年开始几乎全职专注于开发者体验。关于如何使开发者体验变得伟大，有一些基本的、普遍的真理，我将尽力在有限的时间内涵盖尽可能多的内容。希望能见到你。 :) 阅读更多 15013分享

Max Kanat-Alexander 6月27日 我目前认为，AI代理能够成功生成的输出的数量和质量取决于：

模型的质量。
代理的质量。
输入的质量（如提示或其他上下文）。
代理可以独立运行的确定性、客观验证的质量。我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。简单来说，如果你告诉AI做某事，它需要某种方式能够自行验证它做对了。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。这意味着你的测试和验证工具越好，你从模型得到的输出就越好。这不仅仅是测试数量的问题。它们必须是好的测试，具有智能的断言和良好的错误信息。这也意味着代理的成功涉及思考如何将任务分解成可以分别通过自动化测试、linter等进行客观验证的单个部分。需要注意的是，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会表现得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也帮助代理。阅读更多 2710分享

Max Kanat-Alexander 6月4日 技术债务有价值的想法大多是个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内拖慢你的速度。这是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但这根本不是真的。它几乎立即开始产生影响。做正确的事的成本通常是几个小时，也许一天，你几乎总是能立即收回那个时间。也就是说，做对事最终花费的时间通常与做错事花费的时间相同。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本没有为你节省时间！它使得处理变更更加困惑。它使得代码审查时间更长。它在测试期间以更令人困惑的方式失败，需要更长时间来调试。它几乎从不节省你实际的时间。偶尔，你的路径上会有一些如此巨大的“岩石”，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能一次性地交付一个一天的功能。但那只是技术债务决策中极小极小的一部分。这甚至变得更疯狂，因为如果你在过程中一切都做对（你总是重构系统，使其看起来像是为完成现在的工作而设计的），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切都会变得越来越困难，以至于你产生了没有人能移动的“岩石”。复杂性不是某种线性的东西，你可以后来投入线性时间修复。你绝对可能陷入一个如此糟糕的境地，以至于你公司里没有人有时间和专业知识来修复它。这一切感觉如此无辜：“我们就偷工减料一下吧，它会帮助我们满足这个截止日期，”（这个截止日期通常是虚构的，你可以推迟几周而没有任何后果）。“很难弄清楚如何正确地做这个，我们能推迟它吗？”然后砰，很快你发现自己陷入了一个沼泽，一切都变得困难，而且“我们不知道为什么！” 我最后留给你一件事：当我每天直接编码时，我在这方面是完全不妥协的。我基本上无法忍受糟糕的代码——我必须重构它，否则我无法工作。然而，在我整个职业生涯的那部分，我从未错过一个截止日期。阅读更多 13142分享

加载更多

管理同意联系关于书籍：《理解软件》书籍：《代码简洁性》

转到顶部