Когда команда говорит, что "архитектура уже мешает", это почти никогда не означает только код. Обычно за этой фразой стоят три разных слоя проблем: скорость продуктовых изменений, надежность системы и стоимость каждого следующего решения.
Хорошая новость в том, что архитектурный кризис редко случается внезапно. Обычно система подает сигналы заранее. Плохая — компании часто игнорируют эти сигналы слишком долго, потому что формально продукт все еще работает.
Сигнал 1. Каждая новая функция стала неожиданно дорогой
Первый заметный симптом — не падения и не аварии, а рост стоимости обычных изменений.
Если для запуска вроде бы понятной функции команде постоянно нужно:
- затрагивать слишком много модулей;
- согласовывать изменения между несколькими людьми;
- тратить много времени на регрессионные проверки;
- делать много временных компромиссов,
это уже не просто "сложный продукт". Это знак, что архитектура перестала помогать выпуску изменений.
В такие моменты компании часто пытаются лечить ситуацию наймом дополнительных инженеров. Но если сама система не поддерживает скорость изменений, рост команды лишь увеличивает стоимость координации.
Сигнал 2. Реакция на инциденты держится на героизме
Вторая группа симптомов связана с надежностью и операционной ясностью.
Если инциденты закрываются в основном за счет памяти нескольких людей, а не за счет прозрачности системы, это признак архитектурной зрелости ниже нужного уровня. Особенно если:
- наблюдаемость фрагментирована;
- ответственность размыта;
- корневую причину приходится восстанавливать вручную;
- одно и то же повторяется под разными названиями.
Снаружи это может выглядеть как проблема процессов. На практике очень часто основа именно архитектурная: система слишком неявная, слишком связанная и слишком сложная для спокойной эксплуатации.
Сигнал 3. Платформа становится дороже быстрее, чем растет ценность
Еще один хороший индикатор — динамика инфраструктурных затрат и операционной нагрузки.
Если система уже не дает ощутимого выигрыша в скорости, качестве или надежности, но при этом становится все дороже в поддержке, скорее всего, архитектура накопила лишнюю сложность. Причем это не обязательно значит, что все спроектировано плохо. Часто это просто следствие предыдущего этапа роста, который компания уже переросла.
В такой момент полезно смотреть не только на деньги. Нужно смотреть, какую цену платит команда за каждое следующее изменение.
Сигнал 4. Стратегические решения постоянно откладываются
Один из самых недооцененных признаков — не то, что команда делает, а то, что она перестает делать.
Если одни и те же темы переходят из квартала в квартал, например:
- модернизация ключевых частей платформы;
- выравнивание ответственности;
- разбор критичных узких мест;
- упрощение поставки изменений и наблюдаемости,
это означает, что архитектурный долг уже мешает бизнесу управлять будущим, а не только текущим кодом.
Что с этим делать
Почти всегда неправильная реакция — объявить большое переписывание. Обычно сильнее работает более спокойный подход:
- понять реальные узкие места, а не весь список старых болей;
- отделить системные ограничения от локальных неудобств;
- определить, что действительно мешает росту продукта прямо сейчас;
- собрать приоритетный план модернизации, который помогает выпуску изменений, надежности и затратам одновременно.
Архитектура начинает тормозить рост не в тот момент, когда становится "некрасивой", а в тот момент, когда бизнес теряет скорость решений. Чем раньше это увидеть, тем меньше шанс прийти к дорогой радикальной перестройке.
