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

Ответ 1

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

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

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

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

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

Ответ 2

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

• Изначально создается система (не разработана) и плохо документирована.

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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