“软件工程”并非真正的工程

背景

这篇文章最初发布于 Hacker News，标题为“"Software Engineering" Is Not Engineering”，更新日期为 2005 年 3 月 8 日。作者长期参与关于“软件工程”方法的辩论，深感困惑：为什么关于“正确”开发方式的强烈观点层出不穷，却缺少客观的比较方式来平息争论。他通过对比科学、工程学与数学的本质，试图解释软件设计难以被客观评估的根本原因。

核心内容

作者指出，“计算机科学”并非严格意义上的科学，“软件工程”也并非真正的工程。科学依靠可重复的实验和客观证据来验证假设，工程学则是“应用科学”，其设计必须受物理和化学定律约束。例如，桥梁设计可以通过模拟现实环境进行测试，如果最终失效且非建造或材料缺陷，则工程设计的缺陷无可推卸。

但软件设计在很大程度上缺乏这种与现实世界的绑定。虽然软件有明确的需求（如输入/输出、运行时约束），但满足这些需求的技术和范式往往“图灵等价”——只要给足时间和资源，任何方法都能实现算法。这意味着“能否交付正确结果”本身不是一个区分因素，几乎所有主流方法都能做到。因此，常见的争论焦点（如速度、开发者生产力）难以通过客观度量解决。

作者进一步假设：软件设计更像数学，而非工程。数学不受物理世界固有法则的束缚，可以创造近乎无限的模型，只需保持内部一致性。软件同样可以构建虚拟现实——从简单的物理模拟到社会互动游戏（如《模拟人生》），甚至利用遗传算法模拟达尔文自然选择。软件的无限灵活性使得“客观现实”在软件内部不存在：设计者可以任意定义规则，然后按“运行”按钮观看结果。

这种灵活性正是客观评估软件设计近乎不可能的根本原因。作者比喻道：我们就像一群精神病人争论谁是真正的拿破仑——在软件空间里，我们都可以成为拿破仑。问题不在于我们还没学会如何度量，而在于我们可以随意制造“现实”。今天你是圣诞老人，明天是克利奥帕特拉。

那么，面对同一问题的多种设计路径，哪种“更好”？一种可能的答案是“也许无所谓”：只要黑盒正确工作，何必关心内部？但内部之所以重要，是因为不同程序员需要维护或修改他人代码。如同“上帝”度假后，接替者需要理解世界如何运转才能维持运行。人类有理解能力的限制，搞清他人代码需要时间和金钱。因此，约定俗成的惯例有助于沟通，但问题在于：不同惯例之间是否固有优劣？这仍然难以判定。

关键要点

• 软件设计缺乏工程学科特有的“现实约束”：没有物理或化学定律作为客观基准。
• 所有图灵等价的方法都能满足基本功能需求，因此“能否工作”不是区分优劣的标准。
• 争论中常见的性能指标（如速度、开发者生产力）存在太多变量，难以客观比较。
• 软件更像数学：可以构建任意内部一致的虚拟世界，不受现实物理法则限制。
• 这种无限灵活性导致软件内部没有“客观现实”，所有设计都可以自圆其说。
• 软件维护需要理解他人构建的“世界”，但不同程序员有认知局限，因此需要约定俗成的惯例。
• 各种惯例之间的优劣无法通过客观实验验证，只能依赖主观经验或社区共识。

意义与影响

这篇文章深刻揭示了软件工程领域长期存在的“方法论之争”背后的本质困境：软件设计的核心不是工程学意义上的“与物理现实妥协”，而是近乎无限的创造性。这解释了为什么敏捷、瀑布、微服务、单体等架构的争论往往无法通过实验彻底解决——它们往往都能满足需求，优劣更多取决于具体情境、团队习惯和维护成本。

文章提醒我们，不应盲目模仿传统工程学（如土木工程）的评估方法，因为软件缺乏“客观现实”的基准。同时，它也指出“惯例”虽然必要，但不应被神化。对于软件从业者而言，承认设计选择的主观性、重视沟通和可维护性，比追求“唯一正确方法”更为实际。此外，人工智能等领域的评估虽有连续度量（如准确率），但“当前最佳”并不等于“绝对正确”，仍需保持谦逊。

整体而言，该文为软件开发的方法论争论提供了一个清醒的视角：与其争论谁才是“真正的拿破仑”，不如承认在软件世界里，我们都可以成为拿破仑——前提是做好文档和约定，让后来者能理解我们所创造的世界。