Когда старый монолит начинает мешать процессам в разработке, первое, что обычно приходит в голову командам — это переезд на новый стек. Логика понятна: сделаем новый UI, почистим код, а дальше и разработка пойдет бодрее. Чаще всего такое решение — очень дорогая иллюзия. Потому что в бигтехе проблема обычно не в UI, а в связности компонентов, зависимости фронта от бэка, сложных релизах и фичах, которые требуют синхронной работы команды.

Мы — разработчики Surf, Android и iOS команды: Светлана Сорокина, Антон Бояркин и Алексей Рябков. Когда начали работать с Бургер Кинг над трансформацией приложения, столкнулись с похожей историей. Основная сложность была в том, что всё упиралось в старую архитектуру. Поэтому мы решили переписать её так, чтобы разные подрядчики могли нормально работать вместе, а продукт — развиваться быстрее без просадок.

В какой момент становится понятно, что старый стек не работает

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

Сначала новая фича делается чуть дольше обычного. Потом простое изменение внезапно цепляет полсистемы. Затем команда обсуждает уже не столько саму задачу, сколько то, как аккуратно встроить что-то новое в существующие ограничения. Постепенно растёт количество багов, а на их исправление уходит всё больше времени. Нетиповые сценарии начинают стоить непропорционально дорого. Продукт становится тяжёлым на подъём.

С Бургер Кинг так и было. Приложение работало для пользователей. Но внутри уже было видно, что для следующего этапа роста старого фундамента недостаточно. Бизнесу нужно было быстрее запускать промо-механики, гибче управлять корзиной, легче тестировать новые сценарии и не превращать каждую доработку в отдельный проект. Этому мешала именно архитектура, а не скорость команды. 

Что было до

На iOS приложение было одним большим модулем. Рядом располагались вспомогательные части вроде Core, Services, CoreServices, ReusableLayers, Resources, но основная логика была плотно связана сама с собой. Формально модули были, но при этом поменять что-то одно означало потянуть за собой половину соседнего.

На Android ситуация выглядела чуть аккуратнее, но проблема была похожей. Код был разделён по слоям Clean Architecture — Data, Domain, Presentation, плюс Common и Utils. Но бизнес-логика жила вперемешку в одном доменном слое. Домен корзины учитывал домен ресторанов, домен ресторанов — купоны. И получалось, что если поменять выбор ресторана, то можно задеть корзину. Если менять корзину, придется учитывать чекаут. Тесты при таком раскладе быстро становятся дорогими.

Начали не с дизайна, а с правил разработки

Самый большой соблазн в таком проекте — сразу идти в дизайн: сделать классные новые экраны, UI, красивые компоненты. Но мы знали, что начинать нужно не с этого.

Сначала вместе с командой Бургер Кинг сделали внутренний аудит, спроектировали новую архитектуру и прогнали её через внешнее архитектурное ревью. И только после этого зафиксировали стратегию. Она держалась на нескольких базовых принципах:

• модульность, где каждая бизнес-фича живёт в собственном модуле;

• современный стек для обеих платформ;

• параллельная разработка фронтенда и бэкенда;

• бесшовная миграция без резкого отключения старой системы;

• сохранение всего критичного функционала с первого дня.

Здесь важен один момент. Нельзя сказать, что команды просто мешали друг другу правками. Внутри своих контуров все в целом синхронизировались нормально. Главная боль была другой: бэкенд делали заранее, а когда до задачи доходили мобильные команды, API уже существовал — и часто не в самой удобной для клиента форме. Поменять его на этом этапе было дорого, поэтому приходилось идти на компромиссы. А дальше эти компромиссы превращались в костыли в UI и сложные обходные сценарии.

Фундамент фронтенда заложили ещё до финального ТЗ

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

На старте сделали несколько вещей, без которых такая пересборка быстро превратилась бы в хаос:

• спроектировали многомодульную архитектуру для iOS и Android с нуля;

• зафиксировали технологический стек для обеих платформ;

• собрали модуль навигации и систему диплинков;

• начали строить UI Kit: тему приложения, стили текста, цвета и базовые компоненты.

С диплинками отдельная история. Для приложения с миллионами пользователей и активным CRM/CDP это полноценный рабочий инструмент, а не дополнительная механика привлечени. Push должен вести не просто в приложение, а сразу в нужный купон, карточку блюда, раздел или сценарий. Если такие вещи откладывать на потом, они обходятся заметно дороже.

Как перестроили iOS-клиент

На iOS архитектуру собрали на SPM-пакетах с четырьмя уровнями:

1. Core Layer — системные расширения, ресурсы, доменные модели, протоколы, базовый networking и cache.

