刚刚看到一个邮件服务www.mailbox.my，在他们的官方博客里写了这么一篇文章：《为什么商业软件总是如此臃肿》。作者在创立这家公司之前，在一家大型软件公司任职。对于此事，他在自己创业小软件公司后，结合自己的经历，做了一个对比。当然在我看来，他讲的事情不仅发生在商业软件上，普通软件也有同样的问题。

首先我们需要统一概念，什么算是臃肿的软件？这里我们称那些，使用资源远超过完成工作所需的软件，为臃肿软件。所谓资源，在计算机系统里，指的是CPU时间、内存、I/O和磁盘空间。

生活里，那些臃肿的软件，不仅拖慢工作，还耗尽了电量，甚至迫使你去买性能更强大的电脑。CPU的高使用率直接增加了能源消耗，还导致了硬件不必要的淘汰。

臃肿软件的形成原因可以分为商业原因和技术原因。

商业因素可以从公司发展、结构、运营等角度讲起。

从商业上来说，发布速度对软件是性命攸关的。提前发布，并占据市场份额的软件，优势可以抵消功能或者质量带来的劣势。为了快速开发，开发人员和架构师会采取各种捷径，比如把现有的系统粘在一起，使用简单的算法或内存中数据的次优表示法，以及不优化瓶颈问题。这也就导致了软件效率低下。

现在大多数应用都要适应多平台，比如同时能在不同电脑系统、手机系统、以及网页上运行。只有大公司才有能力给每个平台配置一个专门的团队。那么，流行的替代方式是用一个针对多平台框架的代码库，比如Electron（VS Code使用）或渐进式网络应用（Pinterest和Twitter使用）。这些框架是重量级的，需要一个完整的浏览器和JavaScript引擎来运行，这已经占用了相当多的资源。

从公司结构上来说，自建功能比共享更容易。软件开发通常是多团队合作进行的。自上而下的公司结构，划定了每个经理的任务范围。当一个团队需要某个功能时，把这件事委托给其他团队会带来大量的沟通和计划的消耗，并且会导致你的开发进度依赖于其他团队。即使他们共用一个办公室，团队间的沟通也比在团队中困难得多。团队选择自建大于共享，导致了代码超过必要的范围。

从收购公司的角度来说，随着企业被收购，软件被整合进更大的系统。通常情况下，整合面临着重构成本和进入市场的时间压力。所以整合通常只做最低限度的工作，跳过对内部数据结构或算法的重构或代码修改。在这样一个系统中，数据格式的转换、重复数据及重复处理，都会导致更高的延迟，最终每个人都会受到高资源消耗的影响。同样的事也发生在与其他软件合作时。

从维护合同角度来说，软件行业经常会以合同形式保障一些客户对旧功能的依赖。在大多数公司里，这意味着不允许对旧的系统有任何修改，技术债也就越积越多。

从多功能角度说，就像前面提到的特定客户也会给软件留下影响。一个受众广泛的软件，总会在其生命周期中积累很多功能。就像word功能非常多，大多数人只会用其中几个功能，但每个特别功能都有自己的一小部分受众。随着代码库变大，错误也会悄悄地出现，变得更难修复。因为成本/效益变得更差，或者成本太高，管理层不会分配时间等原因，开发人员变得更不愿意进行重构。这些功能也将消耗更多资源。

软件开发的因素包括从开发需求，到迎合运营和商业行为所做的让步。

一个项目的编程语言和框架的选择大多是基于这些因素：工程师的可用性、潜在的开发速度、与其他系统集成的容易程度、编写扩展程序的难易程度。而很少有人会依据生成的软件的运行速度来决定编程语言。在上述标准中得分较高的语言有：

    JavaScript/Web Stack作为唯一一种可以移植的客户端的脚本语言，流行到让它的解释器JavaScript引擎，成为浏览器的一部分。虽然它是一种解释型语言，但广泛的优化和对JIT的研究使其速度越来越快。但内存要求仍然相当高。

    Python这是一种快速编程的伟大语言，但速度相当慢，而且相对来说内存不足。

    相比之下，像Rust或C++这样的语言往往能产生相当高效的软件，但开发速度明显较慢，而且能产生高质量软件的工程师较少。

当然，语言只是一个因素，用任何语言都有可能写出臃肿的软件。

复杂性和抽象性也会造成软件臃肿。Donald Knuth有句名言"过早的优化是万恶之源"。我更愿意把复杂性看作是万恶之源。过早的优化会引入更多的复杂性，这一点已经被涵盖了。但复杂性也涉及到其他问题。

    软件必须遵守的所有技术标准（网络浏览器就是最好的例子）

    可用功能的数量

    为支持未来的更新，而过度设计的软件

复杂性常常（但不总是）会导致软件的臃肿。例如，增加第二种算法，使一个特殊情况下的运行速度提高一个数量级，这将增加复杂性和磁盘占用率，但降低CPU消耗和内存积分。

没有时间编写更好的代码也是一种可能。在很多公司中，功能开发胜过优化、重构或删除遗留代码。在许多情况下，这是有商业意义的，因为客户并不像他们那样关心硬件要求，而是关心功能。然而，随着许多工作负载转移到云端，这一点不再适用，因为提供数据库解决方案的云提供商承担了运营成本，在运行非臃肿的软件方面有既得利益。

商业软件尤其需要易于支持，这也是日志的由来。通常日志在客户占用的服务器上运行，而开发者只得到用于分析的错误日志。因此，一个长期运营的软件可能积累起很多日志。在最好的情况下，这种臃肿只会影响二进制文件的大小，而不会影响内存消耗和运行时性能。

商业软件为了覆盖更多种问题，通常需要大量的代码来处理所有的极端情况，这样有弹性的软件可能会变得非常臃肿。与日志类似，良好的代码实践可以减少这对运行时间和内存消耗的影响。

商业软件必须满足各种法律要求，其中最重要的是可访问性。这是一个必须具备的功能，会导致更多的代码，通常也会导致更高的资源消耗。开源项目经常避免处理这些要求。

总结

归根结底，商业化是导致软件臃肿的主要因素。对商业公司来说，要做出正确的权衡是非常困难的，一个在短期内正确的权衡可能在长期内是有害的。例如，快速发布的臃肿软件可能会快速占据市场，但后期要花很多成本弥补技术债。然而晚发布的软件，可能连占据市场的机会都没有了。所以大多数公司还是考虑尽早发布，以及尽快更新功能，而不是修复臃肿。

幸运的是，不受这种约束的开源项目，往往为企业产品提供了很好的替代品。参考链接的AlternativeTo网站指明了一些常见软件的替代品。

参考链接

Why (Enterprise) Software Is Bloated · The mailbox.my Blog https://www.mailbox.my/blog/posts/why-enterprise-software-is-bloated/

Node js vs C++ g++ - Which programs are fastest? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html

C++ g++ vs Python 3 - Which programs are fastest? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html

AlternativeTo - Crowdsourced software recommendations https://alternativeto.net/