Создание несвязанной архитектуры для оптимизации приложений

Как мы оптимизировали мобильные приложения 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 разработки: мы изменили нашу модель ветвления в управлении версиями, чтобы улучшить совместную работу, управление версиями и доставку.
• Внедрение полного документирования: мы внедрили практику документирования каждого преобразования, что упростило репликацию.

Источник