Мобильная мультиплатформенная разработка в McDonald’s

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

В компании McDonald’s мы изучаем множество вариантов сокращения объема кода в кодовых базах наших глобальных мобильных приложений. Несмотря на то, что существует множество вариантов, многие из них связаны с веб-решениями, которые приводят к неполноценному опыту для пользователя.

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

Моей команде нужно было решение, которое позволило бы нам иметь отзывчивый, «родной» пользовательский интерфейс, который бы оставался актуальным для платформы, а также позволило бы не разрабатывать бизнес-логику дважды.

Что такое Kotlin Multiplatform Mobile?

Kotlin Multiplatform (KMP) — это инструмент, позволяющий разработчику создать кодовую базу на языке Kotlin, которая может использоваться совместно на различных платформах и даже получать доступ к библиотекам и инструментам, родным для платформы.

К преимуществам использования KMM относятся:

• Единая кодовая база для бизнес-логики и общей функциональности, такой как сеть, хранение и синтаксический анализ.
• Бизнес-логика для платформ может быть обработана в одном месте, что снижает тестовую нагрузку на разработчиков, поскольку модульные тесты могут быть проведены для обеих платформ одновременно.
• Для интеграционного/инструментального тестирования в модуль KMM могут быть включены проекты для Android и iOS, что позволяет тестировать базы данных и сетевое взаимодействие с помощью нативной симуляции, эмуляции или аппаратного обеспечения в библиотеке кода.

К числу проблем, связанных с интеграцией KMM, относятся:

• Разработчикам iOS может быть сложно работать в среде KMM, так как она требует знания языка Kotlin, но он имеет много общего с технологией Swift, поэтому кривая обучения не будет слишком существенной.
• Не все библиотеки имеют эквивалент на языке Kotlin, но это можно решить с помощью специфичного для конкретной платформы кода, использующего парадигму ожидаемого/актуального кода.
• При использовании Kotlin-версий часто используемых библиотек сторонних разработчиков могут быть обнаружены недостающие возможности. Скорее всего, эта проблема будет решена по мере развития KMM.
• Библиотеки, использующие совместные корутины/асинхронные вызовы методов, могут аварийно завершаться из-за проблемы со старой моделью памяти Kotlin. Обновление до последней версии Kotlin в большинстве случаев позволяет избежать этого.

КММ для корпоративных приложений

Принимая решение об использовании KMM в своем программном стеке, следует учитывать стадию разработки и парадигму проектирования, которой придерживаются или будут придерживаться ваши приложения. Если ваше приложение построено на инъекции зависимостей и/или использует «чистую» архитектуру, то KMM хорошо впишется в него, поскольку его можно рассматривать как еще один доменный слой, преимущество которого в том, что он является общим для обеих платформ.

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

Как мы используем KMM в компании McDonald’s

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

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

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

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

Для обеспечения полного тестового покрытия каждый компонент KMM покрывается либо модульным, либо инструментальным тестом. Инструментальные тесты выполняются в локальном приложении для Android и iOS в структуре проекта КММ, чтобы убедиться в том, что любой код, выводимый на каждую платформу, работает как нативный. Размер проекта и его целенаправленность делают возможной test-driven разработку. Когда новые функции полностью протестированы, на каждую платформу выкладывается новая версия KMM.

Перспективы

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

Источник