软件开发的类比
作者：Max Kanat-Alexander
发布日期：2025年3月7日
有时，我需要向非软件开发人员解释软件开发。多年来，我想出了一个类比，可以解释软件开发及其流程。我曾成功用它向一个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
6月27日
我目前认为，AI代理可以成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。
我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。
简单来说，如果你告诉AI做某事，它需要某种方式能够自己验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做了错误的事，这些工具会失败。
这意味着你的测试和验证工具越好，你从模型获得的输出就越好。这不只是测试数量的问题。它们必须是好的测试，具有智能断言和良好的错误消息。
这也意味着代理成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单个部分。
作为说明，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也帮助代理。
阅读更多2310分享
Max Kanat-Alexander
6月4日
技术债务有价值的想法大多是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那根本不是真的。它几乎立即开始。做正确的事的成本通常是几个小时，也许一天，而且你几乎总是立即收回那个时间。也就是说，做对的事通常花费与做错的事相同的时间。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本不会节省你的时间！它使得处理变更更加混乱。它使得代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从不节省你的实际时间。
偶尔，你的路径上会有一些“巨石”如此巨大，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能发布一个一天的功能，一次。但那是技术债务决策中极小的一部分。
这变得更加疯狂，因为如果你在过程中做对一切（你总是重构系统，使其看起来像是被设计成 exactly 做现在做的事），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切变得复合性地更加困难，以至于你生成“巨石”，没有人能移动。复杂性不是某种线性事物，你可以后来回去投入线性时间修复。你绝对可以让自己陷入一个如此糟糕的情况，以至于你公司中没有人有时间或专业知识修复它。
这一切感觉如此无辜：“让我们只是偷工减料，它会帮助我们满足这个截止日期，”（一个截止日期通常是虚构的，你可以推迟几周而没有后果）。“很难弄清楚如何做对这件事，我们可以推迟它吗？”然后砰，很快你发现自己陷入一个沼泽，一切都很难，而且“我们不知道为什么！”
我留给你最后一件事：当我每天直接编码时，我在这方面完全 uncompromising。我基本上无法看坏代码——我必须重构它，否则我无法工作。不知何故，在我整个职业生涯的那部分，我从未错过一个截止日期。
阅读更多12940分享
Max Kanat-Alexander
5月30日
我估计，每看到或被告知一万条坏建议，我才收到一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球的教育大多不教人们思考、研究或确定什么是真的。相反，它教人们记忆和重复事实，其中大多数不重要、不真实或无用。
所以总的来说，我们不应该惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。并非全部如此——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说，人们对事物的意见，无论是在报纸、博客文章、论坛还是其他什么，很少具有那种价值。
那么要点是什么？嗯，最好有某种方式在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说：“它有效吗？”这条数据可靠地帮助你完成某事吗？它100%的时间有效，还是更少？
对于许多帖子，你会发现：这条数据根本不会帮助你做任何事。
阅读更多249分享
Max Kanat-Alexander
5月29日
你对系统所做的任何更改在推出时都会收到某个人的负面反馈。这发生不是因为每个更改有问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能批评新的用户界面，或有某种情感论点关于为什么新东西“糟糕”，但通常他们真的只是对任何更改发生感到不安。这不是什么不寻常的事；它是几乎所有人中存在的一个因素。人们往往有一定的 appetite 对于他们愿意在一段时间内经历多少更改，如果你超出那个，他们会不安。
重要的是识别 when 人们的反馈只是这种“变更厌恶” vs 关于有价值事物的真实反馈。有几种方式可以判断：
- 变更厌恶通常持续3到10天。如果你在推出更改后的前3到10天内从用户那里收到反馈，并且同一反馈没有被大量用户提供，值得考虑用户的响应是否只是变更厌恶。
- 变更厌恶反馈通常是情感的。它可能是侮辱性的。它可能表达为 just 一个意见（“新菜单的颜色丑陋”）vs 一个事实（“我测量了，新工具比旧工具慢10倍。”）。
在管理变更时，你试图避免的是创建如此多的变更厌恶以至于你引起反抗。反抗基本上看起来像如此多的人生气，他们去找你的管理层，他们停止你的工作。当有疑问时，向更少的人推出更小的更改，以较慢的扩展速率。随着时间的推移，你将学习你可以推出多少更改，多快。永远不要做“大爆炸”发布，其中所有用户同时经历大规模更改。
现在，所有这些 said，永远不要将所有反馈归因于“变更厌恶”。通常人们确实有合法的反馈。如果许多人提供你相同的事实反馈，你查看它，他们的反馈有意义，你认为修复它会改进产品，那很可能不是变更厌恶。另外，说“这只是变更厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到了。它确实意味着你不应该与那个人争论或尝试与他们推理，因为他们正在有情感反应，你尝试“逻辑”他们 out of it 不会帮助任何人。如果你认为是变更厌恶，你承认他们，他们只是继续与你斗争，有时你应该只是忽略他们，继续做你的工作。如果他们3天后回来带着更合理的论点，那么你知道它不只是变更厌恶，而且他们可能到那时更有帮助。
阅读更多274分享
加载更多
© 2025 版权所有。由 The Fox 提供支持。
管理同意联系关于书：理解软件书：代码简洁性
转到顶部