Например, вы делаете большой корпоративный портал со сквозным процессом через крупную корпорацию и их подрядчиков. При этом вы опираетесь на BPMNS Camunda, это тот самый Low-Code, который даёт много готового из коробки. Из чего состоит на самом деле ваша работа? Вам нужно выработать итоговые требования, развернуть вокруг этой самой Camunda обвязку из микросервисов, большая часть из которых будет интеграционной, встроить это все в архитектурный ландшафт конкретной корпорации, реализовать интеграцию с сервисами подрядчиков и очень много других важных вопросов, где нужно думать, а не писать код. Именно тех вопросов, которые может решить только профессиональный разработчик, а не кто-то другой.
Мне кажется, что No-Code и Low-Code нужен для создания фастфуд-приложений и сервисов, чтобы быстро и дешево на коленке протестить какую-нибудь гипотезу, после чего отдать ее в полноценную разработку
типа того. если у вас нет команды и хочется потестить гипотезы не сложнее лэндоса с парой формочек. на большее это не способно.
Не весь no-code одинаковый. Мы в AppMaster например генерируем приложения используя языки высокого уровня - Go, JS (Vue3), Swift и Kotlin. Кодогенерация позволяет на выходе получить производительные компилируемые приложения, при этом это уже не уровень MVP. Можно масштабироваться достаточно долго и не факт что когда-нибудь придется переписывать приложения вручную.
Смотрите, никто не говорит о том, что приложение на No-Code будут работать медленно. Но они всегда будут иметь ограничения, которую задаст платформа. Это стандартные блоки, способы связи для них и прочие. Именно это будет ограничивать потенциал развития функционала.
Да, вы можете дать возможность кастомизации, просто в какой-то момент развития окажется, что кастомизировать дороже, чем писать на нативном языке.
При этом не ограничивать пользователя вы не сможете. У вас все равно есть какая-то целевая аудитория, с какими-то понятными классами задач, которые в целом решаются одинаково. Плюс стремление оградить пользователя от ошибок, сделать систему удобнее. Именно это в итоге и задаёт систему ограничений.
Конечно, если пользователю не нужно приложение с развитым и нестандартными функционалом, то ему должно хватить ваших стандартных средств. И приложение не нужно будет переписывать.
Скажем честно, разрабатывать что-то сложное и нетривиальное приходится не часто. Вы просто можете исключить людей с такими потребностями из своей целевой аудитории, так часто и поступают. Вы же не ставите себе цель захватить 100% рынка разработки?
Кодогенерация позволяет на выходе получить производительные компилируемые приложения
А как только в сгенерированный код ручками залезли, генераторы уже неприменимы? Дальше только хардкодинг? Или как это работает?
Константин, как тогда на ваш взгляд объяснить ситуацию, что low-code платформы прочно поселились, например, в таких решениях как кредитные конвейеры, комплаенс-процессы и многих другие банковских системах, которые в общем и целом являются наверное одними из самых сложных классов информационных-систем, требующих максимально квалифицированных инженеров и архитекторов?
Это вопрос без подвоха, интересно ваше мнение. Я сам много лет посвятил BPMS и как инженер и как предприниматель.
Что такое No-Code и Low-Code? Это какие-то готовые блоки, которые нужно правильно расположить и связать между собой. Если вы работаете в зарегулированной области, где функционал в целом стандартный, нужно просто верно описать правила движения чего-либо по процессу, то вполне логично применение No-Code и Low-Code. Тогда, систему разворачивать будет не разработчик, а другой человек, пусть даже он прошёл дополнительное обучение. То есть шаблонные и рутинные задачи отдаются от разработчика другим специалистам, бизнес сокращает издержки, может развиваться и генерировать новые задачи для разработчиков.
Хорошим примером является 1С. Разработать с нуля бухгалтерскую систему — нетривиальная задача. А вот взять готовую конфигурацию 1С и немного настроить её под конкретное предприятие — уже проще. При этом мы понимаем, что те разработчики, которые разрабатывают платформу 1С, очень сильно отличаются от тех разработчиков, которые конфигурируют решения на 1С. В финансовой сфере — аналогично.
Ещё пример. Написать свою BPMS — это сложно и долго. Сконфигурировать нужные процессы в уже готовой BPMS — уже проще.
Смысл в том, что максимально квалифицированные инженеры и архитекторы работают один раз, а потом поддержка и развитие могут осуществляться менее квалифицированными и дорогими кадрами.