Впервые термин «low-code» применительно к разработке программного обеспечения был упомянут аналитиками Forrester еще в 2014 году для обозначения платформ, которые делают процесс создания приложений более доступным для широкого круга разработчиков за счет упрощения процесса программирования. Для упрощения разработки в подобных платформах применяют несколько различных принципов, корнями уходящих в визуальное программирование [1], разработку на основе моделей с различными типами диаграмм, моделирование, а также управление процессами и рабочими процессами.
Классификация платформ low-code
Все платформы low-code с точки зрения итогового бизнес-приложения можно условно разделить на генераторы и интерпретаторы кода. Для первых код, сгенерированный платформой, исполняется независимо от нее, и тогда покупатель платформы не зависит от ее поставщика — сгенерированное приложение можно дорабатывать с помощью традиционных инструментов разработки с привлечением своих или внешних программистов, независимо от платформы. Интерпретаторы, по сути, представляют собой не только среду разработки, но и исполнения — итоговое приложение существовать без платформы не может.
Какой из этих подходов лучше? Очевидного ответа нет.
Платформы — генераторы кода позволяют построить самостоятельное приложение, включая все права на его исходный код, но при этом возникает сложность в разработке с точки зрения соотношения между временем разработки (design time) и временем эксплуатации (run time). Все, что создается на экране с помощью визуальных конструкторов, должно превратиться в программный код, а код, в свою очередь, должен собраться и развернуться на сервере — на все это требуются ресурсы. Хотя в современных платформах переключение между этими режимами для пользователя платформы происходит практически незаметно. Так, платформа Gravitonum принадлежит к классу генераторов кода, в котором используется фреймворк с открытым исходным кодом Quarkus, который, с одной стороны, позволяет почти мгновенно собирать проект и переключаться между режимами design-time и run-time, а с другой — существенно сокращает размер приложения и, как следствие, уменьшает требования к железу и общую стоимость проекта. Более того, фреймворк Quarkus позволяет генерировать итоговое приложение в нативном коде, что означает высокое быстродействие и экономию ресурсов. В процесс непрерывной интеграции и развертывания решения на тестовый сервер может быть встроен анализ исходного кода на наличие уязвимостей.
Возвращаясь к общему пониманию подхода low-code — сейчас нет четкого определения, какой тип приложений можно считать платформой low-code. Например, имеются системы, популярные в определенной отрасли, конкретного класса задач: ERP, CRM, ЭДО или различные порталы, снабженные визуальными инструментами для кастомизации приложения. Можно ли считать такие системы платформой low-code? В общем смысле — да, так как пользователь может обходиться минимальным кодированием. Можно ли на системе, относящейся, например, к порталам, разработать принципиально другое решение, например, ЭДО? Не всегда, в зависимости от архитектуры изначальной системы и возможностей ее адаптации к новым задачам и процессам.
Тут возникает еще один тип разделения платформ low-code. Имеются условно универсальные платформы, не завязанные на какой-то определенный тип приложений, и специализированные, позволяющие создавать решения только определенного класса, но для других решений, это, как минимум, не эффективно, а как максимум, невозможно. У каждого подхода есть свои плюсы и минусы. Например, универсальная платформа Gravitonum позволяет создавать широкий класс приложений, конкурируя с узкоспециализированными инструментами: различные конвейеры по выдаче кредитов, банковских карт, подключения услуг для бизнеса, и пр.; порталы, такие как личный кабинет сотрудника, клиента; приложения автоматизации процедур подбора персонала и адаптации новых сотрудников к работе в компании; решения класса PIM, CDP, MDM, CRM; подсистемы управления тарифами. Однако если в компании с помощью платформы создается не одно приложение, а несколько десятков, сотен или тысяч?
Тут возникает еще одно разделение — редакция платформы:
- Freemium — для частных разработчиков, которые создают небольшие приложения для личных нужд;
- Standard — вариант для создания крупномасштабного приложения, с большим количеством пользователей;
- Enterprise — вариант для корпораций, создающих большое количество высоконагруженных систем с высокими требованиями к надежности и безопасности.
Таким образом, часть платформ используется только для разработки небольшого класса систем, не критичных к производительности, надежности и безопасности, а часть платформ, например Gravitonum, позволяют создавать как небольшие приложения, так и надежные, производительные и безопасные решения для крупных предприятий.
Что под «капотом»?
За счет чего платформы позволяют быстро создавать приложения, по сравнению с традиционной разработкой, и, наконец, нужны ли традиционные разработчики при наличии подобных платформ low-code?
а первый взгляд скорость создания приложения определяется наличием визуальных инструментов, но это не совсем так. Конечно, за счет этого снижаются требования к квалификации разработчиков и появляется возможность привлекать специалистов в прикладных областях, слабо знакомых с программированием, — вместо разработчиков на Java, React и прочих языках программирования можно привлекать аналитиков. Стоимость ресурсов на проект уменьшается, а скорость разработки — необязательно. Визуальные инструменты могут быть сложны в использовании, требовать много времени на освоение, обладать ограничениями по функционалу, что, в конечном счете, может нивелировать преимущества их использования.
На скорость разработки оказывают влияние два фактора.
Сокращение жизненного цикла создания готового решения. В случае с платформой low-code техническое задание (ТЗ), в отличие от традиционной разработки, формируется в упрощенном варианте и только на какие-то действительно сложные вещи, например, алгоритм расчета каких-либо показателей на Java, а в остальном платформа является, по сути, самодокументируемой, и достаточно просто разобраться, кто, как и что именно сделал. Как следствие, минимально жизнеспособный продукт (MVP) создается за несколько дней. Кроме этого, платформа снижает требования по взаимодействию бизнеса с командой разработки — бизнесу уже не нужно погружаться в детали при формулировке своих требований. Таким образом, вместо традиционного цикла «Сбор требований» — «Согласование бизнес-требований» — «Написание ТЗ» — «Согласование ТЗ» — «Разработка» — «Тестирование» — «Приемка» — «Исправление замечаний» — «Запуск в эксплуатацию» платформа low-code сводит процесс разработки к последовательности «Анализ» — «Создание MVP» — «Тестирование» — «Запуск в эксплуатацию» — «Непрерывные улучшения».
Повторное использование предыдущих наработок. Здесь подразумевается возможность повторного использования наработок для одной системы, при создании другой: модели данных, экранных форм, различных тестов (валидации, импорты для справочников), интеграционные адаптеры. В платформе Gravitonum, например, реализован механизм пакетов, позволяющий упаковать в один блок структуру данных, экранные формы, бизнес-процессы, тесты (проверки), конверторы в различные форматы и отчетные формы, что в ряде случаев позволяет ускорить разработку. Например, если требуется функционал работы с календарями, то пользователь разворачивает пакет и автоматически получает структуру данных, пользовательские интерфейсы и конверторы календарей. Кроме этого имеется расширяемый набор готовых интеграционных адаптеров к популярным системам: Kaffka, RabbitMQ, DaData/ГАР/ФИАС, «Контур-Фокус» и др. Пользователю достаточно добавить в бизнес-процесс определенный «квадратик» и указать данные доступа.
Насколько все-таки сокращается время разработки платформой low-code? Например, использование Gravitonum позволяет в два-три раза снизить время разработки для больших проектов. Важный бонус любой платформы low-code — уменьшение времени на изменение, а учитывая, что они обычно вносятся регулярно на протяжении всего жизненного цикла приложения, это важно. Для небольших задач, например, разработка механизма опросов (задание шагов с вопросами, перечень ответов для каждого шага и пр.), время разработки может быть мизерным — 2–3 человека-дня, что достаточно сложно достичь стандартными средствами.
Разберем теперь пример разработки на платформе Gravitonum.
Группа аналитиков, проанализировав требования бизнес-заказчиков, создает в визуальном конструкторе модель данных, с учетом связей между сущностями. Процесс создания модели данных занимает в среднем 1–3 дня. При создании модели данных платформа автоматически генерирует фасады REST API и GraphQL, что позволяет начать работать с приложением еще до создания экранных форм, в том числе для импорта и экспорта данных из или в другие системы. Далее модель данных итеративно дорабатывается по мере разработки остальных компонентов приложения: экранные формы, бизнес-процессы, загрузки данных и отчетные формы. Дополнительно могут быть настроены различные события жизненного цикла (триггеры), подключен аудит данных, а также разработаны пользовательские SQL- или HQL-запросы для витрин данных или отчетных форм. Для любой сущности в модели данных могут быть заданы различные проверки (валидации), например форматно-логический контроль при импорте данных из других систем (рис. 1).
.jpg) |
| Рис. 1. Визуальный конструктор модели данных |
После создания модели данных аналитики приступают к созданию экранных форм с привязкой к созданной модели данных. Экранные формы могут быть любой сложности: одностраничные или с табуляцией, с пошаговыми помощниками («визардами») и встроенными компонентами, которые уже были разработаны ранее, в том числе и на других проектах. На рис. 2 представлен внешний вид дизайнера, с помощью которого задаются правила отображения, такие как видимость и доступность на изменение; назначаются права в зависимости от роли пользователя или шага процесса; прописываются обработчики при сохранении данных — либо стандартные, генерируемые платформой, либо уникальные для проекта, созданные разработчиком на JavaScript. Для каждого поля формы и для всей экранной формы могут быть заданы различные проверки: длина поля, контрольный разряд банковского счета или ИНН и т. п. Имеется набор масок ввода (телефон, адрес электронной почты, номер карты, СНИЛС и т. д.), а также возможность создания пользовательских масок любой сложности. Для этого имеется отдельный визуальный инструмент.
.jpg) |
| Рис. 2. Визуальный дизайнер экранных форм |
Если требуется работа с файлами, например сканами документов, то платформа поддерживает работу с S3 подобными хранилищами данных c поддержкой версионности, например с Minio или Yandex Object Storage.
.jpg) |
| Рис. 3. Визуальный редактор бизнес-процессов |
Далее аналитиками в визуальном редакторе (рис. 3) моделируются бизнес-процессы в нотации BPMN 2.0. Для шагов процесса, на которых подразумевается взаимодействие с пользователем (UserTask), указывается, какие роли могут работать на данном шаге и какая экранная форма должна быть использована. Для шагов процесса, на которых происходит взаимодействие с другими системами (ServiceTask), аналитик либо выбирает из списка готовых компонентов интеграционный шаблон для работы с конкретной системой, такой как «Контур-Фокус», СПАРК, DaData, ЕГРЮЛ, MQ, Kaffka и т. д., либо использует универсальный шаблон для вызова REST или SOAP, либо разработчик создает на Java интеграционный адаптер для данного проекта, который в дальнейшем может быть использован и в других проектах.
Если в приложении подразумевается использование данных из других систем, то платформа предоставляет визуальные конструкторы для создания конверторов данных в формате Source2Target, из файлов (csv, xls, xml) или в формате JSON для данных, полученных, например через MQ или Kaffka.
Для задач или процессов, которые должны запускаться по расписанию, в платформе есть соответствующий конструктор.
Большинство систем требует создания различных операционных и пользовательских отчетов. Платформа предоставляет конструктор, позволяющий как создавать шаблоны уведомлений для электронной почты, СМС, Telegram и Mattermost, так и разрабатывать различные отчеты, в том числе с поддержкой экспорта в форматы Word, Excel, .odt, .pdf.
Если требуется, чтобы итоговое приложение выглядело в корпоративном стиле, платформа предоставляет инструмент для «тюнинга» внешнего вида приложения в соответствии с корпоративными форматами.
***
Нужны ли разработчики, если в компании имеется платформа low-code? Да. Рутинные и не творческие, с точки зрения программистов, задачи передаются бизнес-аналитикам, которых часто называют гражданскими разработчиками (citizen developers), а сложные и нетривиальные задачи, например реализация в приложении алгоритма Монте-Карло для управления операционными рисками или разработка интеграционного адаптера для внутренней системы, делают традиционные разработчики. Подобная ситуация выгодна всем. Пользователь платформы получает не только инструмент, позволяющий ускорить разработку и снизить ее стоимость, но и возможность задействовать в своей ИТ-команде традиционные проектные роли: Архитектор, Бизнес- и Системный аналитик, Разработчик (Java и JS), Тестировщик. Кроме этого, учитывая актуальность задачи обеспечения технологической независимости, платформы low-code могут сыграть существенную роль в создании приложений для замены решений от вендоров, ушедших c рынка. Например, на базе платформы Gravitonum имеются решения для замены таких продуктов, как Microsoft Sharepoint, Oracle Siebel CRM, SAS RTDM, FICO BlazeAdvizor, Pega BPM и др.
Литература
Наталья Дубова. О роли ИТ-посредников // Открытые системы.СУБД. — 2001. — № 2. — С. 17–22. URL: https://www.osp.ru/os/2001/02/179923 (дата обращения: 21.12.2023).
Сергей Родионов (srodionov@gravitonum.com) – директор по развитию бизнеса, компания Graviton (Москва).
