Как мы ускорили разработку мобильных приложений на 30%

1118
#Разработка 21 августа 2023
Давайте знакомиться. Меня зовут Миша Вассер, я отвечаю за мобильную разработку в AGIMA.
Мое дело — следить за качеством кода и продуктов, которые мы развиваем, помогать коллегам не факапить и настраивать процессы. С первым и вторым, кажется, понятно, а вот про процессы хочется поговорить подробнее.
Сейчас попробую описать нашу технологию разработки максимально простым языком. Это не техническая статья, на Хабре бы ее восприняли в штыки. Но моя задача — рассказать, как мы оптимизировали процесс и зачем это нужно.
Так что если вы хотите приложение как можно скорее — велком.
  • Дисклеймер! Я описываю не какое-то ноу-хау и не изобретаю велосипед. Я пишу про удобный инструмент руководителя мобилки, который можно использовать, а можно нет. Мы вот используем, пока всё круто! А статья будет полезна продакт овнерам и тем, кто развивает мобильные цифровые продукты, потому что я расскажу, за счет чего приложение можно сделать быстрее и дешевле.

Пара вводных слов

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

Остается одно: оптимизировать процесс. А дальше, как говорится, следите за руками.

Стандартные модули

Посмотрим, как вообще всё работает. Ежедневно мы видим сотни приложений в маркетах. Каждое из них уникально: кто-то делает Ecom-проекты, кто-то занимается финтехом, а кто-то запускает стартапы в области биомедицины.
Но в то же время все приложения имеют стандартную, привычную каждому функциональность. Это те фичи, которые мы представляем, как только слышим само слово «приложение». Вот примерный список:


  1. Пуш-уведомления и диплинки. Маркетинговый инструмент, который помогает общаться с пользователем. А еще пуши часто используют для технических конфигураций приложения в фоне, для обновления информации и других настроек.
  2. Авторизация через сторонние сервисы и/или ОТР. Это нужно, чтобы составлять портрет пользователя и рекомендовать ему товары и услуги. Плюс история покупок пользователя, персонификация настроек и многое другое — всё это скрыто в профиле пользователя.
  3. Оплата через популярные эквайринги. Задача бизнеса — генерировать прибыль. Здорово, когда вы при этом можете упростить пользовательский путь и встроить оплату товаров прямо в приложение.
  4. Face ID/ Touch ID. Бизнес заботится о безопасности пользователей. Часто вход в приложение возможен только по биометрии.
  5. FAQ. Служба поддержки — люди, через которых ежедневно проходят сотни звонков и сообщений. Чтобы облегчить им жизнь и повысить качество продукта, многие добавляют «Часто задаваемые вопросы» в свои приложения.
  6. Карты. Геопозиция — функция, которая необходима разным сферам. Определение местоположения пользователя необходимо для отображения ближайшего магазина, адреса доставки и многих других вещей.
  7. Onboarding. Как правило, 3–4 экрана с картинкой и текстом, на которых пользователю рассказывают о самых основных фичах продукта.
  8. Другие функции, которые встречаются пореже :)

Сколько времени уходит на эти модули

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

  1. Настройка пуш-уведомлений со стороны Mobile.
  2. Создание механизма обработки Deeplinks.
  3. Обработка 5–10 диплинков.

Как правило, оценка для каждой платформы получается большой. В среднем на такой модуль уйдет полторы недели.
  • Важно! В зависимости от архитектуры проекта и других факторов оценка может уменьшаться или увеличиваться. Я говорю о самом среднем примере. На моей памяти самый короткий срок, за который мы реализовали похожую функциональность — 5 дней, а самый долгий — 2 недели.
Разумеется, этот срок хочется сократить.

Как автоматизировать и ускорить разработку

Я знаю два распространенных способа:

  • Использовать сторонние SDK, которые делают всё за вас. Такое решение тяжело кастомизировать, оно может не подходить по функционалу и требует дополнительного вложения денег. Кроме того, возможно, вы автоматически будете передавать данные пользователей третьей стороне.

Ниже я объясню подробнее, что такое SDK.

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

Мы пошли другим путем

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

  1. Проект с базовой архитектурой и настроенными процессами (CI/CD и другие технические вещи). Имея такой проект, мы можем значительно сократить время на разворачивание и настройку нового проекта.
  2. SDK-модули с популярным функционалом, которые можно подключать отдельно. Про них далее поговорим подробнее.

Про SDK и его преимущества

