Почему мы все-таки выбираем модули в мобильной разработке

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

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

Спасибо! Благодаря этим комментариям я решил раз и навсегда разобраться с этими проблемами и показать, что правильное использование модулей — это качественный код, который улучшает и ускоряет нашу разработку.

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

Я не являюсь экспертом в JAVA, .NET C#, тем более в back-end части. Я — iOS разработчик. Практики и философия, которые легли в основу модулей, построены на опыте разработки мобильных приложений под iOS. Схожие подходы и архитектуры также имеют свою интерпретацию в каждой из технологий и, пожалуй, в любом из языков программирования.

Как мы пришли к модулям

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

Именно в этот момент было принято решение — стандартизировать и оптимизировать процесс разработки, начиная с этапа оценки до этапа релиза.

Период перестройки выпал на момент, когда под рукой была классика литературы: «CleanCode» Роберта Мартина и «TDD» Кента Бэка. Велосипедист с меня не очень, поэтому для начала я решил пойти по пути наименьшего сопротивления и принялся за разработку того, что за меня уже придумали.

Все оказалось настолько просто, что вышло сложным. Вдохновение разработать «чистый код» обернулось абстракцией, которая была не переиспользуемой. Итерационная разработка была похожа скорей на творческий порыв и маниакальное желание писать тесты, нежели на итерации red-green-refactor.

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

Отдохнув несколько дней от кода, я выделил свои цели и задачи:

  1. Разработать итеративный код
  2. Переиспользовать код
  3. Сделать код стабильным
  4. Уменьшить эстимейты

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

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

Это действительно повышало уровень стресса, особенно, когда дизайн уже утвердили, а разработчиков забыли спросить. Я благодарен компании Apple и разработчикам xCode за шикарные стэки навигации и элементы, которые за это отвечают, но даже эти ребята не покроют креативный поток дизайнеров.

Выход один — делать свою реализацию. А это прямой намек на разработку модуля. Мои глаза снова загорелись.

Забегу наперед, дабы заранее спастись от программистов-тестировщиков: итеративность — это не про тесты. Тесты — это всего лишь средство оценки качества и работоспособности вашего кода. Итеративность — это методология, подход, видение, или, если хотите, мировоззрение, а тесты — ее производное.

Создание итеративного модуля

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

Для примера опишем базовое флоу похожих приложений, таких как службы доставки, такси, курьерские услуги. Ниже представлен список флоу:

  • Авторизация
  • Главный экран
  • Карта
  • Профиль
  • Способы оплаты
  • Процесс заказа
  • И т.д.

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

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

Чувствуете, как это просто и легко? Декомпозиция больших единиц помогает нам сделать хорошую итерационную модель.

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

Решением этой задачи стало отнюдь не абстрагирование объектов или оптимизация кода. Решение было другим — выпилять код, очистить ядро и разложить наш репозиторий по веткам. Так спустя время мы получили:

  • ядро проекта, которое находилось в мастере;
  • функционал, который мы хотели доделать в ядре или оптимизировать — в девелопере;
  • экстра фичи модуля в отдельных ветках под проект.

Таким образом нам удалось подменить понятие переиспользования на расширение. Это очень помогло. Так мы смогли использовать наш код и в проектах, которые до 300 часов и в проектах, которые более 1000.

Как налаживается стабильность

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

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

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

Покрывать ли код тестами? Нет!... Шучу, остановитесь и перестаньте писать гневные комментарии. Я практикую и всегда ставлю в приоритет тесты, но не в этом случае. Думаю, многие согласятся, что покрывать тестами навигацию не лучший способ удостоверится в верности своих действий. Лучше это время потратить на следующую итерацию разработки.

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

Как уменьшить эстимейты

Уменьшить эстимейты, хм... Попробуем. Если разработчик будет тратить меньше времени на сбор проекта, то на 1-2 часа проект будет разработан быстрее. Модуль мы можем добавить, как скомпилированный фреймворк — это ускорит процесс сборки проекта. Ура — мы сэкономили 2 часа наших эстимейтов. Таких ли цифр от нас ожидает клиент, когда мы рассказываем о нашей экспертизе и оптимизации? Конечно же нет!

Ранее я упомянул о том, что модули переиспользуются, а значит, мы берём код, который уже разработан, протестирован, он прошел боевые испытания и готов интегрироваться в новые проекты. Для примера, реализация функционала чата может занять в районе 60-ти часов. Переиспользование модуля — это время до 20 часов, что лучше 1-2 часов, эти цифры нравятся клиентам.

Буду с вами честен. Я не знаю, куда меня заведут модули. Не знаю я, насколько они будут актуальны через 5-10 лет. Мир разработки так стремительно развивается, что порой я не успеваю смотреть видосы и читать статьи, не говоря уже о книгах. Я знаю, что в данный момент модули — это средство, которое помогло мне добиться моей цели: уменьшить уровень стресса от разрабатываемого кода, ну и конечно же прокачать свой навык.

Спасибо всем читателям, комментаторам и просто прохожим.

👍НравитсяПонравилось2
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

По сути: Если делать правильно — то всё хорошо, а давайте-ка проигнорим риски.
На деле: есть огромная разница в том, ЧТО ИМЕННО вы разрабатываете. Современные мобильные устройства это уже полноценные компьютеры, им только операционки хорошей не хватает. В остальном же — ресурс огромен, развернуться есть где.

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

Так что модульный подход хорош, но он ни разу не универсален. В будущем его популярность будет, естественно, расти — но есть потолок в виде тяжёлого контроля над модульным зоопарком, который комьюнити уже откровенно тяжело тянуть — само-то комьюнити тоже весьма подвижно, текучка кадров огромна. А вот в проприетарных платформах модульная разработка — самое то что надо. Особенно когда модули можно лицензировать отдельно. В том числе модули, несущие код других владельцев.

Хорошие мысли. Если говорить об рисках, то они всегда есть. В монолитах их на много больше)
Касательно работы в команде, нужен хороший ментор и документация, тогда многие риски покрываются

В монолитах рисков намного больше

Инфа 50%. Монолиты никакие не монолиты. Просто блоки с меньшей бюрократизацией связей, и соответственно с более коротким жизненным циклом. И цена ниже.

Подписаться на комментарии