Как мы оптимизировали мобильные приложения Walmart Mexico
В этой статье мы объясняем инженерные решения, которые мы применили для стандартизации и разделения архитектуры этих четырех приложений Walmart Mexico:
- Walmart Groceries
- Walmart Plus
- Superama
- Bodega Aurrera
Для выполнения этого проекта по реархитектуре отдел электронной коммерции Walmart Mexico собрал многопрофильную команду Core Mobile, ответственную за разработку и тестирование новых реализаций. Затем остальные мобильные группы смогли воспроизвести решения у себя.
С самого начала основной целью было изменение архитектуры, но затем мы эволюционировали, чтобы совершить другие преобразования, такие как CI/CD, автоматизация тестирования, стратегия репозитория и другие.
Какова стоимость устаревшей архитектуры
Учитывая, что разные мобильные приложения имеют схожие пользовательские потоки, функции и варианты использования, проект был направлен на создание общей базы для архитектуры, фрагментов кода и конвейеров всех приложений. Это было сделано для того, чтобы разные команды не делали снова одну и ту же работу, что и с устаревшей архитектурой.
Раньше разработчики пересоздавали создавали 95% фронтэнда для iOS и Android приложений. Восемь команд работали над восемью разными приложениями, но решали одни и те же задачи.
Вот некоторые болевые точки, с которыми мы столкнулись при работе с устаревшей архитектурой:
- Сложность повторного использования кода
- Сложности с масштабированием приложений
- Сложный контроль зависимостей
- Низкое качество и непоследовательность кодовой базы
- Непонимание кодовой базы
- Статичные команды
Как работала устаревшая архитектура
Устаревшая архитектура поддерживала множество различных версий мобильных приложений iOS и Android. Например, для iOS у нас было три архитектуры, поддерживающих четыре приложения. В то время как для Android у нас была одна архитектура.
Одной из проблем устаревшей архитектуры было то, что некоторые ее слои были собраны вместе, что затрудняло повторное использование фрагментов кода в качестве автономных модулей в приложениях.
Следующая диаграмма является примером одной из версий архитектуры, которые у нас были. Он показывает, как взаимодействовали слои в приложении Walmart Plus.
Схема устаревшей архитектуры
Схема показывает, как четыре слоя существовали вместе и зависели друг от друга. Остальные версии legacy архитектуры имели схожие реализации и те же трудности.
Как мы сделали новую несвязанную архитектуру
Основная цель команды Core Mobile заключалась в изменении архитектуры четырех мобильных приложений, запущенных Walmart Mexico. Надо было разработать общую архитектуру для всех приложений iOS, а также общую архитектуру для всех приложений Android.
В рамках этой новой модели приложения используют одну и ту же архитектуру для iOS или для Android. Однако они все же отличаются друг от друга, поскольку имеют собственную реализацию компонентов внутри слоев. Это стало возможным благодаря тому, что новая архитектура развязана и разделена на модули. По этой причине одни и те же компоненты и слои представляют различную реализацию в зависимости от модуля, к которому они принадлежат.
В этом проекте мы называем модули Контекстами (Contexts). Они устанавливают ограничения для определенной части бизнес-логики Walmart и в то же время содержат все архитектурные компоненты, необходимые для выполнения одной функции приложений.
Функциональность относится к той части бизнеса, которую Context ограничивает сам. Оплата (Checkout) и Вход (Sign In) являются примерами таких Контекстов в мобильных приложениях. В этих случаях Пользовательский уровень (Use Case), который является общим для всех приложений, может представлять другую реализацию, если в качестве Контекста выбрано Checkout или Sign In.
На следующей диаграмме показано, как модули, уровни и компоненты взаимодействуют в несвязанной архитектуре.
Схема несвязанной архитектуры
На диаграмме видно, что Контексты содержат подконтексты, каждый из которых принадлежит определенному приложению. Подконтекст содержит различные уровни представления, бизнес-логики и API-интерфейсов, которые взаимодействуют, создавая функциональные возможности Контекста, к которому они принадлежат.
Могут быть случаи, когда подконтекст является необязательным, поскольку бизнес-логика и шлюз API одинаковы для всех приложений. В этих случаях можно повторно использовать весь модуль.
Как мы использовали DDD, чистый код и MVVM
Чтобы создать стандартизированную и не связанную архитектуру, мы следовали следующим рекомендациям по разработке программного обеспечения:
- Предметно-ориентированное проектирование (Domain-Driven Design, DDD): предполагается, что ядром архитектуры должен быть уровень предметной области, включая всю бизнес-логику. В приложениях Walmart Контексты являются ядром модуляризации, связанной с бизнес-деятельностью Walmart.
- Model, View, ViewModel (MVVM): предполагается, что пользовательский интерфейс (UI) должен быть отделен от бизнес-логики.
- Модель Чистой архитектуры: предполагает, что программное обеспечение должно быть разделено на уровни, следуя правилу зависимостей, указывающих только внутрь.
На следующем рисунке показано правило зависимостей в модели чистой архитектуры.
Модель чистой архитектуры
Каково влияние новой архитектуры
После внедрения новой несвязанной архитектуры мы выявили не только технические преимущества в приложениях, но и культурные преимущества в командах.
Некоторые из технических преимуществ реализации несвязанной архитектуры:
- Более быстрая разработка более надежного кода.
- Повторное использование кода через модули (когда это применимо).
- Легкое масштабирование приложений.
- Контроль зависимостей на самом мелком уровне.
- Улучшение владения и качества кодовой базы.
А вот некоторые из культурных преимуществ реализации несвязанной архитектуры:
- Возможность менять команды.
- Сокращение времени и ресурсов за счет отказа от дублирования работы.
- Расширение возможностей более сконцентрированных команд.
С какими вызовами мы столкнулись
На пути реализации всех изменений, связанных с новой архитектурой, мы столкнулись с некоторыми проблемами, такими как:
- Нехватка штатных разработчиков: в то время, как мы работали над изменением архитектуры, мы также должны были работать над бизнес-задачами и требованиями мобильных приложений, которые уже были представлены на рынке.
- Кривая обучения: внедрение новой архитектуры, новых моделей разработки программного обеспечения и других преобразований потребовало от разработчиков дополнительных усилий по приобретению знаний.
- Добавление Sam: мобильное приложение Sam по-прежнему работает с устаревшим кодом. Мы включим его в новую архитектуру на следующих этапах.
Какие еще трансформации у нас случились
Воздействие новой архитектуры также отразилось в других преобразованиях, которые смогла выполнить мобильная команда Walmart Mexico. Например:
- Внедрение Walmart One: мы разработали единый интерфейс для Walmart Groceries и Walmart Plus.
- Внедрение CI/CD: мы настроили конвейер CI/CD для приложений, использующих Looper, сервер, разработанный поверх Jenkins командой Walmart Labs.
- Внедрение автоматизации контроля качества: мы собрали команду, чтобы трансформировать наши усилия по обеспечению качества (QA) путем создания стратегии автоматизированного тестирования.
- Внедрение монорепозитория: мы изменили нашу стратегию репозитория с мультирепозитория на монорепозиторий, чтобы упростить рабочий процесс для всех команд.
- Внедрение Trunk Based разработки: мы изменили нашу модель ветвления в управлении версиями, чтобы улучшить совместную работу, управление версиями и доставку.
- Внедрение полного документирования: мы внедрили практику документирования каждого преобразования, что упростило репликацию.