Андрей, по-моему лоукод и ноукод инструменты имея читабельную нотацию помогали понять что делает приложение и в этом их ценность для взаимодействия сторон бизнеса и ИТ. По-моему пусть самый понятный (вам) код будет менее понятен чем процесс описанный, например в бипиэмэн.
Я тоже так думал. И теоретически так и должно быть. Но есть нюансы (которые больше имеют отношения к 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 решения сейчас более воспроизводимыми для управленца.
Андрей, по-моему лоукод и ноукод инструменты имея читабельную нотацию помогали понять что делает приложение и в этом их ценность для взаимодействия сторон бизнеса и ИТ. По-моему пусть самый понятный (вам) код будет менее понятен чем процесс описанный, например в бипиэмэн.
Я тоже так думал. И теоретически так и должно быть. Но есть нюансы (которые больше имеют отношения к 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 решения сейчас более воспроизводимыми для управленца.