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

Три системы в диалоге — всё читаемо. Десять в постоянном обмене — другая жизнь. У нас есть проект: несколько крупных подсистем, которые живут в непрерывном диалоге. Клиенты и заказы, доставка, маркетинговые активности, оплаты. Каждая со своей логикой. Каждое изменение в одной рябью идёт по остальным. Когда зависимостей двадцать — ты поменял метод, прошёлся по цепочке, закрыл. Когда их триста — ты физически не можешь держать в голове полную карту того, что за чем тянется.

Вот здесь начинается самое интересное. Был у нас период, когда качество, скажем, проседало. Не потому что ребята плохие — потому что система стала достаточно запутанной, чтобы полноценное решение каждой проблемы требовало серьёзных часов на распутывание логики. А дедлайны никто не отменял.

Итог предсказуемый: хардкод. Не глобальный, не катастрофический — тихий и локальный. «Тут подпёрли, там заглушили, здесь обошли». Каждый патч решал конкретную видимую проблему. Не решал первоначальный затык в данных или логике — просто аккуратно его огибал.

Поначалу нормально. Потом заплатки начали цепляться друг за друга. Это классика, которую все знают и всё равно в неё влетают. Хардкод не исчезает — он накапливается. И в какой-то момент ты тратишь больше времени на то, чтобы понять, почему три заплатки конфликтуют между собой, чем на разработку реального функционала.

Что делать. Костыль — не грех. Иногда это единственный рабочий выход, когда система горит и клиент ждёт. Грех — о нём забыть.

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

Рефакторинг не страшен сам по себе — страшно делать его тогда, когда узлов уже столько, что распутывание занимает месяц, а то и больше. Выход — регулярно, небольшими порциями, до того как система стала непроходимой. Это просто дисциплина.

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

Сложная система не прощает пренебрежения к системности. Она просто накапливает его — и выдаёт счёт позже. Обычно в самый неудобный момент.

____________________________________ Никого не принуждаю, ничего не продаю (во всяком случае пока что) Мой ТГ: https://t.me/kom_on_dir