Комментарии 22
И после проектирования еще упираешься в ограничения low-code инструмента, которые зависят от видения его разработчиков. Что в итоге выливается в потерю времени или проект на костылях.
Да, поставщики Low-code мягко говоря "преувеличивают" про то, что кто угодно сможет разрабатывать решения. Однако, это не повод кидаться в крайности, и говорить, что давайте вернемся все на Ассемблер. Повышение уровня абстрагирования в любом случае дает много преимуществ. Например, мы на фактически Low-Code инструменте lsFusion делаем сложнейшие ERP системы. Да, конечно же и там есть свои ограничения, но они компенсируются скоростью и дешевизной разработки.
Многие люди не понимают, что обеспечить low code можно только фундаментальным повышением уровня абстракций, не "программированием мышкой". При "программировании мышкой" кода меньше не становится, он просто вводится по другому.
По сути, ты перетаскиваешь куски готового кода в UI оболочке, и количество этих движений зависит от атомарности low-code решения. Чем она выше, тем больше движений, но и гибкости больше (ближе к чистому кодированию). И наоборот, гибкость падает с увеличением размеров готового "куска кода".
Ну подобные решение еще имеют смысл, когда граф транслируется в код и наоборот.
И такие решения хотя бы тьюринг полны. Тот же ui делать или сценарии.
А вот решения наподобие blueprint только повышают сложностью, намного проще выучить язык и платформу.
Oracle Apex - хорош для определённых задач
Проблема же не в инструменте, а в попытке применить его не по назначению. Если сразу принимать и осознавать, что NoCode/LoCode решение будет на определённом этапе неизбежно выкинуто на помойку и заменено нормальным - почему нет?
Если я бэкенд пишу, мне очень удобно на первых порах набросать к нему кривой LoCode фронтенд, вместо того, чтобы сразу нанимать фротнендера, который мне на этом этапе проекта ещё не нужен, да и всё равно в процессе требования поменяются сто раз, так и так переписывать?
Или если я хочу потенциальным пользователям показать "вот так примерно оно будет выглядеть - удобно?"
Ну или ниша, которую Retool занимает - внутренние инструменты, которые по природе своей могут быть несколько корявыми и неидеальными, но лучше, чем ничего.
Пользователю нужен результат а не инструмент. И пофиг, что результат достигается костилями, лишь бы был. Как маркетологи говорят, покупателю сверла нужна дырка а не сверло, просто сверло самый доступный способ добыть дырку.
Идеальный пример лоу-коде инструмента - exel таблицы. Еще ни один инструмент не смог повторить его успех.
А что там Cuba.Platform? Жива еще?
А потом все равно приходится писать в них код
Как же я люблю Scratch
да, привязка, прчем иногда извращенная, если не заплатил вовремя, то уже готовое в гугл-плэй приложение перестанет работать. И пока не видел ни одного которое вызвало бы вау-эффект, везде надо немало документации изучить (соптавимой по объему и сложности с базовым уровнем напимер SQL или С#)
Проблема людей в том, что лоукод ныне можно считать очередным панацелином.
Это конечно же не так... Ничего личного, только маркетинг.
Лоукод решения применяются уже давно в нишевых инструментах, но не везде и всюду. Всему своё место.
Без конкретных примеров из жизни в основном вода которую можно в 1о предложение уместить - "no-code гавно". Хотелось бы конкретики, и что-нибудь из опыта
Согласен с Вашим взглядом на low code. Ознакомьтесь, пожалуйста, с моей статьей на медиуме по данной теме https://mikebolshakov.medium.com/being-a-low-code-skeptic-dff6a7102655
No/low code вполне себе годиться для MVP, но надо понимать что после MVP это выкидывается в помойку или переписывается потому что заказчик такое начинает генерить в бэклог ???. Иногда важно очень быстро релизнуть MVP что бы показать/доказать бизнес ценность продукта.
Если ваш бизнес можно на долгосроке автоматизировать через NoCode, то и занятую им нишу на рынке оттяпать с помощью ChatGPT труда не составит. Пороги -- они ведь не только для вхождения, они еще и от рейдерства.
ChatGPT это не low-code, с чего вообще вдруг? GPT это как раз ЯП, просто ещё сырой и не освоенный, по сути уиверсальный DSL. А вот low-code это присплсоба для решения стандартных задач, оно нацеленно на упрощения и это не универсальный молоток. Сложность в принципе никуда не девается просто в онтологии появляются новые понятия, которые проще оперируют стандартными случаями. Все имеет право на существование и выполняет свои функции. Инструменты никого не обманывают, обманывают люди. Вот вы лучше конкретно пишите, кто вас обманывает и в чем или идите с ними беседуете, какой-то инфантилизм закидывать это в сообщество
На мой взгляд, самая большая проблема lo-code решений в том, что "непрограммисты" не могут использовать его: не хватает базовых знаний.
При этом программисты тоже не могут использовать lolcode инструменты:их от них "корёжит"
Исследовано на примере fis platform.
Консультанты. То есть те программисты, которым приходится общаться с клиентом. У них шансы решить проблему ГОРАЗДО больше. И Их типично программистские проблемы 0.1 + 0.2 === 0.3 не интересуют, им надо получить результат за минимальное время.
1С и Oracle APEX для меня лучший пример баланса между Low и Code, дальше упрощать - потеряется гибкость.
Low-code инструменты для разработки ПО — сплошной обман