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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

<Ол>

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

  

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

Answer 7

Это могло бы пролить некоторый свет на первоначальный вопрос.

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

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