糟糕的代码从何而来？探寻软件质量衰退的根源

如今的软件普遍面临代码臃肿、构建缓慢、性能低下和可靠性差等问题。本文深入探讨了这些问题背后的核心原因，并非算法本身，而是连接这些算法的“胶水代码”和基础设施代码的失控。

现代软件的困境

观察当下的软件生态，不难发现一些普遍存在的现象：

• 代码量爆炸：即便功能简单的软件也动辄拥有数十万甚至数百万行代码。
• 脆弱的构建系统：构建过程极其复杂且脆弱，常常需要依赖 Docker 等容器技术来保证环境一致性。
• 漫长的构建时间：一些主流项目（如 TensorFlow）的完整构建可能需要数小时，这与现代计算机的强大算力极不匹配。
• 低下的运行效率：软件运行缓慢，响应迟钝，占用大量内存和存储空间，但其可靠性和功能并未得到相应提升。

这些现象指向一个核心问题：代码质量正在系统性衰退。但这与市场竞争或程序员乐趣无关，关键在于我们未能实现本应达到的工程潜力。

问题不在算法，而在“胶水”

计算机科学在算法领域取得了长足进步。我们对哈希表、堆、排序算法等有了深刻的理解和分析工具。问题的真正症结，在于将所有算法组件粘合在一起的“胶水代码”和系统基础设施代码。

在过去，硬件的严格限制（如 64KB 内存）天然地约束了这类代码的膨胀。而如今，资源限制几乎消失，但我们却没有建立起新的、有效的约束和指导原则来替代它。

程序员的思维模式：一个导航的比喻

编程学习是一个在大脑中构建“过滤器”和“生成器”的过程。初学者尝试各种语法组合，大脑逐渐学习并生成符合特定语言语法的有效代码。经验丰富的程序员则拥有高度规整化的思维模式，其“过滤器”只会产生特定模式的、可预测的代码。

这个过程可以比喻为导航或探索：程序员从一个起点出发，带着一个模糊的目标，在没有地图的情况下，通过尝试和反馈（“dead reckoning”）来寻找目的地。开发过程是路径，最终成果是抵达的地点。

糟糕的代码就如同在探索中彻底迷失——路径迂回浪费，最终抵达的地点也与目标相去甚远。

错误的路标：虚构的“清洁代码”教条

那么，是什麽导致了这种“迷失”？关键在于，塑造程序员思维模式（那个“过滤器”）的指导原则是错误的。

如今，程序员的训练大量来自于大学课程、代码审查、导师指导、Stack Overflow 投票、技术讲座等。这些渠道普遍灌输诸如 SOLID 原则 之类的概念，声称遵循它们就能写出“清洁代码”。

这就像给探险者一个与导航无关的工具（比如一把锤子），却告诉他这是最重要的导航仪。更糟糕的是，整个生态（语言、平台、库）的起点往往就是由这些“迷失”的先行者建立的，后人只能在此基础上继续探索，积重难返。

从虚构度量转向真实度量

我们需要一场彻底的转变：停止讨论抽象的“清洁”，开始衡量真实世界的成本。一个替代 SOLID 的、更合理的思维框架应该是 WARMED：

• Writing (编写成本)：编写代码需要多少时间？
• Agreeing/Arguing (达成一致的成本)：团队需要多少沟通和争论才能确定方案？
• Reading (阅读成本)：理解现有代码的难度和所需时间？
• Modifying (修改成本)：添加功能或修复缺陷的难度和所需时间？
• Executing (执行成本)：代码在用户设备上的运行效率和资源占用？这是最直接的用户成本。
• Debugging (调试成本)：定位和修复问题的难度和所需时间？

所有这些成本都可以被测量或评估。我们的目标应是尽可能地降低这些成本的总和。任何编程实践、模式或原则的主张，都必须能够论证它如何优化这些可衡量的指标，而不是空谈“清洁”。

结论：坏代码源于衡量标准的缺失

糟糕的代码并非源于某种神秘或不可避免的力量。其根源在于，我们作为一个行业，停止衡量和关注真正重要的实际指标，转而用一套虚构的、脱离现实的“清洁代码” ritual（仪式）来训练程序员的思维模式。

这导致一代代开发者使用的“导航工具”根本无法指引他们走向真正优秀的目的地——高性能、可维护、开发高效的系统。

解决之道在于文化的转变：在讨论技术、设计模式、编程语言特性时，我们必须将其与真实的、可衡量的成本（WARMED）联系起来，并用数据和事实来支持我们的决策。只有这样，我们才能停止生产坏代码，开始实现软件工程本该拥有的潜力。