导致软件过度膨胀的原因是什么？[关闭]

今天，我决定为Creative Sound Blaster驱动程序执行全新安装，因为它们总是在一段时间后开始出现故障。那意味着我必须经历整个清理过程。那花了我将近2个小时。

老实说，我看不出原因吗？尽管Creative（恕我直言）在生产永远无法工作的劣质软件方面绝对是第一名，但膨胀的问题并不仅仅局限于他们。

带有Canon数码相机驱动程序的PC将具有大约10种与各种连接互连的Canon条目。Visual Studio也是一个很好的例子，大约有50个左右的条目可以进行完整安装，并且只有通过完整安装才能修复该问题。当我从VS2k8升级到VS2k8SP1之类的东西时，它甚至破坏了整个操作系统的安装。事实证明5GB的可用空间不足以容纳300Mb的补丁...

因此，这似乎确实是一个普遍存在的问题。如今，几乎每个应用程序通常都包含解包程序，已安装的多个间谍“友人”，驱动程序通常在600Mb左右，包括打印机等的所有内容。

但为什么？是开发人员的错吗？诸如此类的应用程序是梦night以求的支持，如今它们永远无法100％正常运行，而且我所知道的几乎所有用户对于作为USB拇指驱动器/打印机/相机/声卡/浏览器的强制性驱动程序安装后所产生的所有膨胀都非常反感。

从我所知，例如Firefox安装，Nullsoft的NSIS似乎是唯一没有not肿的干净安装系统。干净，几乎基于xcopy的安装没有任何问题。

那么，为什么人们不使用植根于30层互连之上的简单设置和应用程序呢？是因为开发人员懒惰吗？使用代码生成工具？是因为公司强迫重量级应用程序成为用户会喜欢的东西吗？是什么原因造成的，有希望软件有一天能重返基础吗？从头启动新应用程序时，应采取哪些步骤来避免膨胀？

我的猜测是，有人认为很多功能是个好主意。但是，如果很多人都有不同的想法，将它们整合到一个应用程序中，这将使它变得如此复杂。对于大型公司产品，我不会责怪开发人员，在大型公司产品中，应该由产品经理来负责产品中的内容以及如何从各个角度优化产品。

另一个方面是技术债务，在大多数情况下可能无法得到很好的管理，因为它不被认为是对时间的巨大投资。我怀疑新功能和错误修复比重构或其他债务任务似乎更没有直接的商业价值更有意义。如果代码库很旧，那么一组开发人员将有几周的时间清理旧代码？我的猜测不会经常出现。

在战略信函IV：Bloatware和80/20神话中引用Joel ：

[...]有很多重要的原因会导致过时。首先，如果程序员不必担心他们的代码有多大，他们可以更快地发布它。[...]如果您的软件供应商在发货前就停止了，并花了两个月的时间压缩代码以使其缩小50％，那么对您的净收益将是不可察觉的。[...]但是，等待额外两个月的新版本给您带来的损失是可以感觉到的，而不得不放弃两个月的销售的软件公司所遭受的损失则更为严重。

许多软件开发人员都被旧的“ 80/20”规则所吸引。这似乎使很多的感觉：在80％的人使用的20％的功能。因此，您可以说服自己只需要实现20％的功能，并且仍然可以销售80％的副本。

不幸的是，它从来都不是20％。每个人都有一套不同的功能。[...]

当你开始推销你的“精简版”的产品，你告诉人们，“嘿，它的精简版，只有1MB，”他们往往会很开心，然后他们问你，如果它有自己的重要特征，它也没有，所以他们不购​​买您的产品。

其中很大一部分与产品的依赖关系有关。您的操作系统附带了许多用于所有事物的标准库。但是，这些标准库在OS的整个演进过程中具有不同的版本，并且任何通用安装程序都不能假定针对其构建的特定版本实际上将存在于OS中。

因此，完整安装程序将需要包括每个依赖项的正确版本，以确保无论目标计算机上每个依赖项的初始状态如何，所有内容在安装后都能正常运行。对于某些类型的应用程序，例如对于需要部署到Windows XP系统的基于.NET的应用程序，这可能是一个很大的膨胀。

直到最近，我使用过的一个安装程序系统都需要安装每个以前的.NET版本才能部署最新版本，因此这意味着任何.NET 3.5应用程序都需要.NET 1、2、2.5和3的安装二进制文件。排名前3.5。在这种情况下，只有安装程序膨胀。

一种解决方法是Web安装程序，该程序仅下载目标系统上实际上不存在的那些组件-这可能会带来巨大的规模/好处。当然，它确实将您的安装限制为具有Internet连接的系统。

我认为这很大程度上与库代码的层级有关。显然，当您使用一个库时，您不会使用其中的所有内容，因此当您包含越来越多的库时，多余的总和就会增加。

结合这样的事实，即程序员的一个小时的工作成本越来越昂贵，而典型计算机的处理能力/存储到一年前却越来越便宜，您会发现这种方式实际上更具成本效益。

• “我们需要做一些X。让我们使用库$ BIGFATLIBDESIGNEDFORSOMETHINGELSE，因为我在另一个项目中使用了它”
• “我认为我们不再需要此代码部分，但要确保没有任何问题，只需保留它即可。”
• 没有或没有足够的单元测试，这导致
• 没有重构
• 无需跟踪，这些年来这些设置已存储在哪里，所以现在到处都有这些设置
• ...

这是一个恶性循环，绝望周期中的每个人都应受到责备。绝望的一个周期包括以下步骤：

1. 商界人士要求功能features肿。
2. 即使开发人员知道不应该使用这些功能，他们也可以实现这些功能。
3. 客户只为膨胀的功能付费，即使他们只想要产品而不是愚蠢的功能。
4. 商界人士认为，客户需要膨胀的功能。
5. 转到第一步并重复。

你如何阻止它？关于如何做没有简单的答案，但是很显然，为了停止循环，必须打破其中一个步骤。因此，只能由企业，开发人员或消费者采取革命性行动来破坏它。

1. 一位工程师试图优化一个模块，但引入了一些客户问题。然后，他的经理说不。然后，工程师决定在麻烦困扰他之前不要“制造麻烦”。
2. 对于复杂的系统，供应商已经添加了许多补丁程序并修复了数千个错误，以使其在客户环境中稳定。从软件的角度来看，它的质量不高，但是可以工作。没有人想要重写它来再次修复相同数量的错误。
3. 由于向后兼容的原因，即使某个功能在市场上不受欢迎，我们也需要保留该功能。

它总是很懒惰，这就是导致肿胀的原因。（或关于该主题的开篇文章中的泥浆，“泥浆大球”）

例如，在我工作的地方，我们有一个经过精心设计的“旧版” C ++应用程序，客户端与API对话，而API与能够进行DB工作的服务器对话。明智地做到了。最近，我们需要一个附加模块，但是开发人员没有正确实现它，而是决定在.NET中实现它，更糟糕的是，他认为通过API访问数据太困难了（不是，但是...），他会建立数据库连接。直。因此，您会看到这种混乱情况。（并且都得到了TA的同意，他们将“快速”置于“良好”之上）

我以前也看过这种事情-在旧地方，GUI的一小部分是html，因为一些开发人员认为用html编写数据并让GUI显示它是个好主意。因此，一小部分所做的事情与其余部分有所不同。

简而言之，懒惰是不好的，一致性是好的（不管使用什么技术）。我宁愿拥有一个全MFC应用程序，而不是一部分MFC，一部分Winforms和一部分WebGL，以及许多不同的后端体系结构将它们联系在一起。