Как мы ускорили мобильную разработку на 30% — делимся системой

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

Мы нашли рабочее решение. В этой статье — обзор подхода, который позволяет ускорять запуск мобильных продуктов до 30%. Без «чудес», но с чёткими системами, переиспользуемыми модулями и налаженными процессами. Делимся опытом, который может быть полезен продактам, разработчикам и тем, кто руководит мобильными направлениями.

Время — это ресурс, который нельзя терять

На любом коммерческом проекте одна из ключевых задач — уложиться в сроки. Бизнес не стоит на месте: запускаются акции, выходят обновления, меняются законы. Если команда разработки не успевает адаптироваться — страдает результат.

Однако попытки ускорить работу «в лоб» — за счёт переработок или расширения команды — редко приводят к стабильному результату. Мы пошли другим путём: оптимизировали сам процесс.

Одинаковые фичи в разных приложениях

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

• Пуш-уведомления и диплинки
• Авторизация (в том числе через сторонние сервисы или OTP)
• Интеграция с системами оплаты
• Биометрия (Face ID / Touch ID)
• FAQ и справочная информация
• Интеграция с картами
• Онбординг-экраны

Эти блоки повторяются из проекта в проект. Каждый раз реализовывать их с нуля — долго, дорого и неэффективно. Например, модуль с пушами и диплинками может занимать от 5 до 14 дней разработки на каждую платформу. А если таких модулей — не один? Значит, задача — сократить время без потери качества.

Как мы автоматизировали процесс

Существуют два распространённых подхода:

• Использование сторонних SDK
  Решение простое, но не всегда гибкое. Ограниченные возможности кастомизации, зависимость от стороннего разработчика, возможная передача пользовательских данных третьим лицам.
• Копирование кода с других проектов
  Часто оказывается проблемным: код может быть «зашит» под конкретную архитектуру, его сложно поддерживать и адаптировать. Появляется множество мелких багов при интеграции.

Мы выбрали третий путь — разработали собственную внутреннюю платформу, которая включает:

• Базовый проект с архитектурой и готовыми настройками (CI/CD, окружение, линтеры и пр.)
• Набор SDK-модулей, в которых реализованы самые частые фичи

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

Как работает наш SDK

SDK — это модуль, в котором «упакованы» повторяющиеся блоки функциональности. Например, SDK пуш-уведомлений и диплинков включает:

• Настройку Firebase или APNS
• Получение push-токенов
• Обработку silent push-сообщений
• Реализацию deeplink-навигации
• Обработку нажатий по уведомлениям

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

Преимущества подхода:

• Меньше багов — модули протестированы заранее
• Ускорение старта — подходит и для поддержки существующих проектов
• Расширяемость — SDK постоянно обновляется нашей внутренней командой

Ускорение не только за счёт SDK

Кроме платформы и модулей, на скорость разработки влияют два дополнительных фактора.

✔ Отлаженный CI/CD пайплайн

Процесс ручной сборки отнимает массу времени — особенно на масштабных проектах. Поэтому у нас внедрены стандарты CI/CD, автоматизирующие следующие этапы:

• Проверка code style с помощью линтеров
• Прогон unit-тестов
• Сборка разных версий (тестовая, на прод-сервер, релизная)
• Загрузка в Firebase App Distribution / TestFlight
• Публикация сборок в закрытых каналах для команды

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

✔ Чёткий регламент работы

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

• Правила код-ревью
• Единый code style и линтеры
• Принципы документирования кода
• GitFlow и правила ветвления
• Стандарты взаимодействия внутри команды

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

Результат: реальная экономия времени

В итоге мы пришли к системе, которая позволяет:

• Быстро стартовать новые проекты
• Сокращать трудозатраты на стандартные модули
• Снижать количество багов
• Увеличивать предсказуемость сроков

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

Итог

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

• Готовая архитектура
• Повторно используемые SDK-модули
• Автоматизация сборки
• Стандартизация командной работы

Такой подход работает у нас — и вполне может сработать у других. Если вы развиваете мобильные продукты, возможно, какие-то идеи из этой статьи окажутся полезны и вам.