Design patterns 如何克服“反模式”；“大泥球”；？

是什么导致一个计算机程序变成一个程序？有可能从这种反模式中恢复吗？有没有经过验证的重构方法可以应用？

我唯一需要处理“BBOM”场景的时候，我们基本上必须与用户一起重新审视需求，并从可怕的代码中推断出我们可以做什么。与所有BBOM一样，在需要进行一些维护/增强之前，问题通常不会显现出来。（这家商店没有奢侈的代码审查，标准是“它能做他们想要的吗？”），而“作者”早已不见了

---

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

这可能会对最初的问题有所帮助

一个大泥球是一个软件系统，它缺乏可感知的 建筑学虽然从工程的角度来看是不可取的， 由于业务压力和 开发商营业额。因此，它们被宣布为设计 反模式

---

由于以下原因之一，通常会出现大泥球：

• 需求变更s-您用一组需求构建了一个解决方案，随着时间的推移，这些需求会发生变化，而现在，您可能正在迎合不同的受众，他们希望使用具有稍微不同需求的同一产品。您将这些需求烘焙到同一个产品中，最终得到一个BBOM

• 开发人员的变更-原始产品由一组开发人员创建，具有特定的设计和架构假设，这些假设对于“接管”产品进行维护或进一步开发的全新开发人员来说并不完全明显。新开发人员做出了自己的假设，随着时间的推移，产品会退化为一堆无法维护的垃圾

• 不称职——开发者（他们不知道反模式）、管理层（要求太高，缺乏产品知识）或用户（他们不知道自己需要什么）。这很难解决

---

有时，最好的解决方案只是根据新的需求重写应用程序。但这通常是最坏的情况。繁琐的解决方案是停止所有新的开发，从编写一组测试开始，然后重新设计和重新构建整个解决方案。不过，这可能需要几年时间，具体取决于产品的大小。

维基百科文章中回答您问题的相关引用如下：

控制一个大球的程序员 大力鼓励开展泥浆项目 研究它，了解它是什么 完成，并将其用作 一套正式的 对设计良好的系统的要求 可以取代它的系统

---

我遇到的BBOM通常是在达尔文的过程中有机地创建的。事情是这样的：

最初，一个系统是创建的（不是设计的）并且没有很好的文档记录

原始资源继续在其他地方创建更多的havok，因此这个“遗留”系统甚至没有口述历史

新鲜血液进来了。这些开发人员试图揭示各种系统部件的工作原理，但这就像几个盲人试图理解大象一样，一个抓着尾巴，一个抓着腿，一个抓着鼻子。他们会做出改变，但从来没有真正的自信

通过这种方式，一个系统通过盲自然选择“进化”，但与之平行的是最难处理、最不可生产的缺陷的进化，这些缺陷之所以持续存在，正是因为它们一直在雷达屏幕下，直到它们在客户安装时出现

---

我总是将术语（BBOM）归因于一个代码库，在这个代码库中，“一切都取决于一切”，很难找到您想要更改的代码，当您确实进行更改时，您最终不得不到处更改内容以使其再次工作。为了测试单个更改的类/文件，您需要整个代码库。Bob叔叔称之为晨后综合症（根据非循环依赖原则）

---

在缺乏基本依赖性控制的情况下，代码库将（嗯哼）转化为BBOM几乎是不可避免的，因为开发人员只能看到他们当前正在编辑的代码，这是无法做到的。

在我的情况下，我的软件中有一个元素属于这种模式，大约两年前是“临时解决方案”，它不断地增加新的特性（总是迫不及待地），而以重写为代价

如果这不会引起管理层的痛苦，他们就没有动力去改变它。“是的，当你下个月有时间的时候，你可以重写它，但我们现在只需要它来处理这个案子。”。新功能一出现，重写就被遗忘了

---

两年来，我一直在解释这是一段糟糕的代码（这意味着其中有一些看不见的bug）

谢谢，科西：-）我听到的并不总是其他人听到的，当然！“大泥球”反模式确实值得学习，因此感谢链接！荣誉很好的回答。anirudth-听起来你有一些经验来分享“产品会退化成一堆无法维护的垃圾。”-是的，这就是我在公司的BBOM：9comicheal-坦率地说，很难处理这样的代码。根据您拥有的时间长短，您会想到两种方法—在进行过程中重写或重构。我们做了这两件事——重构了当前版本并从头开始构建了一个新版本。通常情况下，这不是替代它的选项，所以重新设计并重新构建整个解决方案，正如Anirudh所说，就是解决方案