Инструменты Low-code как для гражданских, так и профессиональных разработчиков позволяют создавать похожие приложения, но опыт работы с ними несколько отличается. Дело в том, что последним требуется расширенный функционал — доступ к коду, возможности командной разработки, модульность и др., пишет на портале The New Stack Шей Шмельцер, директор по управлению продуктами Oracle для облачной разработки.

Инструменты Low-code продолжают развиваться и уже могут поддерживать более сложные приложения. Что характерно, ими пользуются не только так называемые гражданские, но и профессиональные разработчики. Более того, число последних стремительно растет. Но эти две группы пользователей не будут удовлетворены одним и тем же набором функций. Некоторые инструменты разработки Low-code (например, Salesforce и Zoho) возникли как инструменты для бизнес-пользователей; другие (Outsystems и Oracle) — нацеливались на разработчиков. Хотя типы приложений, которые создаются с помощью каждого из них, могут выглядеть одинаково, важную роль в опыте разработки играют различия в их применении.

Low-code действительно повышает продуктивность работы, но у профессиональных разработчиков более высокие ожидания к платформе, чем у бизнес-пользователи, — они основаны на лучших практиках, выработанных годами. Мы испытали это на собственной команде разработчиков, когда они перешли на Low code-платформу Oracle для создания SaaS-приложений. Основываясь на нашем опыте, мы хотели бы поделиться советами, которые могут помочь вашей команде разработчиков гладко внедрить Low-code корпоративного масштаба.

1. Прямой доступ к коду

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

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

Проверьте, делает ли используемая вами платформа код макета страницы и визуализации бизнес-логики доступным и изменяемым. Позволяет ли она разработчикам кодировать напрямую? Использует ли она стандартные языки, такие как JavaScript и HTML, для внесения изменений? Могут ли разработчики расширять функциональность как на уровне пользовательского интерфейса, так и на уровне бизнес-логики?

2. Командная разработка и CI/CD

Ищите инструменты Low-code, которые интегрируют и поддерживают возможности, позволяющие осуществлять разработку на основе методологии agile, которую так полюбили разработчики. К ним относятся управление версиями на основе git для совместной командной разработки, возможность автоматизации тестирования, аудит кода и создание конвейеров CI/CD для ускорения доставки изменений. Например, проверьте, могут ли разработчики напрямую генерировать автоматизированные тесты для бизнес-логики, которая была разработана декларативным способом, и как они будут сочетаться с такими практиками, как разработка на основе тестирования.

3. Модульность

При создании приложений масштаба предприятия инструменты Low-code должны поддерживать работу нескольких разработчиков над одним и тем же приложением — и во многих случаях над одними и теми же страницами — одновременно. Ваш инструмент должен уменьшать количество ситуаций, когда изменения одного разработчика могут конфликтовать с изменениями другого. Именно здесь в игру вступает модульность. Устранить конфликты помогает разбиение большой страницы на области, которые можно разрабатывать независимо друг от друга, а затем объединить в целостное решение. Здесь имеются в виду микросервисы, а не монолитные решения.

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

4. Отраслевые стандарты

Большинство разработчиков предпочитают широко распространенные на рынке технологии, чтобы время, потраченное на изучение нового инструмента и фреймворка, пригодилось им и на следующей работе. Это также помогает им в процессе разработки — легче получить помощь, когда возникают вопросы. Таким образом, разработчики предпочитают платформы Low-code, использующие популярные языки и стандарты, а не проприетарные технологии. Применение открытых платформ упрощает поиск и наем квалифицированных разработчиков.

Выбирайте платформы, где разработка ведется с использованием стандартов JavaScript/HTML/REST. Благодаря такому подходу, разработчики, столкнувшиеся с чем-то, чего они не знают, могут просто найти ответ на популярных форумах по JavaScript. Когда им нужно получить доступ к внешней системе, им просто нужен стандартный REST API. Это также позволит им разрабатывать бэкенд на своем любимом серверном языке и легко получать к нему доступ из инструмента.

5. Расширяемость

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

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