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

Другим вариантом будет использование flexbox .

Хотя это не поддерживается IE8 и IE9, вы могли бы рассмотреть:

  • Не обращая внимания на эти старые версии IE
  • Предоставление запасного варианта
  • Использование polyfill

Несмотря на то, что для полной кросс-браузерной поддержки понадобится дополнительный префикс стиля, специфичный для браузера, вы можете увидеть основное использование либо на этой скрипке, и по следующему фрагменту:

html {
  height: 100%;
}
html body {
  height: 100%;
  overflow: hidden;
  display: flex;
  flex-direction: column;
}
html body .container-fluid.body-content {
  width: 100%;
  overflow-y: auto;
}
header {
    background-color: #4C4;
    min-height: 50px;
    width: 100%;
}
footer {
    background-color: #4C4;
    min-height: 30px;
    width: 100%;
}

Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum
Lorem Ipsum

19
задан IAdapter 30 September 2009 в 14:45
поделиться

6 ответов

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.

27
ответ дан 30 November 2019 в 03:16
поделиться

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

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

1
ответ дан 30 November 2019 в 03:16
поделиться

Уместная цитата из статьи в Википедии, которая отвечает на ваш:

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

1
ответ дан 30 November 2019 в 03:16
поделиться

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

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

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

0
ответ дан 30 November 2019 в 03:16
поделиться

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

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

2
ответ дан 30 November 2019 в 03:16
поделиться

Не могли бы вы создать класс-оболочку, который содержит ссылку на экземпляр NSManagedObject, который вы хотите использовать в качестве ключа словаря? Затем вы можете заставить этот класс-оболочку реализовывать NSCopying вместе с хеш-методом (возможно, просто вызывая хеш-метод NSManagedObject) и использовать эту оболочку в качестве ключа словаря.

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

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

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

  • 8
    ответ дан 30 November 2019 в 03:16
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: