Разработка и доставка ПО продолжают ускоряться, поэтому командам разработчиков нужно минимизировать узкие места на любом этапе жизненного цикла софта (software development lifecycle, SDLC). Опрошенные порталом InformationWeek эксперты советуют обратить внимание на платформы low-code и платформы для опробования новых функций.

Чтобы справляться с нарастающим давлением, вызванным ускорением циклов выпуска ПО, команды разработчиков задействуют методики Agile, DevOps и непрерывную интеграцию/доставку (CI/CD). Между тем, существуют определенные инструменты, которые позволяют повышать уровень автоматизации на протяжении всего цикла, сделав его более интеллектуальным. Каждая фаза SDLC оптимизируется шаг за шагом, скорость цикла варьируется от организации к организации. Однако по мере устранения конкретных узких мест на их место приходят новые. К числу проблем, которые задерживают доставку ПО, относятся традиционное переключение флагов функций (feature flagging) и ручное кодирование.

Переключение флагов функций vs. платформы для обкатки экспериментальных функций

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

«Современная разработка в какой-то степени нуждается в переключении флагов функций: на выходе они позволяют разделить новое ПО и новые плановые функции, которым предстоит попасть в пользовательский интерфейс. Это очень важно, потому что дает возможность отдельным командам двигаться быстрее за счет снижения взаимодействия между командами, — сказал CTO и соучредитель поставщика решений для мониторинга производительности приложений LightStep Даниэль Спунхауэр. — Иногда возможность развертывания функций для отдельной группы пользователей подается как преимущество feature flagging. С одной стороны, так оно и есть, но, с другой, это замедляет скорость разработки».

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

«Применение флагов функций — довольно странный инструмент. Клиент либо видит новую функцию, либо нет, когда она запрятана при помощи переключателя функций. В то же время платформы для экспериментов с новыми функциями гораздо более детализированы и контекстны, — считает главный специалист по продуктам и технологиям провайдера платформы low-code Quick Base Джей Джеймисон. — Оба подхода могут быть эффективными в зависимости от требований пользователя, но здесь нужно иметь в виду, что новый подход позволяет понять мотивы и изучить поведение пользователя. Остается немало причин, когда требуется прибегать к применению флагов функций, но это не исключает того, что рано или поздно, но вы захотите окунуться в новые экспериментальные платформы для ускорения инноваций в вашей компании».

Экспериментальные платформы ориентированы скорее на более широкую базу пользователей, чем на разработчиков, однако их эффективность и экономия времени резко снижается без наличия надежных процессов. В качестве целевой аудитории, которая отслеживает новые функции, привлекаются менеджеры по продуктам, задействование других категорий сотрудников, например, продавцов, считается малоэффективным. «Экспериментальные платформы облегчают владельцам продуктов понимание того, как новые функции влияют на бизнес и стоит ли их выводить на более широкую аудиторию пользователей, — сказал Рохит Джайнендра, генеральный директор и вице-президент по IT Business Management and DevOps ITSM-провайдера ServiceNow. — Хотя они и не ускоряют доставку ПО, на зато приносят понимание того, как пользователи воспримут нововведения. В то же время применение флагов функций всегда ограничивалось кругом разработчиков, которые отвечают за техническую реализацию, что никак не отвечает нуждам бизнеса».

Кодирование вручную vs. low-code

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

«У GCP, AWS, Azure, Box, Dropbox и других сервисов есть библиотеки, модули или программы, которые можно подключить к своим разработкам. Больше нет необходимости писать промежуточное ПО, — сказал CIO провайдера по предоставлению услуг интеллектуальной э-почты Black Pearl Mail Майк Гуггермос. — Современная сборка — это скорее гордость за удачную комбинацию готовых модулей, которым придали уникальную форму, а не написание фрагмента кода для автоматического подключения к Slack».

Многие разработчики рассматривают инструменты low-code как игрушечные решения, пригодные лишь для универсальных задач, однако это неправильная точка зрения. На рынке имеются платформы low-code для бизнес-пользователей, веб-разработчиков и профессиональных разработчиков. Всего Gartner насчитала 200 поставщиков low/no-code.

Инструменты low-code и даже некоторые инструменты no-code обеспечивают легкий доступ к окну командной строки, потому что по мере достижения зрелости приложений, построенных с помощью этих инструментов, они неизбежно нуждаются в пользовательских функциях или интеграции, которая превышает возможности платформы или человека, первоначально написавшего приложение.

Несмотря на отчасти пренебрежительное отношение, компании из различных сфер промышленности все чаше прибегают к low-code, чтобы на порядок ускорить процесс разработки, создавая приложения корпоративного класса не за годы, а месяцы, которые к тому же обновляются за считанные минуты. В итоге на выходе у них получается минимально жизнеспособный продукт (minimally viable product, MVP) в максимально сжатые сроки. Большинство известных поставщиков ПО не использует инструменты low-code, но появился целый класс стартапов, которые замыкают на платформе low-code весь свой бизнес, по крайней мере, на начальном этапе.

Однако даже low-code может привести к проблемам, особенно если необходимо переписать приложение. «Проекты с применением low-code лучше всего подходят тем компаниям, которые предъявляют ограниченные требования к разработке программ с расчетом, что они не потребуют дополнительной доработки. Таким образом, в отличие от написания кода вручную low-code ускоряет создание софта, но он также создает значительные препятствия, когда вам нужно сделать что-то нестандартное», — сказал главный консультант фирмы по разработке программного обеспечения Improving.com Марк Рунион.

Некоторые платформы позволяют плавно переходить от первоначального состояния приложения к более поздней версии — она может быть более кастомизированной и наверняка более сложной, поэтому первоначальное время, затраченное на разработку или прототипирование, не теряется. Однако, чтобы провести переход с одного состояния в другое, платформа должна быть решением корпоративного класса, поскольку платформы low/no-code совместимы частично или совсем не совместимы друг с другом.

Выводы

Организации продолжают наращивать темп выпуска ПО, а это значит, что им необходимо постоянно выявлять препятствия, которые замедляют процесс разработки. Как и любые другие функции в SDLC, программная разработка уже созрела для трансформации. В связи с этим организациям нужно найти пути улучшения ее эффективности, но не жертвовать при этом пользовательским опытом и качеством. В качестве помощников предприятия могут прибегнуть к помощи платформ low-code и платформам для экспериментов с новыми функциями.