是什么导致计算机程序变成大泥球？是否有可能从这种反模式中恢复？是否有可以应用的经过验证的重构方法？
问问题
3437 次
7 回答
26
由于以下原因之一，通常会出现大泥球：
需求变更- 您构建具有一组需求的解决方案，随着时间的推移会发生变化，现在，您可能正在迎合想要使用相同产品但需求略有不同的不同受众。您将这些要求融入到同一个产品中，最终得到一个 BBOM。
开发人员变更- 原始产品是由一组开发人员创建的，具有某些设计和架构假设，这对于“接管”产品以进行维护或进一步开发的一组全新开发人员来说并不完全明显。新开发人员做出自己的假设，随着时间的推移，产品退化为一堆无法维护的垃圾。
无能- 开发人员（他们不知道反模式）、管理层（要求太高，缺乏对产品的了解）或用户（他们并不真正知道自己需要什么）。这很难解决。
有时，最好的解决方案是简单地重写应用程序以满足新的需求。但这通常是最坏的情况。繁琐的解决方案是停止所有新的开发，首先编写一组测试，然后重新设计和重新构建整个解决方案。不过，这可能需要数年时间，具体取决于产品的大小。
于 2009-06-23T02:50:01.513 回答
8
我遇到的 BBOM 通常是在达尔文过程中有机地创建的。它是这样的：
最初，创建（未设计）一个系统并且记录不充分。
原始资源继续在其他地方创造更多的破坏，因此这个“遗留”系统甚至没有口述历史。
新鲜血液被引入。这些开发人员试图揭示各种系统部分的工作原理，但这就像几个盲人试图理解大象，一个抓住尾巴，一个抓住腿，一个抓住象鼻。他们做出改变，但从来没有真正对他们有信心。
通过这种方式，一个系统通过盲目的自然选择“进化”，但与此平行的是最难处理、不可复制的错误的进化，这些错误之所以持续存在，正是因为它们一直在雷达屏幕下，直到它们在客户安装时出现。
于 2009-09-30T14:40:02.840 回答
2
我总是将术语（BBOM）归因于“一切都取决于一切”的代码库，并且很难找到要更改的代码，并且当您进行更改时，最终不得不彻底更改让它再次工作的地方。您需要整个代码库才能测试单个更改的类/文件。鲍勃叔叔将此称为“综合症后的早晨”（此处根据非循环依赖原则）。
在没有基本依赖控制的情况下，代码库（咳咳）转变成 BBOM 几乎是不可避免的，因为开发人员只能看到他们当前正在编辑的代码，无法做到这一点。
于 2009-09-30T18:10:24.283 回答
2
就我而言，我的软件的一个元素正在落入这种模式，大约两年前，它不断地添加新功能（总是紧急），但以牺牲重写为代价。
如果它不会引起管理上的痛苦，他们就没有动力去改变它。“是的，下个月有时间的时候，你可以重写它，但我们现在只需要它来处理这个案例”。一旦新功能出现，重写就会被遗忘。
两年来我一直在解释这是一段糟糕的代码（这意味着其中存在看不见的错误）。
于 2013-10-09T10:01:58.433 回答
1
回答你的维基百科文章的相关引述是：
强烈鼓励控制一个大泥球项目的程序员研究它并了解它完成了什么，并将其用作一个松散的基础，为一个可以替代它的精心设计的系统的正式需求集。
于 2009-06-23T03:00:04.190 回答
1
唯一一次我不得不处理“BBOM”场景时，我们基本上不得不与用户重新审视需求，并从可怕的代码中推断出我们能做些什么。与所有 BBOM 一样，在需要进行一些维护/增强之前，该问题通常不会变得明显。（这家商店没有奢侈的代码审查，可悲的是，标准是“它做他们想做的事吗？”）而且“作者”早已不复存在。
在这种情况下，重构甚至是不可能的。
于 2009-06-23T02:41:18.317 回答
0
这可能会对最初的问题有所帮助。
http://en.wikipedia.org/wiki/Big_ball_of_mud
一个大泥球是一个缺乏可感知架构的软件系统。尽管从工程的角度来看是不可取的，但由于业务压力和开发人员流动性，这种系统在实践中很常见。因此，它们被宣布为设计反模式。
于 2009-06-23T02:42:06.740 回答