如何克服反模式“大泥球”？
是什么导致计算机程序变成大泥球？ 是否有可能从这种反模式中恢复？ 是否有经过验证可以应用的重构方法？
What causes a computer program to turn into a Big Ball of Mud? Is it possible to recover from this anti-pattern? Are there proven refactoring methods that can be applied?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
大泥球通常是由于以下原因之一而发生的：
需求更改 - 您使用一组需求构建解决方案，随着时间的推移，这些需求会发生变化，现在您可能正在满足这些需求面向想要使用相同产品但要求略有不同的不同受众。 您将这些需求融入同一个产品中，最终得到 BBOM。
开发人员变更 - 原始产品是由一组开发人员创建的，具有某些设计和架构假设，这些设计和架构假设对于“接管”该产品的全新开发人员来说并不完全明显用于维护或进一步开发。 新的开发人员做出自己的假设，随着时间的推移，产品会退化成一堆无法维护的垃圾。
无能 - 开发人员（他们不知道反模式）、管理层（要求太高、缺乏产品知识）或用户（他们并不真正知道自己要做什么）需要）。 这很难解决。
有时，最好的解决方案就是重写应用程序以满足新的需求。 但这通常是最坏的情况。 麻烦的解决方案是停止所有新的开发，从编写一组测试开始，然后重新设计和重新构建整个解决方案。 不过，这可能需要数年时间，具体取决于产品的大小。
A Big Ball Of Mud normally occurs because of one of the following:
Change of Requirements - You architect a solution with one set of requirements, which over time change and now, you are probably catering to a different audience who wants to use the same product with slightly different requirements. You bake those requirements into the same product and you end up with a BBOM.
Change of Developers - The original product has been created by one set of developers with certain design and architectural assumptions which are not entirely evident to a whole new set of developers who 'take over' the product for maintainence or further development. The new developers make their own assumptions and over time, the product degrades into a pile of unmaintainable junk.
Incompetency - of the developers (they are unaware of anti-patterns), the management (too demanding, lack of knowledge of the product) or the users (they don't really know what they need). This is hard to solve.
Sometimes, the best solution is simply to rewrite the application catering to the new requirements. But this is normally the worst case scenario. The cumbersome solution is to stop all new development, start by writing a set of tests and then redesign and rearchitect the whole solution. This could take years, depending on the size of the product, though.
我遇到的 BBOM 通常是按照达尔文的过程有机创建的。 它是这样的：
最初，系统被创建（而不是设计）并且记录很差。
原始资源继续在其他地方造成更多破坏，因此甚至没有这个“遗留”系统的口述历史。
新鲜血液被引入。这些开发人员试图揭示各个系统部件的工作原理，但这就像几个盲人试图了解大象，一个抓住了尾巴，一个抓住了腿，一个抓住了鼻子。 他们做出改变，但从来没有真正对这些改变感到有信心。
通过这种方式，系统通过盲目的自然选择“进化”，但与此平行的是最棘手、不可重现的错误的进化，这些错误之所以持续存在，正是因为它们保留在雷达屏幕之下，直到它们出现在客户面前 。
BBOMs I have encountered were usually created organically, in a Darwinian process. It goes something like this:
Initally, a system is created (not designed) and poorly documented.
Original resources go on to create more havok elsewhere, so there isn't even an oral history for this "legacy" system.
Fresh blood is brought in. These developers try to uncover workings of various system parts, but it's like several blind men trying to understand the elephant when one has grabbed the tail, one a leg, and one the trunk. They make changes but never really feel confident about them.
In this way, a system "evolves" by blind natural selection, but parallel to this is an evolution of the most intractable, unreproducible bugs that persist precisely because they remain under the radar screen, until of course they surface at a customer installation.
我总是将术语（BBOM）归因于一个代码库，其中“一切都取决于一切”，很难找到您想要更改的代码，当您确实进行更改时，您最终不得不更改所有内容让它再次发挥作用的地方。 您需要整个代码库才能测试单个更改的类/文件。 鲍勃叔叔将此称为“事后综合症”（此处，根据非循环依赖原则）。
在缺乏基本依赖控制的情况下，代码库几乎不可避免地会（咳咳）退化为 BBOM，因为开发人员只能看到他们当前正在编辑的代码，因此无法完成此操作。
I always attributed the term (BBOM) to a code-base in which "everything depends on everything" and it is hard to find the code you want to change, and when you do make a change you end up having to change stuff all over the place to make it work again. You need the whole code-base in order to test a single changed class/file. Uncle Bob calls this the Morning After Syndrome (here under Acyclic Dependencies Principle).
It's pretty much inevitable that a code base will (ahem) devolve into a BBOM in the absence of basic dependency control because it can't be done by developers that see no more than the code they are currently editing.
就我而言，我的软件陷入这种模式的一个要素是大约两年前的“临时解决方案”，它不断添加新功能（总是很紧急），但代价是重写。
如果它不会给管理带来痛苦，他们就没有动力去改变它。 “是的，当你下个月有时间的时候，你可以重写它，但我们只是需要它来处理现在的这个案例”。 一旦新功能出现，重写就被遗忘了。
两年来我一直在解释这是一段糟糕的代码（这意味着其中存在看不见的错误）。
In my case, one element of my software is falling into this pattern was a "temporary solution", around two years ago, that has constantly had new features added (always with urgency) at the expense of a rewrite.
If it doesn't cause management pain, they have no incentive to change it. "Yes when you get time next month, you can rewrite it, but we just need it to work for this case just now". As soon as the new feature is in, the rewrite is forgotten about.
I have been explaining for two years that it is a poor piece of code (the implication being that there are unseen bugs in it).
我唯一一次必须处理“BBOM”场景时，我们基本上必须与用户一起重新审视需求，并从可怕的代码中推断出我们能做什么。 与所有 BBOM 一样，在需要进行一些维护/增强之前，问题通常不会显现出来。 （这家商店没有奢侈的代码审查，可悲的是，标准是“它是否达到了他们想要的效果？”）而“作者”早已不复存在。
在这种情况下甚至不可能进行重构。
The only time I had to deal with a "BBOM" scenario, we basically had to revisit the requirements with the users and infer what we could from the horrendous code. As with all BBOMs, the issue doesn't usually make itself apparent until there's some maintenance/enhancement needed. (No luxury of code review at this shop, the criteria was sadly "does it do what they want?") And the "author" is long gone.
Refactoring wasn't even possible in this case.
回答您问题的维基百科文章中的相关引用是：
The pertinent quote from the wikipedia article that answers yours is:
这可能会对最初的问题有所启发。
http://en.wikipedia.org/wiki/Big_ball_of_mud
This might shed some light on the original question.
http://en.wikipedia.org/wiki/Big_ball_of_mud