2. Middle Layer — DTO, data-сервисы, общие бизнес-сервисы, UI-библиотека, аналитика.

3. Feature Layer — модули конкретных фич.

4. Main Layer — точка входа в приложение.

Главное правило: прямые зависимости идут только сверху вниз. Feature-модули не ссылаются друг на друга напрямую, хотя горизонтальное взаимодействие между ними, конечно, есть. Оно строится через dependency injection (DI): если двум фичам нужно взаимодействовать, они делают это через протоколы и общие абстракции нижнего уровня или через навигацию. За счёт этого модуль зависит не от конкретного соседа, а от интерфейса. А конкретная реализация подставляется снаружи.

По стеку iOS получилась такая комбинация:

• MVVM + Coordinators;

• SwiftUI;

• Combine;

• Factory для DI;

• NodeKit.

Отдельно эволюционировал сам DI. На старте использовали обычные инъекции по всему приложению. Для небольшого количества модулей это было удобно. Но по мере роста приложения связи стали хуже читаться, появились циклические зависимости, общая картина стала заметно мутнее. В какой-то момент наверху, в Main Layer, появился отдельный composer зависимостей. Он взял на себя межмодульную сборку и связи между частями системы. А внутри самих модулей остался привычный DI. В итоге получилась двухуровневая схема: сверху composer собирает систему, внутри модулей работает обычная инъекция. После этого зависимости стали гораздо прозрачнее. 

Отдельно пришлось переработать работу с данными. Вместо загрузки огромной локальной базы блюд приложение стало получать только действительно нужные данные с бэкенда. За счёт этого пользователи начали видеть более актуальные цены, составы и конфигурации в реальном времени.

Как перестроили Android-клиент

На Android архитектуру тоже не стали сводить к переходу на Compose. Её собрали в три уровня:

• app-модуль как точка входа;

• сервисные модули без бизнес-логики;

• feature-модули с внутренним разделением по слоям Clean Architecture.

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

Самое важное было внутри feature-части. Каждая фича разбивалась не на один модуль, а на четыре: api-logic, api-presentation, impl-logic, impl-presentation. За счёт этого другие части системы видели только контракт, а реализация оставалась закрытой. Это решало классическую проблему, когда одна фича начинает тянуть за собой внутренние части другой. Плюс такая схема сильно помогает там, где нужно держать две реализации одной фичи параллельно, например для А/Б-тестов: меняется implementation, контракт остается тем же.

UI рисовали на Compose, но фрагменты оставили контейнерами экранов. Полностью Compose-only среда на тот момент не очень хорошо дружила с частью внешних библиотек и кастомной навигацией. Фрагмент как контейнер давал предсказуемое поведение и не ломал то, что уже работало.

Стек на Android выглядит так:

• Ktor;

• Coroutines;

• Hilt;

• Coil;

• Kotlinx.serialization;

• Surf Navigation — использовали свои наработки на основе Cicerone.

Плюс использовали AI: генерировали Compose-код по макетам из Figma, чтобы быстрее выходить на ревью и не тратить лишнее время на рутину.

SwiftUI и Compose реально дали эффект — но не сами по себе

Да, новые фреймворки здесь сработали. Они ускорили сборку типовых интерфейсов, упростили развитие UI Kit и сделали дешевле по времени то, что раньше стоило слишком дорого — например, сложные анимации и более насыщенные пользовательские сценарии.

За счёт этого стало проще развивать такие вещи, как:

• анимированные промо-механики;

• сборка комбо в несколько шагов;

• более точечный онбординг;

• история покупок;

• кастомизация заказа;

• сохранение привычных сценариев оплаты и лояльности.

Но здесь важно не перепутать причину и следствие. Эти фреймворки начали ускорять разработку только потому, что сверху уже была нормальная архитектура. Если бы их просто натянули на старую схему разработки, ничего принципиально не изменилось бы. Сработали многомодульность и разведённые контракты. Вот пара примеров.

1. Сетевая модель корзины раньше использовалась и в логике, и прямо на экране. Если бэкенд менял поле, править нужно было сразу и бизнес-логику, и вёрстку. Один незаметный пропуск — и экран рассыпался. В новой схеме DTO, доменная модель и UI-модель разведены. Чтобы использовать чужую модель, надо явно подключить модуль, и это видно на ревью.

2. Ещё один пример — логика выбранного ресторана. Она жила в нескольких местах. Со временем её вынесли в единое пространство, но с саму логику приходилось часто править. Из-за этого рождался класс ошибок, который сложно поймать: код меняется вроде легко, а ревью не всегда замечает побочный эффект. В новой модели выбор ресторана мы вынесли в отдельный модуль. Изменить его снаружи нельзя — только внутри самого модуля. И это уже сильно снижает количество случайных поломок.

