Как я могу обеспечить безопасность и стабильность быстро разрабатываемых приложений?
Убедитесь, что ваша команда разработчиков следует лучшим практикам безопасного кодирования и проводит регулярные аудиты безопасности. Внедрите надежные процессы тестирования, включая функциональное тестирование, тестирование производительности и тестирование безопасности, для выявления и устранения любых уязвимостей. Регулярные обновления и проактивный мониторинг производительности приложения необходимы для поддержания стабильности и своевременного решения любых проблем.
Можно ли использовать платформу без кода, такую как AppMaster, для быстрой разработки приложений?
Да, платформа , такая как , может стать отличным инструментом для быстрой разработки приложений. Платформы позволяют пользователям создавать приложения без необходимости использования традиционных языков программирования или навыков кодирования. предлагает удобный интерфейс и визуальную среду разработки, которая упрощает процесс создания приложений.
Ускоряем процесс разработки сложных проектов. Без хаоса и нервов
Время на прочтение
На практике мы часто сталкиваемся с тем, что руководитель проекта хочет ускорить процесс разработки — его не устраивает скорость поставки нового функционала. Как правило такие клиенты нуждаются в сложных продуктах вроде системы управления госпиталем, системы торговли на бирже, банковских системах, ДБО.
В таких случаях можно подключить новую команду специалистов, наладить процессы в уже существующей или объединить и то, и другое. Рассмотрим, какие плюсы и минусы есть у каждого подхода. Сразу оговоримся, что в статье рассматривается разработка крупных и сложных проектов (больше 10 000 часов).
Почему нельзя сразу подключать новых специалистов
Часто самый простой и очевидный вариант увеличения скорости разработки — подключить новых специалистов или команду. Руководителю проекта кажется, что так можно ускорить скорость доставки business-value до конечных пользователей. На практике такое получается не всегда, особенно когда процессы в проекте требуют переработки. Приведем один пример из нашей практики.
Необходимо было подключить две команды к существующему развивающемуся проекту. Проект разрабатывался более 4-х лет и содержит большое количество подсистем (более 20) со своими общими механизмами и сервисами. Полный регресс требовал участия 5-7 QA инженеров и около 4-6 рабочий дней. При вхождении в проект и выхода команд на необходимый уровень решения задач столкнулись со следующими сложностями:
Результатом вышеописанных нюансов являются:
Рассмотрим как можно избежать подобной ситуации.
Анализ процессов
Прежде чем подключать новых специалистов, стоит разобраться, как устроена работа команды — необходимо найти и устранить «узкие» места. Обычно этим вопросом занимается PM, так как он отвечает за проект, и именно ему хочется тратить меньше сил на отслеживание процессов.
Устранение «узких» мест двигает проект вперед. К примеру, сокращается время на вхождение в проект нового специалиста или команды специалистов, повышается вовлеченность команды в проект, уменьшается стоимость часа за счет правильной реализации задач с первого раза. Если убрать все «узкие» места руководитель проекта получит настолько быстрый прирост к скорости разработки, насколько позволяют текущие практики и контекст проекта. В общем, всем от этого хорошо.
Анализ «узких мест» возможен с двух сторон: со стороны топ-менеджмента/эксперта и со стороны команды. Разберем каждый вариант отдельно.
Сторонние эксперты. В данном подходе, процесс работы анализирует либо внешняя команда внешних экспертов, либо руководитель проекта совместно с тимлидом. С последними не факт что получится — важно, чтобы они могли отбросить все нюансы проекта, иначе анализ будет бессмысленным.
Важное условие — поддержка руководства проекта и готовность к изменениям.
Соответственно, эксперт погружается в проект и подробно анализирует документацию, исходный код, структуру БД, производственный процесс (от проведения аналитики до релиза). Поэтапно работа выглядит так:
Плюсы данного подхода:
Со стороны команды. Этот подход можно назвать ретроспективой, которая является неотъемлемой частью в scrum. Процесс выглядит так:
Если культура компании не поощряет инициативность, нововведения, то ретроспектива не лучший способ переработать процессы. Участники команды не будут выходить за рамки своего «болота».
В большинстве случаев можно обойтись адаптацией и совершенствованием процессов, о которых написано выше. Даже если первоначально видно, что действительно проект возможно завершить в намеченные сроки только привлечением новых специалистовкоманд настоятельно рекомендуем попробовать выполнить шаги выше.
Если же после устранения «узких» мест, руководитель проекта считает, что capacity не достиг нужного уровня, то можно подключать новые команды.
Подготовка инфраструктуры для новых команд
На этом этапе стоит провести подготовительные работы, которые сократят длительность и стоимость разработки, помогут сохранить нервные клетки разработчиков. Рассмотрим какими должны быть условия:
Вышеперечисленные условия позволяют подключать новые команды наиболее эффективно. Время, которое требуется команде на вхождение в проект заметно снижается. Тоже самое происходит и с трудозатратами на поддержку и развитие проекта.
Как мы подключали дополнительную команду на проект
У нас был кейс когда в проекте нужно было срочно ускорить процесс разработки. До сдачи очередной мажорной версии в промышленную эксплуатацию оставалось 2-3 месяца. Сам проект представлял собой сложную систему, которая разрабатывалась одной командой в течение 3-4 лет.
В первую очередь, мы погрузились в контекст самого проекта. В результате получилась следующая картина самых узких мест проекта:
После анализа, мы создали план по устранению описанных выше пунктов. Конечно, коллектив не сразу согласился с изменениями, но с поддержкой руководства и выработкой четких сроков, мы смогли уговорить каждого члена команды.
Согласовали наши действия с ключевыми лицами проекта: PM, тимлидом, ведущим аналитиком. Вместе, эти три человека представляют собой единый центр управления командами на стороне заказчика. Они дополнительно продвигают решения и контролируют их внедрение на практике. Без такого такой управленческой команды невозможно координировать действия более трех команд.
В результате внедрилиоптимизировали следующие процессы:
По результатам первой итерации мы подготовили инфраструктуру для подключения новой команды. Параллельно с этим, двое наших разработчиков подключились к текущей команде для погружения в кодовую базу. Затем один из них стал тимлидом новой команды. На второй итерации двумя командами были достигнуты следующие результаты:
Считаю, что одно из самых важных достижений этого проекта — радость клиента. Он прозрачно представлял состояние проекта в любой момент времени, а обязательства перед бизнесом были выполнены в полном объеме и в оговоренные сроки.
Заключение
Основных способов увеличения скорости разработки проектов два: устранить «узкие» места и увеличить производственные мощности. В первом случае можно получить 30-40% прироста скорости разработки, во втором 70-80%. Дополнительные команды не дают двойного прироста производительности, поскольку больше времени тратится на взаимодействие между несколькими командами.
Ключевыми факторами успеха расширения разработческих команд являются:
Над проектом, который мы описывали ранее, сейчас работает 3 команды ( одна старая и две новых). Количество выполняемых задач увеличилось в 1,9 раз.
Про SDK и его преимущества
SDK — это набор готовых решений, необходимых для разработки фич. Вернемся к примеру с пуш-уведомлениями. Когда мы видим такую строчку в ТЗ, мы понимаем, что нам предстоит проделать большую работу:
Почти все эти вещи приходится отдельно делать для каждого приложения. Но если реализовать собственный SDK, мы сократим трудозатраты.
Грубо говоря, мы будем переиспользовать те решения, которые однажды где-то внедрили. То есть нам больше не нужно писать код настройки Firebase с нуля. Нам нужно только подключить наш модуль с пушами к проекту и передать в него наш ключ проекта Firebase.
Как непрерывная интеграция и развертывание помогают в RAD?
Непрерывная интеграция и развертывание (CI/CD) подразумевают интеграцию изменений кода и регулярное развертывание обновлений приложения. C I/CD помогает выявлять ошибки на ранней стадии, сокращает ручное тестирование, обеспечивает плавное развертывание и предоставляет конечным пользователям последовательные и актуальные приложения.
Мерж реквесты. Важен каждый голос
Платформа дает нам площадку и подспорье для экспериментов. Так что по просьбам пользователей мы сделали на платформе возможность настроить кастомные правила для Merge Request (MR) на ветку/группы веток в проекте. Вдохновлялись тем, как это устроено в Gitlab Premium, но добавили кое-что от себя, например, регулярные выражения для настройки правил и более гибкие политики для указания конкретных «аппруверов».
Правило представляет из себя:
Как это выглядит:
Мерж-реквесты на платформе
На платформе транслируется информация из Gitlab:
Со стороны Gitlab это выглядит как дискуссия, блокирующая MR:
Каковы некоторые лучшие практики для оптимизации разработки мобильных приложений?
Некоторые лучшие практики для оптимизации разработки мобильных приложений включают разбиение проектов на более мелкие задачи, определение приоритетов функций, повторное использование кода и компонентов, автоматизацию повторяющихся задач, проведение регулярных обзоров и постоянное совершенствование.
Стратегии эффективного внедрения быстрой разработки приложений
Для компаний, стремящихся ускорить рост за счет использования быстрой разработки приложений, необходимо принять следующие стратегии:
Преимущества быстрой разработки приложений для роста бизнеса
Быстрая разработка приложений дает бизнесу множество преимуществ, которые способствуют ускоренному росту и общему успеху. Некоторые ключевые преимущества включают:
Повышение производительности
С помощью платформ и инструментов RAD команды могут сократить время, затрачиваемое на ручное кодирование, и сосредоточиться на создании приложений более высокого качества. В результате компании могут быстрее выводить продукты на рынок, повышая свою конкурентоспособность в отрасли и увеличивая общую производительность.
Снижение затрат
Упрощая процесс разработки приложений и ускоряя время выхода на рынок, быстрая разработка приложений помогает снизить затраты, связанные с разработкой и внедрением. Кроме того, использование инструментов и позволяет нетехническим сотрудникам вносить свой вклад в разработку, что позволяет организациям сократить расходы, обычно связанные с наймом специализированных специалистов.
Ускоренное время выхода на рынок
С помощью RAD компании могут оптимизировать процесс разработки, что позволяет им завершать проекты за долю времени, требуемого традиционными методами. Ускоренное время выхода на рынок позволяет организациям быстрее реагировать на запросы клиентов и рыночные возможности, создавая конкурентное преимущество, которое стимулирует рост.
Адаптивные и гибкие решения
Одним из значительных преимуществ быстрой разработки приложений является присущая ей адаптивность и гибкость. Приложения, разработанные с использованием методологии RAD, могут быть легко обновлены и адаптированы в соответствии с меняющимися условиями рынка, отзывами клиентов или новыми знаниями, что делает этот подход важным для организаций, стремящихся сохранить конкурентное преимущество.
Оптимизированная совместная работа
Платформы быстрой разработки приложений часто оснащены мощными инструментами для совместной работы, позволяющими членам команды работать вместе в режиме реального времени и оптимизировать общение. Улучшение совместной работы приводит к более эффективному принятию решений, ускорению итераций и, в конечном итоге, к более качественным приложениям, отвечающим потребностям пользователей.
Стимулирование инноваций
Быстрая разработка приложений позволяет предприятиям быстрее и эффективнее внедрять инновации, что дает им возможность оставаться впереди в конкурентной среде. Способствуя ускорению цикла разработки, платформы RAD позволяют организациям исследовать новые идеи, разрабатывать прототипы и проводить итерации своих продуктов быстрее, ускоряя рост и присутствие на рынке.
Что делать, чтобы ускорить процесс разработки?
Постарайтесь понять, какие элементы приложения связаны с главной идеей вашего проекта.
— Экраны каталога тренировок? Да.
— Поп-ап с приветствием и комплиментом? Нет, выкидываем.
— Красивая страница 404? Да, возможно.
— Анимация на счётчике товаров в корзине? Вряд ли. Убираем.
и т. д.
Делать красиво и быть внимательным к деталям — это здорово. Но иногда чем-то приходится жертвовать, чтобы не потерять ещё больше.
Сколько времени уходит на эти модули
Предположим, что мы каждый раз делаем эти функции с нуля. Во-первых, это дорого — зарплаты у команды разработки не маленькие. Во-вторых, процесс разработки не быстрый: пока напишем код, пока его проверят, пока исправим баги.
Возьмем, например, пуш-уведомления и диплинки. Какие строки могут быть в смете на разработку этого модуля:
Как правило, оценка для каждой платформы получается большой. В среднем на такой модуль уйдет полторы недели.
Важно! В зависимости от архитектуры проекта и других факторов оценка может уменьшаться или увеличиваться. Я говорю о самом среднем примере. На моей памяти самый короткий срок, за который мы реализовали похожую функциональность — 5 дней, а самый долгий — 2 недели.
Разумеется, этот срок хочется сократить.
Традиционные подходы к разработке мобильных приложений
Традиционные подходы к разработке мобильных приложений обычно подразумевают написание кода для каждой платформы и функции с нуля. Этот трудоемкий процесс сопряжен с различными проблемами и ограничениями. К основным недостаткам традиционных подходов к разработке относятся:
Преодоление этих проблем требует инновационных подходов и инструментов, которые способствуют повышению эффективности и сокращению времени цикла разработки. Платформы и стали популярным решением для ускорения разработки мобильных приложений и устранения многих ограничений традиционных методов.
Квест. Найди 10 Отличий
Итак, первая из нашего сегодняшнего топа, необычная, и уже незаменимая для команд фича – сравнение окружений от dev до prod.
Только представьте, у вас есть полигон, которым пользуется команда разработки, полигон для автотестов, полигон для интеграционных тестов, для нагрузочных, пре-прод, и, наконец, сам prod. В процессе поставки зачастую членам команды нужно быстро сравнить окружения. Какие есть варианты? Зайти в кубера и сравнить глазами. Да, но уйдет очень много времени. Второй вариант – сравнить yaml-манифесты репозиториев, являющихся частью GitOps-процесса. Да, но там не вся необходимая информация, а только версии helm-чартов. В любом случае, уйдет много времени на нецелевую работу команды. Эту проблему мы решили с помощью инструмента для мониторинга и сравнения окружений. Почему не использовали готовое решение? Инструментов для мониторинга k8s множество, но вот настолько кастомных нет. Наиболее часто используется именно сравнение по версиям сервисов, но также есть возможность сравнить версии любых объектов k8s (deployment, ingress, replicaSet и т.д.), helm-чартов. При этом мы не показываем секреты или увствительную информацию, а лишь отмечаем наличие расхождений.
Кстати, само сравнение можно проводить как в режиме «помониторить один полигон», так и сравнивать неограниченное количество полигонов между собой. А отличия подсвечиваются, чтобы точно не пропустить.
Сравнение тестовых полигонов
Когда может понадобиться ускоренная разработка?
Представим ситуацию: вы хотите делать фитнес-приложение с планами тренировок для разных сегментов аудитории: женские, мужские, универсальные и для людей с физическими ограничениями.
Тут возможны два сценария:
Вот только вы плохо понимаете, насколько сейчас востребованы онлайн-тренировки и для кого их лучше писать: для женской аудитории, мужчин или захватить всех сразу?
В первом случае можно делать приложение на коде: вы уверены, что у идеи не истечёт срок годности и в нишу можно будет попасть в любом случае — через месяц, три или девять. А можно взять и No/LowCode — они вполне подойдут для подобного проекта. Рекомендуем почитать нашу статью о том, какие ещё приложения можно делать на NoCode.
Вы приступаете к покорению золотых вершин онлайн-фитнеса: нашли команду разработчиков, объяснили идею, дали пожелания по нюансам функционала и интерфейса. Команда работает: сделали прототип, построили навигационную цепочку, «нарастили мышцы» — оплату членства,
И вдруг происходит следующее.
Вы провели custdev и увидели, что спрос на силовые тренировки значительно упал, и ваш продукт оказался практически никому не нужен: всем стала интересна йога. А приложение — вот оно, уже практически готовое у вас на руках.
Выходит, что придётся переделывать всё практически с нуля или значительно корректировать проект, а сроки (и ваш карман, вероятно, тоже) начинают гореть.
Как еще мы ускоряем разработку
Само собой, выпускать продукт в сжатые сроки нам помогают не только внутренние проекты с базовой архитектурой и переиспользуемые модули. Есть еще два приема, которые мы используем.
✔ Пайплайн сборки мобильного приложения
Как правило, разработчики на ранних стадиях собирают проект руками, просто нажимают на кнопку Build и ждут несколько минут, потом исправляют баги, запускают Build и ждут ещё несколько минут.
В итоге уходит много времени. А с ростом проекта это вообще становится критичным показателем. Поэтому и существуют стандарты CI/CD. Мы тоже используем их у себя в Gitlab и для iOS- и Android-проектов. Стандартный пайплайн на нашем проекте выглядит так:
Таким образом, хорошо настроенный CI/CD позволяет нам достаточно серьезно сокращать время проекта целиком и не тратить фокус разработчиков на постоянную сборку проекта и передачу тестировщикам.
✔ Регламентация процесса разработки
Разработчики — это люди, которым иногда нужно помочь и которых нужно направить. При этом разработка — творческое занятие. Поэтому на наших проектах мы стараемся убрать разработчикам головную боль, связанную с процессами. Все процессы продуманы и зафиксированы, их не нужно каждый раз переизобретать.
В нашем случае главный регламент — манифест разработчика. В наш манифест входит несколько простых правил, которые описывают следующие вещи:
Благодаря манифесту мы получаем команду, которая работает в едином стиле, понимает, как работают процессы и идут к единой цели. У такой команды сведены к минимуму отвлекающие факторы, а все силы идут на разработку действительно качественного продукта.
Как менеджеры проектов могут обеспечить оптимальное распределение ресурсов для разработки мобильных приложений?
Руководители проектов могут оптимизировать распределение ресурсов путем определения четких целей, эффективного распределения задач, мониторинга прогресса, поощрения сотрудничества, а также выявления и устранения потенциальных узких мест и проблем в цикле разработки.
Безопасное проникновение в контур
Вот уже более полутора лет мы живем в условиях новой реальности и предпочитаем находиться в позиции недоверия: доступ в публичный интернет ограничен из внутренней сети. Процесс получения зависимостей, артефактов из интернета, обновления библиотек у нас был довольно сложным с точки зрения времени ожидания и количества задействованных людей.
Радости такой процесс, конечно же, не приносит, силы отнимает, поэтому на платформе мы сделали сервис безопасной загрузки артефактов из интернета.
Пользователь выбирает тип артефакта, заполняет заявку в диалоговом окне, после чего запускается процесс загрузки пакетов в карантин. Строится дерево зависимостей, проверяется наличие файлов во внутренних репозиториях, осуществляется проверка контрольных сумм. После чего заказчик подтверждает, что ему нужны именно эти артефакты. Далее скачанные файлы и отчет отправляются на проверку команде информационной безопасности.
Заявка на получение артефактов
Созданные заявки отображаются на платформе, можно посмотреть, проверить статус, отменить.
Этим сервисом мы постарались снять нагрузку с дежурных, разгрузить ИБ. Сам по себе процесс ускорить, исключив, где возможно, человеческий фактор, ожидание, автоматизировав ручные действия. Избавились от ситуации с повторными запросами пользователей, когда не догрузили транзитивные зависимости, проект не собирается, человек возвращается и по новой ждет проверки новых пакетов.
Может возникнуть вопрос, почему этот сервис располагается на платформе с UI, а не вызывается только через API с ПК разработчика. Мы считаем, что, заполняя сперва диалоговую форму, человек сильнее задумывается о вопросах безопасности и необходимости использования того или иного пакета. То есть он понимает свою причастность к тому или иному выбранному артефакту. А когда этот процесс полностью скрыт от него, то ответственность смещается на всех, кроме самого разработчика.
В планах по развитию этого сервиса прикрутить к процессу скачивания и первичной проверки различные DevSecOps инструменты.
Платформа – это также про постоянное улучшение DevExp, про прозрачность и избавление от узких мест в виде процессов и людей.
Конечно, у нас были ошибки. Во-первых, в самом начале пути мы выпускали фичи, которые, как нам казалось, будут наиболее полезны для команд, вместо проведения аудита и сбора реальных запросов и потребностей. А также мы начинали разрабатывать новый функционал сразу в «чистовом виде» без PoC. Тратили много ресурсов, не имея уверенности, взлетит фича или нет. Так что, хозяйке на заметку, самое главное – решать реальные проблемы, устранять реальные боли разработчиков, то есть общаться, спрашивать, проводить аудит, собирать обратную связь и статистику использования.
Нет единого рецепта для всех, нет двух одинаковых платформ, но определенные подходы и идеи можно и нужно пробовать внедрять. Это были пять наиболее любопытных и необычных возможностей и сервисов нашей внутренней инженерной платформы, которыми хотелось поделиться с миром. Главное, что эти фичи экономят нам время, силы, ресурсы и сокращают TTM. И самое-самое главное, ключевой фактор успеха – это наша большая сплоченная команда настоящих профессионалов, без которых ничего этого невозможно было бы построить и развивать!
Мы искренне уверены, что инвестиции в команду и в людей – это основной фактор успеха.
В следующих статьях расскажем о других возможностях нашей платформы, а пока пишите в комментариях, если стоит подробнее осветить какую-то из представленных фич.
В качестве эпилога
Подытоживая всё вышесказанное, хочется отметить, что мы прошлись, так сказать, «по верхам», и «за кулисами» осталось множество других интересных вопросов: паттерны проектирования (как минимум, тот же самый MVC, в рамках Spring, раз уж мы заговорили о нём), структуры данных, способы оптимизации, гибкие методологии разработки и прочее прочее прочее. Но это уже потянет на целую книгу, а не на статью 🙂
Если попытаться выделить самое главное, то, наверное, имеет смысл на первое место поставить всё-таки эрудицию, так как наверняка у каждого найдётся как минимум 1-2 истории, когда изученные впрок технологии и подходы, неожиданно пригодились. Если бы ещё в сутках времени было чуть больше, чем 24 часа.
Конкурс статей от RUVDS. COM. Три денежные номинации. Главный приз — 100 000 рублей.
