Как преодолеть анти-паттерн «Большой шарик грязи»?

Что заставляет компьютерную программу превращаться вБольшой шарик грязи? Можно ли оправиться от этого анти-паттерна? Существуют ли проверенные методы рефакторинга, которые можно применять?

Ответы на вопрос(7)

Это может пролить свет на исходный вопрос.

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

A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from an engineering point of view, such systems are common in practice due to business pressures and developer turnover. They have therefore been declared a design anti-pattern.

В моем случае одним из элементов моего программного обеспечения, попавшим в эту модель, было «временное решение», около двух лет назад, в которое постоянно добавлялись новые функции (всегда срочно) за счет переписывания.

Если это не вызывает управленческой боли, у них нет стимула ее менять. & quot; Да, когда у вас будет время в следующем месяце, вы можете переписать его, но нам просто нужно, чтобы оно работало для этого случая прямо сейчас & quot ;. Как только новая функция включена, о перезаписи забывают.

Я два года объяснял, что это плохой кусок кода (подразумевается, что в нем есть невидимые ошибки).

Я всегда приписывал термин (BBOM) кодовой базе, в которой «все зависит от всего» и трудно найти код, который вы хотите изменить, и когда вы вносите изменения, вам приходится менять что-то повсюду, чтобы заставить его работать снова. Вам нужна вся база кода, чтобы протестировать один измененный класс / файл. Дядя Боб называет это Синдромом Утром После (Вот по принципу ациклических зависимостей).

Это в значительной степени неизбежно, что кодовая база будет (хм)devolve в BBOM в отсутствие базового управления зависимостями, потому что это не может быть сделано разработчиками, которые видят не больше, чем код, который они редактируют в настоящее время.

BBOM, с которыми я сталкивался, обычно создавались органически, в дарвиновском процессе. Это выглядит примерно так:

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.

Соответствующая цитата из статьи в Википедии, которая отвечает вашей:

Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

Решение Вопроса

Большой Шар Грязи обычно происходит из-за одного из следующих:

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.

Иногда лучшее решение - просто переписать приложение, отвечающее новым требованиям. Но обычно это худший вариант развития событий. Громоздкое решение - остановить все новые разработки, начать с написания набора тестов, а затем перепроектировать и перестроить все решение. Однако это может занять годы, в зависимости от размера продукта.

Единственный раз, когда мне приходилось иметь дело с «BBOM» В этом сценарии нам, в основном, пришлось пересмотреть требования к пользователям и сделать вывод, что мы можем из ужасного кода. Как и во всех BBOM, проблема обычно не проявляется до тех пор, пока не потребуется некоторое техническое обслуживание / улучшение. (Никакой роскоши анализа кода в этом магазине, к сожалению, критерии были «он делает то, что они хотят?») И «автор» давно ушел

Рефакторинг даже не был возможен в этом случае.

Ваш ответ на вопрос