Почему мало просто перейти на SwiftUI и Compose: заглядываем под капот перезапуска приложения Бургер Кинг

В сфере искусственного интеллекта произошло заметное событие. Surf_Studio 43 минуты назад Почему мало просто перейти на SwiftUI и Compose: заглядываем под капот перезапуска приложения Бургер Кинг Сложный 9 мин 1. 5K Swift * Jetpack Compose * Разработка мобильных приложений * Тестирование мобильных приложений * Управление разработкой * Кейс Когда старый монолит начинает мешать процессам в разработке, первое, что обычно приходит в голову командам — это переезд на новый стек. Логика понятна: сделаем новый UI, почистим код, а дальше и разработка пойдет бодрее.

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

Технические детали

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

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

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

Отраслевые последствия

Нетиповые сценарии начинают стоить непропорционально дорого. Продукт становится тяжёлым на подъём. С Бургер Кинг так и было.

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

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

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