如何克服防模式"大泥球"?

Question

是什么原因导致一个计算机程序变成一个 大泥球?是否有可能恢复从这反模式？是否有经证明的重构方法，可以适用？

Answer 1

一个大球泥，通常会发生是因为下列之一：

• 变化的要求s-你设计一个方案与一组的要求，即随时间的变化和现在，你可能迎来一个不同的受众谁想要用同样的产品有稍微不同的要求。你烤的那些要求进入同一产品和你结束了一个BBOM.

• 变化中的开发商 -原始的产品已经创建了一套商定的设计和建筑假设它们不完全明显的一套全新的开发者'接管'的产品对于维护或进一步发展。新的开发人员使他们自己的假设，随着时间的推移，产品降解成是一堆不可维护垃圾。

• 无能 -开发人员(他们不知道反模式)，管理(太苛刻、缺乏知识的产品)或者(他们真的不知道他们需要什么).这是难以解决的问题。

有时候，最好的解决办法就是改写的应用程序助的新要求。但这通常是最坏的情况。繁琐的解决办法是停止所有新的发展，开始通过编写一套测试和随后的重新设计和重新构整体的解决方案。这可能需要几年的时间，这取决于产品的大小，虽然。

Answer 2

BBOMs我们遇到了从创建有机，在达尔文的进程。它是这样的：

1. 开始，一系统的创建(不计)和管理不善的记录。

2. 原来资源的继续创造更多的瞄准其他地方，所以不存在，甚至口头历史上的这个"遗留"系统。

3. 新鲜血液带来。这些开发者试图揭露工作的各种系统的部件，但它就像几个瞎子试图理解的大象当一个人有抓尾巴，一个一条腿和一个后备箱。它们作出改变，但从来没有真正感到有信心他们。

4. 在这一方式，一种系统"发展"由盲目的自然选择，但是并行的，这是一个进化的最棘手,unreproducible的错误依然存在，正是因为他们留下的雷达屏幕，直到他们当然表面的客户安装。

Answer 3

我总是将术语（BBOM）归结为代码库，其中“一切都取决于所有东西”。并且很难找到您想要更改的代码，当您进行更改时，您最终必须更改所有地方的内容以使其再次运行。您需要整个代码库才能测试单个更改的类/文件。鲍勃叔叔将此称为早晨综合症（在非循环依赖原则下此处）。

在没有基本依赖控制的情况下，代码库（ahem）将 转移到BBOM中几乎是不可避免的，因为开发人员不能只看到他们的代码而无法完成正在编辑。

Answer 4

在我的情况下，我的软件中的一个元素属于这种模式，大约是两年前的“临时解决方案”，它不断增加新功能（总是紧迫），但要以重写为代价。

如果它不会导致管理上的痛苦，他们没有动力改变它。 “是的，下个月你有空的时候，你可以重写它，但我们只是需要它才能适用于这种情况”。一旦新功能出现，重写就会被遗忘。

我已经解释了两年，它是一段糟糕的代码（暗示其中有一些看不见的错误）。

Answer 5

我唯一一次处理“BBOM”在这种情况下，我们基本上不得不重新审视用户的要求，并从可怕的代码中推断出我们能做什么。与所有BBOM一样，在需要进行一些维护/增强之前，问题通常不会明显。 （在这个商店没有奢侈的代码审查，标准很遗憾地“它做了他们想做的事情吗？”）并且“作者”指的是“作者”。早已不复存在。

在这种情况下甚至不可能进行重构。

Answer 6

来自维基百科文章的相关引言是：

  

程序员控制一个大球   强烈鼓励泥浆项目   研究它并了解它是什么   完成，并将其用作   一套正式的松散基础   精心设计的要求   系统可以取代它。

Answer 7

这可能会对原始问题有所启发。

http://en.wikipedia.org/wiki/Big_ball_of_mud

  

泥球是一个缺乏可感知性的软件系统   建筑。虽然从工程角度来看是不受欢迎的，   由于业务压力和压力，这种系统在实践中很常见   开发商营业额因此他们被宣布为设计   反模式。