Давайте знакомиться. Меня зовут Миша Вассер, я отвечаю за мобильную разработку в AGIMA.
Мое дело — следить за качеством кода и продуктов, которые мы развиваем, помогать коллегам не факапить и настраивать процессы. С первым и вторым, кажется, понятно, а вот про процессы хочется поговорить подробнее.
Сейчас попробую описать нашу технологию разработки максимально простым языком. Это не техническая статья, на Хабре бы ее восприняли в штыки. Но моя задача — рассказать, как мы оптимизировали процесс и зачем это нужно.
Так что если вы хотите приложение как можно скорее — велком.
- Дисклеймер! Я описываю не какое-то ноу-хау и не изобретаю велосипед. Я пишу про удобный инструмент руководителя мобилки, который можно использовать, а можно нет. Мы вот используем, пока всё круто! А статья будет полезна продакт овнерам и тем, кто развивает мобильные цифровые продукты, потому что я расскажу, за счет чего приложение можно сделать быстрее и дешевле.
Пара вводных слов
Время — деньги. Для нас это буквально.
Почти на каждом проекте одна из наших главных задач — уложиться в срок. Бизнес развивается, растет, торопится, и нам нужно успевать за его потребностями. Поэтому ускорить разработку — это не самоцель, а прагматичная задача.
Чем быстрее мы сдаем проекты, тем выгоднее нам и нашим заказчикам.
Но как это ускорить? Стоять над разработчиком с кнутом и заставлять писать код день и ночь? Это не работает. Человек быстро устанет и уйдет к конкурентам. Набрать огромную команду? Это дорого и не всегда эффективно.
Остается одно: оптимизировать процесс. А дальше, как говорится, следите за руками.
Стандартные модули
Посмотрим, как вообще всё работает. Ежедневно мы видим сотни приложений в маркетах. Каждое из них уникально: кто-то делает Ecom-проекты, кто-то занимается финтехом, а кто-то запускает стартапы в области биомедицины.
Но в то же время все приложения имеют стандартную, привычную каждому функциональность. Это те фичи, которые мы представляем, как только слышим само слово «приложение». Вот примерный список:
Сколько времени уходит на эти модули
Предположим, что мы каждый раз делаем эти функции с нуля. Во-первых, это дорого — зарплаты у команды разработки не маленькие. Во-вторых, процесс разработки не быстрый: пока напишем код, пока его проверят, пока исправим баги.
Возьмем, например, пуш-уведомления и диплинки. Какие строки могут быть в смете на разработку этого модуля:
Как правило, оценка для каждой платформы получается большой. В среднем на такой модуль уйдет полторы недели.
- Важно! В зависимости от архитектуры проекта и других факторов оценка может уменьшаться или увеличиваться. Я говорю о самом среднем примере. На моей памяти самый короткий срок, за который мы реализовали похожую функциональность — 5 дней, а самый долгий — 2 недели.
Разумеется, этот срок хочется сократить.
Как автоматизировать и ускорить разработку
Я знаю два распространенных способа:
Ниже я объясню подробнее, что такое SDK.
Мы пошли другим путем
Мы оценили варианты и поняли, что здорово взять плюсы обоих. Так родился проект, который мы между собой называем платформой. Платформа состоит из двух частей:
Про SDK и его преимущества
SDK — это набор готовых решений, необходимых для разработки фич. Вернемся к примеру с пуш-уведомлениями. Когда мы видим такую строчку в ТЗ, мы понимаем, что нам предстоит проделать большую работу:
Почти все эти вещи приходится отдельно делать для каждого приложения. Но если реализовать собственный SDK, мы сократим трудозатраты.
Грубо говоря, мы будем переиспользовать те решения, которые однажды где-то внедрили. То есть нам больше не нужно писать код настройки Firebase с нуля. Нам нужно только подключить наш модуль с пушами к проекту и передать в него наш ключ проекта Firebase.
Плюсы SDK-подхода
Как еще мы ускоряем разработку
Само собой, выпускать продукт в сжатые сроки нам помогают не только внутренние проекты с базовой архитектурой и переиспользуемые модули. Есть еще два приема, которые мы используем.
✔ Пайплайн сборки мобильного приложения
Как правило, разработчики на ранних стадиях собирают проект руками, просто нажимают на кнопку Build и ждут несколько минут, потом исправляют баги, запускают Build и ждут ещё несколько минут.
В итоге уходит много времени. А с ростом проекта это вообще становится критичным показателем. Поэтому и существуют стандарты CI/CD. Мы тоже используем их у себя в Gitlab и для iOS- и Android-проектов. Стандартный пайплайн на нашем проекте выглядит так:
Таким образом, хорошо настроенный CI/CD позволяет нам достаточно серьезно сокращать время проекта целиком и не тратить фокус разработчиков на постоянную сборку проекта и передачу тестировщикам.
✔ Регламентация процесса разработки
Разработчики — это люди, которым иногда нужно помочь и которых нужно направить. При этом разработка — творческое занятие. Поэтому на наших проектах мы стараемся убрать разработчикам головную боль, связанную с процессами. Все процессы продуманы и зафиксированы, их не нужно каждый раз переизобретать.
В нашем случае главный регламент — манифест разработчика. В наш манифест входит несколько простых правил, которые описывают следующие вещи:
Благодаря манифесту мы получаем команду, которая работает в едином стиле, понимает, как работают процессы и идут к единой цели. У такой команды сведены к минимуму отвлекающие факторы, а все силы идут на разработку действительно качественного продукта.
Выводы
Вот, в общем-то, и всё.
Эти понятные и простые шаги, которые в совокупности позволили нам на 30 процентов ускорить разработку. Конечно, от проекта к проекту эта цифра меняется, просчитать точное время, не имея вводных, невозможно. Но если говорить в абстрактных категориях, то, на что раньше уходило 90 дней, теперь 60 дней.
И честно говоря, мы довольны таким результатом.
На этом всё. Больше о разработке мы рассказываем в нашем телеграм-канале AGIMA Dev. А лично я делюсь своими мыслями, лайфхаками и заметками о жизни команды мобильной разработки в соцсети X.