Монолитные системы – наследие

Раздел: Programming / Теория разработки @ 21.08.2008 | Ключевые слова: проблемы разработки

Автор: Kaaboeld
Источник: habrahabr

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

Основная проблема

При создании не предполагает наращивания функционала. Создается «раз и на всегда» — любая «новая кровь» — не той группы и вызывает отторжение. Любое хирургическое вмешательство рано или поздно приводит к появлению «Франкенштейна» — сущности Множеств — объеденных синтетическими связями.

Со временем в любом проекте наступает этап, когда базового функционала становиться не достаточно.
Основываясь на первом тезисе – существует несколько вариантов решений:

Инъекции

«—Я не знаю, как это работает — сделаю поверх»

Так как у Системы много пап (мам) — новые ее родители, часто экономят свое время и нервы – не пытаются разобраться в кусках чужого «наследия» и просто работают «поверх» того, что есть. Многим знакомы симптомы подобного отношения: или превентивные инъекции кода черед replace после генерации. Основная проблема, если проекту предположим 10+ лет, то подобные «методы» наслаиваются друг на друга.

Внести изменений в ядро

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

Чистый лист

Создание новой системы, подразумевает колоссальные затраты времени и финансов – которые только приумножаются с каждым днем работы текущей «версии». Так как за это время происходит ее развития (наращивание функционала) иными способами. Полная остановка работы системы на время создания новой, в большинстве случае — невозможна, так как ведет за собой потерю потенциальной прибыли.

Вернуться в раздел: Programming / Теория разработки