Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код.
А потом проходит несколько лет.
И внезапно оказывается, что проект, который «быстро накидали», начинает разваливаться от любого изменения.
Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм.
И начинается археология.
Почему так происходит?
Потому что почти любой проект без нормальной архитектуры рано или поздно превращается в спагетти. Причём даже если его пишут хорошие программисты.
Архитектура — это не про красоту
Есть популярное заблуждение:
«Архитектура нужна большим корпорациям. Маленькому проекту она не нужна».
Это неправда.
Архитектура — это не красивые картинки для начальства. Это ответ на очень практичный вопрос:
«Сколько боли будет при следующем изменении системы?»
Если любое изменение страшно — архитектура плохая.
Если модуль можно заменить без переписывания половины проекта — архитектура уже начинает работать.
Самая опасная вещь в проекте — успешный старт
Это ловушка, в которую попадали почти все.
Сначала всё прекрасно: один разработчик, одна база, один проект, «сейчас быстро сделаем MVP».
Потом появляется второй программист, третий модуль, интеграции, отчёты, уведомления, API, права доступа, фоновые задачи.
И внезапно система начинает напоминать подвал, где за 10 лет никто не разбирал провода.
Я видел проекты, где архитектура буквально убивала систему
Один из самых жёстких случаев был в сметной программе.
Файл сметы весил около 2 МБ. После загрузки в память он разворачивался примерно в 600 МБ. Каждое изменение документа увеличивало потребление памяти ещё процентов на 20.
Самое прекрасное — после закрытия сметы память не освобождалась.
Потому что были циклические зависимости, и объекты продолжали держать ссылки друг на друга.
Программа могла спокойно сожрать гигабайты RAM просто потому, что пользователь несколько раз открыл разные документы.
И проблема была не в языке. Не в Windows. Не в железе.
Проблема была в архитектуре.
«Но у нас же DLL!»
Это тоже классика.
Формально проект может быть разбит на модули.
На практике:
— DLL ссылается на форму
— форма лезет в базу
— SQL написан прямо в UI
— бизнес-логика вызывает элементы интерфейса
— модуль A знает про B, C, D и половину алфавита
Особенно весело это выглядит в старом enterprise.
В одной медицинской системе я видел SQL прямо внутри форм.
2023 год.
Не ORM. Не DAL. Не репозитории.
Прямой SQLConn из UI.
При этом проект был «разделён на DLL». Но DLL были перекрёстно связаны настолько, что любое изменение тянуло за собой каскад зависимостей.
Выглядело модульно. По факту — тот же монолит, только нарезанный кусками.
Монолит — не проблема
Вот здесь начинается священная война интернета.
Многие почему-то думают:
монолит = плохо
микросервисы = хорошо
На практике всё сложнее.
Плохой монолит — это когда нет границ ответственности.
Хороший модульный монолит может жить годами и прекрасно масштабироваться. Особенно если:
— есть чёткое разделение слоёв
— бизнес-логика отделена от UI
— зависимости контролируются
— модули общаются через интерфейсы
— нет циклических ссылок
Для большинства проектов модульный монолит вообще является лучшим стартом.
Потому что микросервисы — это не «магическая современная архитектура». Это цена. Иногда оправданная. Иногда — нет.
Микросервисы не решают проблему плохого кода
Они просто распределяют её по сети.
Вместо одного спагетти-монолита получается распределённое спагетти: с таймаутами, очередями, контейнерами, сетевыми ошибками и ночными поисками причины, почему сервис авторизации отвечает 502 только по вторникам.
Хорошая архитектура — это прежде всего понятные связи
Главный признак здоровой системы — предсказуемость.
Ты понимаешь:
— где находится бизнес-логика
— кто за что отвечает
— какой модуль можно менять
— какие зависимости допустимы
И желательно, чтобы цепочка выглядела так:
A → B
а не:
A → B → C → E → A → форма → SQL → XML → внезапно SMTP
Потому что именно так рождается настоящий enterprise-хоррор.
Самая дорогая ошибка — «потом отрефакторим»
Не отрефакторите.
Почти никогда.
Потому что потом появляются сроки, дедлайны, новые фичи, прод, поддержка и «срочно надо клиенту».
И временный костыль становится частью системы. Навсегда.
Тут очень подходит старая фраза из советского мультфильма:
«Лучше день потерять — потом за час долететь».
В архитектуре это работает буквально.
Иногда один лишний день на нормальное разделение модулей экономит месяцы боли через год.
Иногда правильная архитектура даёт чудовищный прирост производительности
Был у меня случай с Oracle.
Тяжёлая процедура: десятки миллионов строк, 4–5 JOIN, составные JOIN, всё через старый SQLConn.
Работало примерно 25 минут.
Сначала я прикрутил ORM (Entity Framework), разбил логику на подзапросы и начал стягивать данные асинхронно.
Память выросла процентов на 20–25. Зато время выполнения упало до 12 секунд.
Потом задача была разбита по потокам.
Итог — меньше секунды.
И это важный момент: архитектура — это не только «красиво». Очень часто это ещё и производительность.
Есть старая инженерная мудрость: не катить прод в пятницу
Потому что вселенная воспринимает это как вызов.
Однажды начальство очень хотело выкатить обновление именно в пятницу утром.
Я сразу предупредил: после обеда уезжаю на страйкбольную игру, связи почти не будет, и если что-то упадёт — быстро починить не смогу.
Ответ был классический:
«Да всё нормально будет, выкатывай».
Ну хорошо.
Выкатил и уехал.
18 вечера. Лес. До ближайшей цивилизации километров тридцать.
И тут звонок:
— «У нас всё не работает. Срочно чини».
Интернета почти нет.
В итоге я сидел на сосне метрах в пяти над землёй и правил код прямо на сервере с телефона, потому что только там ловила связь.
С тех пор к пятничным релизам я отношусь философски.
Главная проблема легаси — не старость
А отсутствие границ.
Старый код может быть нормальным.
Я видел проекты начала 2000-х, которые до сих пор поддерживать легче, чем некоторые современные «ультрамодные» системы.
Потому что там были понятные модули, нормальная декомпозиция, минимум магии и прозрачные зависимости.
И наоборот: можно за полгода превратить новый проект в технический Чернобыль.
Итог
Архитектура — это не про элитарность.
Не про «настоящих инженеров».
И не про диаграммы ради диаграмм.
Это способ сделать так, чтобы система пережила:
— рост
— новые фичи
— новых разработчиков
— смену технологий
— и тебя самого через три года, когда ты откроешь свой старый код
Потому что главный враг проекта — не язык. Не фреймворк. Не база данных.
А хаос связей внутри системы.
И чем раньше программист это понимает — тем меньше шансов однажды разгребать shop_final_new2_REAL_fix_v7.cs в пятницу ночью.
ссылка на оригинал статьи https://habr.com/ru/articles/1035696/