Модульная архитектура в мобильной разработке: что это, как работает и когда нужна

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

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

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

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

Давайте разберем, как выглядит проект, который построен на «пазлах».

Как выглядит структура модульного проекта

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

Корневой проект, в котором размещены зависимости других проектов/фреймворков

В примере, который приведен выше, ModularApp — это корневой проект, а CoreModule, NavigationModule, SererApiModule и Onboarding — это модули или частицы, из которых состоит наш продукт.

В отличии от Onboarding модуля, первые три модуля всегда используются в наших проектах:

• NavigationModule — отвечает за навигацию внутри наших проектов и позволяет получить доступ к любому стеку и флоу.
• CoreModule — инициируется на старте проекта, в нем хранятся все стили и наборы представлений, которые будут использоваться.
• ServerApiModule — модуль для работы с RestAPI.

Количество модулей и их наполнение могут отличатся от проекта к проекту.

Как распределять обязанности в проекте

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

Работу следует строить следующим образом:

• Разработчик, который реализовывает модуль, должен быть владельцем репозитория;
• Разработчики, которые снова и снова используют (reuse) модуль в своих проектах, могут лишь создавать свои ветки и работать с модулем отдельно от мастера.

Удобство в том, что всегда есть человек, который может провести код ревью, ведь он ведает про ценность, которую приносит этот код.

Как создать модуль

Пять простых шагов:

1. Необходимо создать проект с темплейта framework.

2. Далее следует развернуть репозиторий, в котором будет находится наш проект. Расставить правильные уровни доступа для нашей команды.

3. Приступить к разработке кода.

4. Для оценки и тестирования нашего кода понадобиться создать тестовый проект, в который мы добавим наш framework и доведем его до желаемого уровня.

5. После того, как мы заполнили кодом наши модули, необходимо описать весь функционал в нашем read.me файле.

На заметку

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

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

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

Интеграция нашего модуля в проект может проходить посредством стандартного набора: Swift Package Manager, Manual framework, carthage, cocoapods. При выборе провайдера необходимо учитывать некоторые факторы, а именно:

• Carthage и Cocoapods — для публичного кода;
• Manual framework и SPM позволяют использовать внутренний код;
• Swift Package Manager не работает с объектами @IBDesignable, @IBInspectable.

Почему модули

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

Эти факторы привели нас к модулям, появилась стандартизация кода, привычка писать и читать код правильно. Швы выносились в отдельные модули и решались проблемы с функциональными задачами изолированно.

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

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

Есть ли минусы

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

Read the docs! Разработчик в команде не должен отвлекать разработчика модуля. Модуль считается мертвым, если нет документов.

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

Наш опыт

Мы в TRIARE разработали более 10 используемых модулей, которые активно развиваются. Есть 6 активных приложений, в основе которых лежат модули. Преимущества очевидны:

• Увеличена скорость инициализации проектов и разработки;
• Разработчики передают знания посредством описания кода модуля и документации;
• Построен новый модуль навигации, который покрывает потребности и недостатки Router;
• Облегчилась интеграция тестов, внедрение TDD;
• Разрабатываемый код всегда актуален благодаря повторному использованию модулей;
• Разработчикам стало легче переключаться между проектами и задачами, что привело к уменьшению bus factor.

Вместо вывода

Когда я только начинал изучать модули, все казалось слишком сложным. Теперь я могу сказать, что это не так. Я хочу, чтобы моя команда писала код легко. Никаких сложных архитектур, развертывание которых занимает 5-6 часов. Никаких проектов с устаревшим кодом, на обслуживание которых требуется 8 часов в день.

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