软件开发的比喻

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

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

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

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

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

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

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

我希望这有所帮助！

-Max

读者评论

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

其他内容

Max Kanat-Alexander · 11月3日 我很高兴宣布我将在11月20日在纽约市的AI工程师代码峰会上发言。过去几年关于软件工程的未来存在很多不确定性。在本次演讲中，我将讨论我们可以应用的原则，以确保无论发生什么，那个未来对你的业务都是有利的。

希望在那里见到你！

阅读更多 935 分享

Max Kanat-Alexander · 11月1日 从2011年到2015年左右我们停止定期每周会议，我几乎每周都参加Google代码健康小组的周会。这是一个非常棒的会议，有一个核心小组几乎总是参加，加上每周一些一次性参加的与会者，他们希望在他们所在领域获得关于代码质量、测试或重构问题的帮助。

大多数情况下，这个会议作为一个支持小组，为那些关心代码质量并希望在他们所在领域采取行动的人服务。他们会出席，抱怨他们如何关心但难以让别人关心。我们会支持他们，说我们真的很关心，他们应该继续努力，然后他们会回到自己的领域并做出伟大的事情。实际上，令人惊讶的是，那个会议的许多与会者后来成为了Google一些最资深的技术负责人。（关于长期职业成功的一个好提示：如果你专注于做正确的事情，尽管面临反对或困难，从长远来看，这几乎总是对你的职业有利。我们确实在代码健康小组中一次又一次地看到这种情况发生。）

然而，几乎每周，都会有人出现在会议上问我们同样的问题：“我如何客观地测量代码复杂性？”一周又一周，我们会给他们同样的答案：“没有办法做到，请不要这样做。”

这个小组的负责人代表了代码质量和重构领域一些世界上最有经验的工程师，随着时间的推移，我们都得出了相同的结论：代码复杂性测量不起作用。所有尝试制定定量指标（圈复杂度、计算静态分析失败、确定内聚和耦合的算法）都失败了——它们引导团队走向错误的道路，并没有解决真正阻碍开发人员的重要问题。

最终，我意识到为什么这些指标不起作用，而且永远不会起作用。这是因为代码“简单”的定义是：易于阅读、理解和正确修改。那里的“阅读”和“理解”本质上是主观的。只有人类能告诉你某物是否易于阅读。

有些人希望现代的LLMs能够在这方面提供帮助。我愿意在看到时相信这一点，但现在这实际上是所有模型都一致表现糟糕的领域：告诉你是否产生了高质量的输出。它们在发现特定问题并以代码审查的形式提供具体指导方面表现良好。但它们完全缺乏经验丰富的软件工程师在创建真正简单的软件系统方面所具有的判断力。无论你告诉它们多少次“要简单”或“编写好代码”，它们就是无法做到。

所以这仍然是正确的：代码质量本质上是主观的，如果你想理解它，你需要关于它的主观数据。这是我见过的唯一有效的方法。

阅读更多 9118 分享

Max Kanat-Alexander · 10月15日 我很高兴今年在2025年开发人员生产力工程峰会上发表主题演讲之一。我谈到了什么造就了出色的开发人员体验。特别是，这次演讲涵盖了我们在所有开发人员体验工作中试图优化的三个核心事项。我希望它有所帮助！ :) https://lnkd.in/g-AJtJ2b

阅读更多 什么造就了出色的开发人员体验？ lnkd.in 846 分享

Max Kanat-Alexander · 10月13日 为什么Google有如此出色的开发人员体验？它只是在这方面花费了比任何人都多的钱吗？

嗯，是的，如果你累计计算Google基础设施上花费的所有人力成本，Google可能在开发人员体验上花费了比任何人都多的钱。但这实际上不是Google在这方面成功的核心原因，因为Google开发人员体验的早期并没有涉及很多工程师。实际上，它涉及相对较少的一些体面工程师，他们随着时间的推移相当缓慢地构建工具。Google一些最受喜爱的工具最初是由总共三、四个人构建的。

关键是这些工程师被允许专注于开发人员基础设施的基础，无论需要多长时间才能做好。每个人都在朝着开发人员体验的长期全局最大值构建，而不是短期即时需求。非常优秀的工程师被赋予自由，可以问诸如“一个完美的构建工具应该是什么样子”的问题，然后尝试构建它。源代码控制、代码审查、编程语言基础设施、CI、IDE、常用库以及开发人员体验的许多其他部分也是如此。当然，有时我们在这个过程中构建了糟糕的东西，但公司足够关心做好它，以至于我们（通常）最终回去修复它。

Google开发人员体验和速度的关键是对软件工程基础的这种关注。这不仅仅在开发工具团队中，而是贯穿整个公司——Google的工程师比我在任何其他地方看到的更关心代码质量、测试等。

行业其他地方的技术领导者最常犯的错误之一是没有专注于所有这些工程基础。代码库可维护吗？你拥有有效构建可靠、高质量软件所需的基本工具吗？是否有系统确保新软件工程师能够快速上手项目，并随着时间的推移提高他们的技能？等等。

相反，我经常看到领导者坚持在破碎的基础上紧急解决即时问题，没有任何真正在未来解决这些基础的计划。这有点像是一个酒店建造者，看到所有其他酒店都有很棒的顶层套房，然后坚持团队建造一个美丽的顶层套房，而建筑却有裂缝的地基和漏水的管道。修复那个地基可能很困难，但如果你不这样做，你肯定会后悔。

基础有时感觉抽象或不重要，因为它们不是你被要求交付的即时产品。但让我告诉你，如果你想能够交付任何东西，基础才是最重要的。

阅读更多 24443 分享

加载更多

© 2025 版权所有。由 The Fox 提供技术支持。