SDK — это набор готовых решений, необходимых для разработки фич. Вернемся к примеру с пуш-уведомлениями. Когда мы видим такую строчку в ТЗ, мы понимаем, что нам предстоит проделать большую работу:

  1. Настроить Firebase или другой APNS для получения пуш-уведомлений.
  2. Получить Push-токен, чтобы управлять уведомлениями со своего бэкенда.
  3. Настроить Silent Push — уведомления, которые не видны пользователю. Они помогают работать с конфигурационными вещами. Например, обновлять каунтер на иконке приложения в фоновом режиме.
  4. Обработать нажатие на уведомление пользователем.
  5. Обработать глубокие ссылки (Deeplinks) для перехода пользователя в нужный раздел приложения и работы с навигацией.
Почти все эти вещи приходится отдельно делать для каждого приложения. Но если реализовать собственный SDK, мы сократим трудозатраты.
Грубо говоря, мы будем переиспользовать те решения, которые однажды где-то внедрили. То есть нам больше не нужно писать код настройки Firebase с нуля. Нам нужно только подключить наш модуль с пушами к проекту и передать в него наш ключ проекта Firebase.

Плюсы SDK-подхода


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

Как еще мы ускоряем разработку

Само собой, выпускать продукт в сжатые сроки нам помогают не только внутренние проекты с базовой архитектурой и переиспользуемые модули. Есть еще два приема, которые мы используем.
✔ Пайплайн сборки мобильного приложения
Как правило, разработчики на ранних стадиях собирают проект руками, просто нажимают на кнопку Build и ждут несколько минут, потом исправляют баги, запускают Build и ждут ещё несколько минут.
В итоге уходит много времени. А с ростом проекта это вообще становится критичным показателем. Поэтому и существуют стандарты CI/CD. Мы тоже используем их у себя в Gitlab и для iOS- и Android-проектов. Стандартный пайплайн на нашем проекте выглядит так:

  1. Прогон линтеров (чтобы убедиться, что соблюдается Code-Style).
  2. Прогон Unit-тестов (под каждый проект мы разрабатываем определенный набор правил о том, что покрывается тестами, а что нет).
  3. Сборки нескольких вариантов проекта. Как правило, это:
  4. Тестовая сборка.Тестовая сборка, направленная на продакшен-сервер.Продакшен-релиз-сборка.
  5. Загрузка сборок в App Distribution от Firebase для Android или TestFlight для iOS.
  6. Загрузка сборок в Telegram-канал (иногда тестировщикам бывает удобнее ставить оттуда).
Таким образом, хорошо настроенный CI/CD позволяет нам достаточно серьезно сокращать время проекта целиком и не тратить фокус разработчиков на постоянную сборку проекта и передачу тестировщикам.
✔ Регламентация процесса разработки
Разработчики — это люди, которым иногда нужно помочь и которых нужно направить. При этом разработка — творческое занятие. Поэтому на наших проектах мы стараемся убрать разработчикам головную боль, связанную с процессами. Все процессы продуманы и зафиксированы, их не нужно каждый раз переизобретать.
В нашем случае главный регламент — манифест разработчика. В наш манифест входит несколько простых правил, которые описывают следующие вещи:

  1. Принципы проведения код-ревью (повышаем качество кода и минимизируем человеческий фактор).
  2. Принятый единый Code Style (разработчики пишут в одном стиле, это проверяется линтерами во время сборок).
  3. Принципы документирования кода и модулей (позволяет с легкостью проводить онбординг новым участникам команды).
  4. GitFlow — выработанный свод правил по работе с Git, который ускоряет команду и позволяет всем работать в симбиозе.
  5. Еще несколько пунктов, которые позволяют стандартизировать работу над проектами.

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

Выводы

Вот, в общем-то, и всё.

  1. Базовый проект с заранее заложенной архитектурой.
  2. Различные SDK-модули, которые можно подключать к проектам.
  3. Настроенные процессы разработки и сборки.
  4. Регламенты, которым следует команда разработчиков.
Эти понятные и простые шаги, которые в совокупности позволили нам на 30 процентов ускорить разработку. Конечно, от проекта к проекту эта цифра меняется, просчитать точное время, не имея вводных, невозможно. Но если говорить в абстрактных категориях, то, на что раньше уходило 90 дней, теперь 60 дней.
И честно говоря, мы довольны таким результатом.
На этом всё. Больше о разработке мы рассказываем в нашем телеграм-канале AGIMA Dev. А лично я делюсь своими мыслями, лайфхаками и заметками о жизни команды мобильной разработки в соцсети X.

Контент-хаб

0 / 0
+7 495 981-01-85 + Стать клиентом
Услуги Кейсы Контент-хаб