Почему мы все-таки выбираем модули в мобильной разработке
Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!
Начнем со слов благодарности. После первой статьи о модульной архитектуре в мобильной разработке, я столкнулся с комментариями, в которых идет речь о сложности поддержки, развития и функциональности на костылях программных модулей.
Спасибо! Благодаря этим комментариям я решил раз и навсегда разобраться с этими проблемами и показать, что правильное использование модулей — это качественный код, который улучшает и ускоряет нашу разработку.
В этой статье не будет кода, не будет углублений в реализацию, я расскажу, почему модули пришли в мою жизнь и стали спасением от многих проблем. Оговорюсь сразу: модули — это не панацея, модули — это способ разделять, переиспользовать и саппортить код.
Я не являюсь экспертом в JAVA, .NET C#, тем более в back-end части. Я — iOS разработчик. Практики и философия, которые легли в основу модулей, построены на опыте разработки мобильных приложений под iOS. Схожие подходы и архитектуры также имеют свою интерпретацию в каждой из технологий и, пожалуй, в любом из языков программирования.
Как мы пришли к модулям
Некоторое время назад количество проектов, которые требовали оценки, проектов, которые требовали саппорта, и тех, которые были уже на стадии разработки, перевалило за горизонт. Стоя на краю водопада и смотря на стремительно уплывающий поток смешанных архитектур, подходов, функционалов, которые разрабатывались за безумно разное количество времени, я терял последнюю надежду на удовольствие от разработки, уже не говоря о постоянно накапливающемся уровне стресса.
Именно в этот момент было принято решение — стандартизировать и оптимизировать процесс разработки, начиная с этапа оценки до этапа релиза.
Период перестройки выпал на момент, когда под рукой была классика литературы: «CleanCode» Роберта Мартина и «TDD» Кента Бэка. Велосипедист с меня не очень, поэтому для начала я решил пойти по пути наименьшего сопротивления и принялся за разработку того, что за меня уже придумали.
Все оказалось настолько просто, что вышло сложным. Вдохновение разработать «чистый код» обернулось абстракцией, которая была не переиспользуемой. Итерационная разработка была похожа скорей на творческий порыв и маниакальное желание писать тесты, нежели на итерации red-green-refactor.
В итоге я получил код, который не поддерживался, его нельзя было переиспользовать, тесты покрывали все что нужно и не нужно, и, вишенка на торте, — я потратил на это неделю. Согласитесь — это вовсе не похоже на здравое программирование.
Отдохнув несколько дней от кода, я выделил свои цели и задачи:
- Разработать итеративный код
- Переиспользовать код
- Сделать код стабильным
- Уменьшить эстимейты
Разработать итеративный код оказалось не так и сложно. Для того чтобы научится делать что-то хорошо, я считаю, нужно взять то, что уже реализовано, разобраться в этом и затем улучшить.
Меня всегда смущали супер-креативные дизайны мобильных приложений. Поймите меня правильно, я люблю красивые анимации и люблю их реализовывать, но кто послал дизайнерам право вершить судьбу в этой плоскости? Навигация на главном экране ведёт на боковое меню или дублирует его поведение? Каждый флоу — новый стэк боттом навигации? А давайте сделаем тройную вложенность, чтобы пользователь чувствовал, будто он на американских горках...
Это действительно повышало уровень стресса, особенно, когда дизайн уже утвердили, а разработчиков забыли спросить. Я благодарен компании Apple и разработчикам xCode за шикарные стэки навигации и элементы, которые за это отвечают, но даже эти ребята не покроют креативный поток дизайнеров.
Выход один — делать свою реализацию. А это прямой намек на разработку модуля. Мои глаза снова загорелись.
Забегу наперед, дабы заранее спастись от программистов-тестировщиков: итеративность — это не про тесты. Тесты — это всего лишь средство оценки качества и работоспособности вашего кода. Итеративность — это методология, подход, видение, или, если хотите, мировоззрение, а тесты — ее производное.
Создание итеративного модуля
Помня об итеративности, я принялся реализовывать код, который, так сказать, является оболочкой для нативной навигации, при этом расширяет ее возможности. В чем состояла моя итеративность? Я реализовывал код и расширял его по мере надобности. Основной идеей этого модуля было переключение глобальных флоу навигации.
Для примера опишем базовое флоу похожих приложений, таких как службы доставки, такси, курьерские услуги. Ниже представлен список флоу:
- Авторизация
- Главный экран
- Карта
- Профиль
- Способы оплаты
- Процесс заказа
- И т.д.
Эти флоу независимы друг от друга, они могут идти в любой последовательности (логической, конечно же). Данные, которые обрабатываются в этих флоу не зависимы друг от друга. А значит их можно выделить в отдельные группы и строить навигацию между ними. Назовем это первой итерацией в процессе создания модуля навигации.
Но со временем пришлось производить ряд обновлений и изменений. Хорошо, когда код позволяет управлять глобальной навигацией, но почему бы его тогда не использовать для навигации внутри каждого отдельного флоу? Это и стало второй итерацией в процессе создания модуля. Последующие итерации для написания ядра модуля появлялись по мере их надобности.
Чувствуете, как это просто и легко? Декомпозиция больших единиц помогает нам сделать хорошую итерационную модель.
Постепенно, в процессе копирования кода модуля из одного проекта в другой, он загрязнялся кучей дополнительного функционала. Потребности проектов меняются и меняется сложность переиспользования кода. Попытки пофиксить эту проблему на уровне кода с каждым разом собирали новую гору проблем и ненужного кода, это я еще не упоминаю об его саппорте.
Решением этой задачи стало отнюдь не абстрагирование объектов или оптимизация кода. Решение было другим — выпилять код, очистить ядро и разложить наш репозиторий по веткам. Так спустя время мы получили:
- ядро проекта, которое находилось в мастере;
- функционал, который мы хотели доделать в ядре или оптимизировать — в девелопере;
- экстра фичи модуля в отдельных ветках под проект.
Таким образом нам удалось подменить понятие переиспользования на расширение. Это очень помогло. Так мы смогли использовать наш код и в проектах, которые до 300 часов и в проектах, которые более 1000.
Как налаживается стабильность
Очень хорошо, когда в команде разработки настроен процесс код-ревью. Мы всегда актуализируем модуль, который используем в каждом проекте, поскольку всегда при изменениях в ветках от проекта к проекту мы проводим его рефакторинг и смотрим, как можно обновить ядро, или, возможно дополнительный код лучше оставить в ветке проекта.
Обычно код становится стабильным тогда, когда он проходит тестирование, модуль же стабильным можно назвать тогда, когда его использовали хотя бы в
Стабильность налаживается в каждом новом отдельном модуле примерно с 3 интеграции, но это не влияет на качество продукта. Мы внедряем их там, где нам известны кейсы для покрытия, и мы видим зоны ответственности нашего кода. Стабильность есть всегда на проектах, со временем стабильней становится только код модуля и, соответственно, ядро проектов, в которых он используется.
Покрывать ли код тестами? Нет!... Шучу, остановитесь и перестаньте писать гневные комментарии. Я практикую и всегда ставлю в приоритет тесты, но не в этом случае. Думаю, многие согласятся, что покрывать тестами навигацию не лучший способ удостоверится в верности своих действий. Лучше это время потратить на следующую итерацию разработки.
Тесты нужны всегда, где есть рациональное объяснение их применению. Если говорить о модулях, то в нашей команде активно используется модуль для работы с чатами, и он покрыт тестами, но о нем будем говорить в будущем.
Как уменьшить эстимейты
Уменьшить эстимейты, хм... Попробуем. Если разработчик будет тратить меньше времени на сбор проекта, то на
Ранее я упомянул о том, что модули переиспользуются, а значит, мы берём код, который уже разработан, протестирован, он прошел боевые испытания и готов интегрироваться в новые проекты. Для примера, реализация функционала чата может занять в районе
Буду с вами честен. Я не знаю, куда меня заведут модули. Не знаю я, насколько они будут актуальны через
Спасибо всем читателям, комментаторам и просто прохожим.
3 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів