Давайте знакомиться. Меня зовут Миша Вассер, я отвечаю за мобильную разработку в AGIMA.
Мое дело — следить за качеством кода и продуктов, которые мы развиваем, помогать коллегам не факапить и настраивать процессы. С первым и вторым, кажется, понятно, а вот про процессы хочется поговорить подробнее.
Сейчас попробую описать нашу технологию разработки максимально простым языком. Это не техническая статья, на Хабре бы ее восприняли в штыки. Но моя задача — рассказать, как мы оптимизировали процесс и зачем это нужно.
Так что если вы хотите приложение как можно скорее — велком.
- Дисклеймер! Я описываю не какое-то ноу-хау и не изобретаю велосипед. Я пишу про удобный инструмент руководителя мобилки, который можно использовать, а можно нет. Мы вот используем, пока всё круто! А статья будет полезна продакт овнерам и тем, кто развивает мобильные цифровые продукты, потому что я расскажу, за счет чего приложение можно сделать быстрее и дешевле.
Пара вводных слов
Время — деньги. Для нас это буквально.
Почти на каждом проекте одна из наших главных задач — уложиться в срок. Бизнес развивается, растет, торопится, и нам нужно успевать за его потребностями. Поэтому ускорить разработку — это не самоцель, а прагматичная задача.
Чем быстрее мы сдаем проекты, тем выгоднее нам и нашим заказчикам.
Но как это ускорить? Стоять над разработчиком с кнутом и заставлять писать код день и ночь? Это не работает. Человек быстро устанет и уйдет к конкурентам. Набрать огромную команду? Это дорого и не всегда эффективно.
Остается одно: оптимизировать процесс. А дальше, как говорится, следите за руками.
Остается одно: оптимизировать процесс. А дальше, как говорится, следите за руками.
Стандартные модули
Посмотрим, как вообще всё работает. Ежедневно мы видим сотни приложений в маркетах. Каждое из них уникально: кто-то делает Ecom-проекты, кто-то занимается финтехом, а кто-то запускает стартапы в области биомедицины.
Но в то же время все приложения имеют стандартную, привычную каждому функциональность. Это те фичи, которые мы представляем, как только слышим само слово «приложение». Вот примерный список:
- Пуш-уведомления и диплинки. Маркетинговый инструмент, который помогает общаться с пользователем. А еще пуши часто используют для технических конфигураций приложения в фоне, для обновления информации и других настроек.
- Авторизация через сторонние сервисы и/или ОТР. Это нужно, чтобы составлять портрет пользователя и рекомендовать ему товары и услуги. Плюс история покупок пользователя, персонификация настроек и многое другое — всё это скрыто в профиле пользователя.
- Оплата через популярные эквайринги. Задача бизнеса — генерировать прибыль. Здорово, когда вы при этом можете упростить пользовательский путь и встроить оплату товаров прямо в приложение.
- Face ID/ Touch ID. Бизнес заботится о безопасности пользователей. Часто вход в приложение возможен только по биометрии.
- FAQ. Служба поддержки — люди, через которых ежедневно проходят сотни звонков и сообщений. Чтобы облегчить им жизнь и повысить качество продукта, многие добавляют «Часто задаваемые вопросы» в свои приложения.
- Карты. Геопозиция — функция, которая необходима разным сферам. Определение местоположения пользователя необходимо для отображения ближайшего магазина, адреса доставки и многих других вещей.
- Onboarding. Как правило, 3–4 экрана с картинкой и текстом, на которых пользователю рассказывают о самых основных фичах продукта.
- Другие функции, которые встречаются пореже :)
Сколько времени уходит на эти модули
Предположим, что мы каждый раз делаем эти функции с нуля. Во-первых, это дорого — зарплаты у команды разработки не маленькие. Во-вторых, процесс разработки не быстрый: пока напишем код, пока его проверят, пока исправим баги.
Возьмем, например, пуш-уведомления и диплинки. Какие строки могут быть в смете на разработку этого модуля:
Как правило, оценка для каждой платформы получается большой. В среднем на такой модуль уйдет полторы недели.
- Настройка пуш-уведомлений со стороны Mobile.
- Создание механизма обработки Deeplinks.
- Обработка 5–10 диплинков.
Как правило, оценка для каждой платформы получается большой. В среднем на такой модуль уйдет полторы недели.
- Важно! В зависимости от архитектуры проекта и других факторов оценка может уменьшаться или увеличиваться. Я говорю о самом среднем примере. На моей памяти самый короткий срок, за который мы реализовали похожую функциональность — 5 дней, а самый долгий — 2 недели.
Разумеется, этот срок хочется сократить.
Как автоматизировать и ускорить разработку
Я знаю два распространенных способа:
Ниже я объясню подробнее, что такое SDK.
- Использовать сторонние SDK, которые делают всё за вас. Такое решение тяжело кастомизировать, оно может не подходить по функционалу и требует дополнительного вложения денег. Кроме того, возможно, вы автоматически будете передавать данные пользователей третьей стороне.
Ниже я объясню подробнее, что такое SDK.
- Переиспользовать решения от похожих проектов, реализованных ранее. В целом, вполне неплохо. Но есть минусы: код может быть завязан под конкретный проект, в итоге его интеграция может стать почти невозможной. При копировании такого кода в нём могут появляться ошибки и несовместимость с новым проектом.
Мы пошли другим путем
Мы оценили варианты и поняли, что здорово взять плюсы обоих. Так родился проект, который мы между собой называем платформой. Платформа состоит из двух частей:
- Проект с базовой архитектурой и настроенными процессами (CI/CD и другие технические вещи). Имея такой проект, мы можем значительно сократить время на разворачивание и настройку нового проекта.
- SDK-модули с популярным функционалом, которые можно подключать отдельно. Про них далее поговорим подробнее.
Про SDK и его преимущества
SDK — это набор готовых решений, необходимых для разработки фич. Вернемся к примеру с пуш-уведомлениями. Когда мы видим такую строчку в ТЗ, мы понимаем, что нам предстоит проделать большую работу:
- Настроить Firebase или другой APNS для получения пуш-уведомлений.
- Получить Push-токен, чтобы управлять уведомлениями со своего бэкенда.
- Настроить Silent Push — уведомления, которые не видны пользователю. Они помогают работать с конфигурационными вещами. Например, обновлять каунтер на иконке приложения в фоновом режиме.
- Обработать нажатие на уведомление пользователем.
- Обработать глубокие ссылки (Deeplinks) для перехода пользователя в нужный раздел приложения и работы с навигацией.
Почти все эти вещи приходится отдельно делать для каждого приложения. Но если реализовать собственный SDK, мы сократим трудозатраты.
Грубо говоря, мы будем переиспользовать те решения, которые однажды где-то внедрили. То есть нам больше не нужно писать код настройки Firebase с нуля. Нам нужно только подключить наш модуль с пушами к проекту и передать в него наш ключ проекта Firebase.
Плюсы SDK-подхода
- Разработчик, который интегрирует 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.