Как побороть анти-паттерн "Большой Грязевой Шар"?

Question

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

Answer 1

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

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

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

• Некомпетентность - разработчиков (они не знают об анти-шаблонах), менеджмент (слишком требовательный, незнание продукта) или пользователи (они на самом деле не знают что им нужно). Это трудно решить.

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

Answer 2

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

1. Первоначально система создана (не предназначена) и плохо документирована.

2. Оригинальные ресурсы позволяют создавать больше хавок в других местах, поэтому для этой "устаревшей" системы нет даже устной истории.

3. Вводится свежая кровь. Эти разработчики пытаются раскрыть работу различных частей системы, но это похоже на то, как несколько слепых пытаются понять слона, когда один схватил хвост, один за ногу, а другой за туловище. Они вносят изменения, но никогда не испытывают к ним уверенности.

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Программисты, управляющие большим мячом грязного проекта настоятельно рекомендуется изучить это и понять, что это выполняет, и использовать это как свободная основа для формального набора требования к хорошо продуманному система, которая может заменить его.

Answer 6

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

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

Answer 7

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

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

Большой шарик грязи - это программная система, в которой отсутствует ощутимое архитектура. Хотя это нежелательно с инженерной точки зрения, такие системы распространены на практике из-за давления бизнеса и оборот разработчика. Поэтому они были объявлены дизайном антишаблон.