Скорость команды часто пытаются измерить количеством сильных разработчиков.

Но самый быстрый человек в хаотичной системе обычно не ускоряет команду. Он первым начинает компенсировать её проблемы.

В большом проекте скорость теряется не столько в коде, сколько между мыслью «надо поменять» и моментом, когда изменение можно увидеть, обсудить, проверить и выпустить. Представьте: большое iOS-приложение для широкой аудитории. Несколько рынков из одного проекта. Данные обновляются раз в несколько секунд. Product хочет менять экраны быстрее, чем выходит новый релиз. В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми.

1. Запускать модули отдельно

Одна из самых дорогих операций в большом проекте – полная сборка. Разработчик приходит поправить один экран, меняет несколько строк и ждёт, пока соберутся модули, ресурсы и зависимости, которые не имеют отношения к задаче. Поэтому крупные разделы должны запускаться отдельно – только с нужной функциональностью, как миниаппы. Тогда изменение быстро видно, его не страшно переделать. Можно изолированно проверить связанные экраны, а новому человеку не нужно понимать весь проект, чтобы принести пользу в одном разделе.

Если результата долго ждать, люди начинают гадать. Если его можно увидеть быстро — проверяют гипотезы.

2. Не усложнять границы экранов

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

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

3. Проверять на реальном устройстве

Если данных много и они часто обновляются, симулятора недостаточно. В одном R&D-сценарии первый способ обработки данных занимал почти две секунды. Второй был быстрее, но при регулярных обновлениях заметно нагревал устройство. Причина была не в одной «тяжёлой» операции. Данные постоянно проходили длинный путь: JSON → DTO → доменные модели → view-модели → UI. И всё повторялось при каждом обновлении. Мы сократили число промежуточных моделей. Пики нагрузки остались, но устройство перестало стабильно нагреваться.

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

Но технической системы недостаточно. Регулярные релизы без здоровой среды быстро превращаются в тревогу и выгорание.

О том, как устроить такую среду – тот самый vibe coding, но не тот, о котором сейчас все говорят, – напишу чуть позже.