Code first VS low-code для создания интеграций в эпоху ChatGPT | Андрей Путин

[@petushkovandrey1094]

Андрей, по-моему лоукод и ноукод инструменты имея читабельную нотацию помогали понять что делает приложение и в этом их ценность для взаимодействия сторон бизнеса и ИТ. По-моему пусть самый понятный (вам) код будет менее понятен чем процесс описанный, например в бипиэмэн.

[@andrey-putin-ktteam]

Я тоже так думал. И теоретически так и должно быть. Но есть нюансы (которые больше имеют отношения к Low Code и намного меньше к nocode): 1. Компоненты конструктора надо знать. Нужно понимать что делает каждый компонент, а прочесть его можно заглянув внутрь. Это делает критически важным ясный нейминг, но с хорошим неймингом у большинства -- проблемы. 2. low-code можно сделать нечитаемым (как и код). Но спросить GPT о пояснениях в таком случае будет сложнее (пока, во всяком случае). 3. Паттерны одного lcdp не будут соответствовать другим (в отличие от кода). Если у вас есть несколько разных сред разработки, то проблемы low-code начинают умножаться кратно, а code-first только на сахар синтаксиса, который теперь даже знать не обязательно (можно copilot попросить перевести с airflow на php-laravel и всё получится). Для примера, посмотрите на BPMN2 (3 уже). Идеальная схема описания бизнес-процессов. Если сделать правильно, то схема читается за 5 минут. Проблема в том, что чтобы так сделать, нужно иметь очень высокую компетенцию и насмотренность. Где таких специалистов брать? Я за читаемый low-code, но чтобы сделать это читаемым, нужно прилагать усилия. Если идти в сторону унификации, урощения, стандартизации, лично мне видятся code-first решения сейчас более воспроизводимыми для управленца.