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

Posted 2023-05-07

技术标签:

【中文标题】如何克服反模式“大泥球”？【英文标题】：How to overcome the anti-pattern "Big Ball of Mud"? 【发布时间】：2010-11-05 01:09:47 【问题描述】：

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

【问题讨论】：

【参考方案1】：

一个大泥球通常由于以下原因之一发生：

需求变更s - 您构建一个具有一组需求的解决方案，随着时间的推移而变化，现在，您可能正在迎合想要使用相同产品的不同受众要求略有不同。您将这些要求融入到同一个产品中，最终得到一个 BBOM。

开发人员变更 - 原始产品由一组开发人员创建' 用于维护或进一步开发的产品。新开发人员做出自己的假设，随着时间的推移，产品退化为一堆无法维护的垃圾。

无能 - 开发人员（他们不了解反模式）、管理人员（要求太高，缺乏对产品的了解）或用户（他们并不真正了解反模式）知道他们需要什么）。这很难解决。

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

【讨论】：

荣誉...精心制定的答案。 anirudth - 听起来您有一些经验可以分享“产品退化成一堆无法维护的垃圾”。 -是的，这是我在公司得到的 BBOM：9 comicheal - 坦率地说，很难处理这样的代码。根据您拥有的时间量，您会想到两种方法 - 在您进行时重写或重构。我们两者都做了 - 重构了当前版本并从头开始构建了一个新版本。【参考方案2】：

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

最初，系统已创建（未设计）且文档记录不完善。

原始资源继续在其他地方制造更多的破坏，因此这个“遗留”系统甚至没有***。

新鲜血液被引入。这些开发人员试图揭示各种系统部分的工作原理，但这就像几个盲人试图理解大象，一个抓住尾巴，一个抓住腿，一个抓住象鼻。他们做出改变，但从来没有真正对他们有信心。

通过这种方式，一个系统通过盲目的自然选择“进化”，但与此并行的是最难处理、不可复制的错误的进化，这些错误之所以持续存在，正是因为它们一直在雷达屏幕下，直到它们浮出水面在客户安装时。

【讨论】：

【参考方案3】：

我总是将术语 (BBOM) 归因于“一切都取决于一切”的代码库，并且很难找到您想要更改的代码，并且当您进行更改时，您最终不得不更改到处都是东西，让它再次工作。您需要整个代码库才能测试单个更改的类/文件。 Bob 大叔将此称为“综合症后的早晨”（here 在非循环依赖原则下）。

在没有基本依赖控制的情况下，代码库（咳咳）演变成为 BBOM 几乎是不可避免的，因为开发人员只能看到他们自己的代码，这是无法做到的。正在编辑中。

【讨论】：

【参考方案4】：

就我而言，我的软件的一个元素落入了这种模式，这是大约两年前的“临时解决方案”，它不断地添加新功能（总是很紧迫），但代价是重写。