Что реально ускорило delivery

По-настоящему все ускорить получилось, когда фронтенд и бэкенд перестали ждать друг друга. Со стороны бэкенда систему разбили на независимые доменные сервисы:

У каждого сервиса — своя зона ответственности и своя база данных.

Между клиентом и этими сервисами поставили Composition Layer — единую точку входа. Если внутренние сервисы меняются, а API-контракт остаётся прежним, мобильному приложению не нужно знать, что именно внутри переделали. Со стороны клиента этот же принцип поддержали мок-сервером и заранее согласованным контрактом. Пока реальный бэкенд ещё строился, фронтенд не простаивал: его можно было разрабатывать и тестировать на моках, идентичных по API. Когда реальный сервис поднимался, переключение было незаметным. 

Самая важная часть проекта — миграция, а не переписывание кода

Есть огромная разница между просто обновлением приложения и переводом его на новый стек без удара по бизнесу. Второе всегда сложнее.

Поэтому одна из самых важных частей проекта — схема миграции. Старое и новое приложение какое-то время работали параллельно, а серверный Composition Layer маршрутизировал запросы так, чтобы переход был прозрачным для пользователя. Со своей стороны мы строили клиент так, чтобы он мог спокойно жить в этой переходной модели и не ломать пользовательские сценарии.

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

Без тестирования всё это развалилось бы на первом же релизе

На проекте такого масштаба тестирование нельзя вынести в конец всего процесса как финальную проверку. Если так делать, проблемы всплывают слишком поздно, когда цена ошибки уже высокая. Поэтому мы выстроили shift-left подход: тесты появляются не в самом конце, а как можно раньше, по ходу работы над фичей. Разработчики пишут тесты, опираясь в том числе на прогоны QA, и за счёт этого ручные сценарии постепенно синхронизируются с автоматизацией.

Сейчас у нас три основные группы тестов.

• Unit-тесты пишут разработчики. В первую очередь они покрывают бизнес-логику и помогают быстро проверять, что изменения не ломают базовое поведение системы. Часть этих тестов синхронизирована с ручными сценариями QA через автоматизацию, поэтому это не просто изолированная проверка кода ради покрытия.

• Snapshot-тесты в основном пишут разработчики, но подключаются и AQA. Эти тесты уже тесно связаны с ручными прогонами QA и помогают проверять вёрстку и состояние экранов. За счёт этого можно быстрее замечать визуальные расхождения и не ловить их уже на поздних этапах.

• UI-тесты пишут AQA. Они тоже синхронизированы с ручными проверками и покрывают ключевые пользовательские сценарии на уровне реального поведения приложения.

В итоге получается, что мы покрываем не только код unit-тестами, но и постепенно переносим в автоматизацию сами ручные проверки. И именно это даёт больше уверенности в релизах: изменения можно выпускать быстрее, потому что основные сценарии уже проверены на нескольких уровнях.

Результаты:

• на Android больше 50% UI покрыли скриншот-тестами;

• покрытие unit-тестами на Android выросло с 20% до 36%;

• AI применяли и для генерации unit-тестов, что всё ускорило;

• нагрузочное тестирование бэкенда сделали непрерывным.

Релиз: сначала 5%

Новое приложение мы не выкатывали на всех сразу. Сначала дали доступ только 5% пользователей. Ограниченный релиз — адекватный способ свериться с реальностью: посмотреть, как приложение ведёт себя в живых сценариях, и послушать тех, кто действительно им пользуется.

Это сработало. Один из пользователей поймал баг, который мы просмотрели: на Android 12 и ниже нет системного запроса на разрешение push-уведомлений, он появился только в Android 13. Приложение ожидало ответ, которого не существовало, и зависало на сплэше. Мы быстро добавили обходной сценарий и закрыли проблему до более широкой раскатки.

Что в этой истории важно для разработки

Для себя сделали выводы, что в зрелом продукте новый стек начинает приносить пользу только после того, как вы:

• убрали архитектурные ограничения;

• разделили систему на внятные части;

• развели ответственность между командами;

• зафиксировали контракты;

• дали фронтенду и бэкенду работать параллельно;

• продумали бесшовную миграцию.

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

Сейчас продолжаем работать над приложением и ещё будем рассказывать, что в такой трансформации реально работает. Обо всех самых актуальных инсайтах в мобильной разработке рассказывает наш C-level в Телеграмм-канале «Директорат Surf обсуждает» — от внедрения ИИ до управления командой.