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

Руководитель мобильной разработки AGIMA Михаил Вассер на пальцах объясняет, как уложиться в срок, когда дедлайн завтра.

Давайте знакомиться. Меня зовут Миша Вассер, я отвечаю за мобильную разработку в AGIMA.

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

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

Так что если вы хотите приложение как можно скорее — велком.

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

Время — деньги. Для нас это буквально.

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

Чем быстрее мы сдаем проекты, тем выгоднее нам и нашим заказчикам.

Но как это ускорить? Стоять над разработчиком с кнутом и заставлять писать код день и ночь? Это не работает. Человек быстро устанет и уйдет к конкурентам. Набрать огромную команду? Это дорого и не всегда эффективно.

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

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

Но в то же время все приложения имеют стандартную, привычную каждому функциональность. Это те фичи, которые мы представляем, как только слышим само слово «приложение». Вот примерный список:

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

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

Возьмем, например, пуш-уведомления и диплинки. Какие строки могут быть в смете на разработку этого модуля:

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

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

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

Разумеется, этот срок хочется сократить.

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

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

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

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

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

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

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

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

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

Грубо говоря, мы будем переиспользовать те решения, которые однажды где-то внедрили. То есть нам больше не нужно писать код настройки Firebase с нуля. Нам нужно только подключить наш модуль с пушами к проекту и передать в него наш ключ проекта Firebase.

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

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

✔ Пайплайн сборки мобильного приложения

Как правило, разработчики на ранних стадиях собирают проект руками, просто нажимают на кнопку Build и ждут несколько минут, потом исправляют баги, запускают Build и ждут ещё несколько минут.

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

Прогон линтеров (чтобы убедиться, что соблюдается Code-Style).
Прогон Unit-тестов (под каждый проект мы разрабатываем определенный набор правил о том, что покрывается тестами, а что нет).
Сборки нескольких вариантов проекта. Как правило, это:
Тестовая сборка.Тестовая сборка, направленная на продакшен-сервер.Продакшен-релиз-сборка.
Загрузка сборок в App Distribution от Firebase для Android или TestFlight для iOS.
Загрузка сборок в Telegram-канал (иногда тестировщикам бывает удобнее ставить оттуда).

Таким образом, хорошо настроенный CI/CD позволяет нам достаточно серьезно сокращать время проекта целиком и не тратить фокус разработчиков на постоянную сборку проекта и передачу тестировщикам.

✔ Регламентация процесса разработки

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

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

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

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

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

Базовый проект с заранее заложенной архитектурой.
Различные SDK-модули, которые можно подключать к проектам.
Настроенные процессы разработки и сборки.
Регламенты, которым следует команда разработчиков.

Эти понятные и простые шаги, которые в совокупности позволили нам на 30 процентов ускорить разработку. Конечно, от проекта к проекту эта цифра меняется, просчитать точное время, не имея вводных, невозможно. Но если говорить в абстрактных категориях, то, на что раньше уходило 90 дней, теперь 60 дней.

И честно говоря, мы довольны таким результатом.

На этом всё. Больше о разработке мы рассказываем в нашем телеграм-канале AGIMA Dev. А лично я делюсь своими мыслями, лайфхаками и заметками о жизни команды мобильной разработки в соцсети X.

7 комментариев

Evgeniya Ivanova

21.08.2023

Миш, классная статья получилась. =)

Ответить

Любовь Сотникова

В дальнейшем хочу создать собственное приложение, вот про "быстро" полезно, а вот "дешевле" - не очень хочется)), хочется наоборот вложиться хорошенько, и не думать, что теперь кошелек жмет))