Комментарии 27
Вангую следующее — такие платформы умерят дизайнерские и фишечные аппетиты менеджмента, стандартизируя UX, в результате окажется что если не требовать от разработчиков всякой фигни — обычные программиные решения и библиотеки так же справятся неплохо. И от распространения этих платформ будет падать средняя стоимость разработки вообще, что будет замедлять их распространение.
По моему 5+ летнему опыту две трети усилий по разработке тратятся на не особо нужные хотелки. "хотим тут чтобы футер менял цвет". "хотим чтобы можно было выбирать фото и видео одной кнопкой". "хотим кнопку удаления сущности вот в этом подменю вот этой подсущности" — и все, архитектура не выдерживает, код пачкается, и т.д.
А когда менеджеры привыкнут, что что-то нельзя и есть стандартные UX решения — то и просто разработка подешевеет, а стало быть такие платформы станут менее актуальными.
Более того, при современной плотности рынка свистелки/пердели это единственная способность завоевать какую либо долю рынка или попросту не загнуться.
Вангую, что типовые решения как были фуфлом так им и останутся.
А разработка будет дорожать, так как нужно конкурировать с конкурентами конкурентно.
Вот это вот все что вы описываете позволяет проектам с свистелками/перделками/уникальным UX уничтожать на рынке типовые проекты сотнями.
Даже интересно узнать хотя бы про пару примеров. Что-то ничего найти не могу. А вот когда за свистелками/перделками ничего найти не получается… то 99% стартапов и загибаются.
В вашем примере сопоставляются 99% стартапов со свистелками против 1% существующих стартапов с реализованными свистелками и кучей клиентов.
Если вы против этого 1% попробуете выкатить шаблонное приложение, то его никто не заметит совсем.
Пример: любая CRM допиленная под клиента против уникального хорошо написанного проекта для тех же целей.
Получается наоборот. Сотни и тысячи сидят на типовом решении, а 10% допиливают, иногда сильно, под себя… и умирают (((
С чего Вы решили, что допиливание свистелок и перделок было/стало причиной появления кучи клиентов?
Также одно из преимуществ — это уменьшение цепочки между конечным пользователем и разработчиком. Т.е. в классическом подходе пользователь может хотеть чтобы «футер менял цвет», а до разработчика это требование может дойти совершенно другим. А в лоу код пользователь это может поменять сам(ну или попросить напрямую разработчика)
Читаем заголовок… и… так почему нужно присматриваться к этим решениям?
Потому, что Gartner сказал про 2024 год?
Или потому, что есть список «наиболее серьёзных проблем»?
Или это реклама облачного контакт-центра?
С другой стороны, аналогичный заход уже был: SQL для того, чтобы каждый бухгалтер/руководитель получал нужные себе данные. И вылилось в то, что SQL теперь как отдельная программистская дисциплина. Low-Code идут в туже сторону?
Ирина, прокомментируете?
А еще раньше был язык COBOL, предназначенный для того, чтобы обыкновенные люди могли писать программы простым человеческим языком.
Ну Эксель же выполнил эту задачу? Куча народу, совсем не программисты, вполне ваяют себе отчеты, различные сборные таблицы, с различными перекрестными ссылками и полями.
Не было бы Эксель сколько надо было бы программистов для расчетов, что делают бухгалтера, экономисты и прочие менеджеры? А маткад/матлаб? Какому количеству математиков и физиков была бы нужна помощь программистов?
PS. А VBA и возможность записать скрипт/макрос и потом прогнать его 100500 раз на разных данных. И менять структуру этих данных?
Была надежда, что Вы в этой теме варитесь и сможете прокомментировать статью. Сейчас, на мой скромный взгляд, это описание из разряда «в огороде бузина ...», т.е.: Да, такой софт есть.
И?:
Применимость? Вопрос для кого. Руководитель будет сам разбираться в кубиках?
Сделать флоу? Простенькое наверное можно. Посложнее — сомнительно. Или нет?
Ну, а с другой стороны. Да, перевод…
Но есть и подводные камни, о которых тоже нужно знать. Целью данной статьи не является заставить вас все бросить и начать использовать данный подход, подойдет ли он конкретно вам, вам и решать)
Платформы low-code/no-code имеют множество преимуществ, но требуют обучения для работы с ними.
Главное, чтобы это обучение не стало существенно сложнее, чем обучение программированию.
Конструктор программ
Не требует знания языков
Конструктор программ позволяет каждому пользователю ПК начать программировать без знания каких бы то ни было языков высокого уровня сразу же после установки среды.
Создать программу в HiAsm так же просто, как собрать фигурку из деталей лего — достаточно выбрать необходимый набор компонентов и соединить их друг с другом в цельную конструкцию.
Расширяемость пакетами
Функциональность Конструктора программ может быть расширена путем установки дополнений — новых пакетов и элементов.
Пакет может содержать неограниченное число элементов и давать в руки пользователя инструмент для создания программ под различные операционные системы, платформы и устройства.
Редактор схем online
Online версия среды (Hion) позволяет собирать схемы с помощью всего лишь одного браузера, запускать их и делиться с другими пользователями конструктора.
Hion работает в любом браузере, в том числе на телефонах и планшетах, что позволяет заниматься конструированием даже в дороге.
Поддержка сообщества
Для облегчения работы над проектами в среде каждому зарегистрированному пользователю предлагаются несколько online сервисов, позволяющих по мимо всего прочего обмениваться своими разработками с другими участниками проекта.
Так же существующие сервисы дают возможность каждому разработчику принять непосредственное участие в развитие проекта и помочь сделать его лучше.
Создать программу в HiAsm так же просто, как собрать фигурку из деталей лего — достаточно выбрать необходимый набор компонентов и соединить их друг с другом в цельную конструкцию.
Я думаю, что эту фразу нужно читать следующим образом:
Создать простенькую программу так же просто, как собрать детскую машинку из деталей лего. А создать реальную программу так же "просто", как собрать настоящий автомобиль из деталей лего.
ИМХО «нейронные сети», придут на смену «обычному» программированию.
Нейронки решают узкий круг специфических задач. Точнее, этот круг можно расширять очень сильно, на любую задачу, где есть какие-то закономерности (на которые нейронки и натренировываются), но это требует достаточно серьёзных вложений для обучения. Плюс, многие задачи требуют специалиста по нейросетям, чтобы подобрать наиболее удачную структуру сети под конкретную задачу.
Везде, где потребуется чтото новое, вам понадобится живой человек. Ни одна сеть не научится из пространного объяснения того, что хочется заказчику генерировать код. В софтверных компаниях для этого требуется минимум три человека, на заводе программист 1с может и в одиночку въехать в требования и сделать доработку, но наверняка он там не только что пришел и часть времени потратил на понимание того, кто излагает требования, а также въезжание в предметку вместо того, чтобы разрабатывать в это время.
есть у меня ребята которые на вордпрессе сделали решение, теперь никто копаться не хочет в этих глюках. всё-таки в разработке нужно учитывать и поддержку тоже. какие-то изолированные вещи может и проще писать в визуальных редакторах, но как это всё потом соотносить с командной разработкой, гит, инженерными практиками, непонятно. вот есть у меня код на C# который я писал 5 лет назад, я его досихпор использую во всех проектах. а такие вещи как эти схемы они привязаны к какому-то одному решению, им невозможно управлять в долгосрочной перспективе. они больше про то как подсадить клиента на своё решение так чтобы он не смог с него слезть чем про решение проблем
Мне вообще не понятен круг задач решаемых сферическим программистом в вакууме )))
Здесь много программистов, поделитесь кто чем занят, в общих чертах, и в общих чертах напишите почему задачу которую решаете Вы (не)возможно выполнить на low/no-code?
Я (и команда) пилю некую crm+helpdeck в достаточно узкой нише. Готовых решений нет. Интеграции с другими crm, госсайтами и т.д.
Часть функционала переведена в no-code, т.е. пользователь может настроить последовательность и число задач, правила рассылки, в том числе в боты мессенджеров, правила уведомления, сроки исполнения, определение исполнителей и т.д. по нескольким десяткам параметров. Т.е. при появлении нового контрагента программировать (в большинстве случаев) ничего не надо. Надо заполнить соответствующие реквизиты, настроить правила обработки, уведомлений и т.д. Так же при появлении нового вида заявок, достаточно добавить запись об этом виде, "собрать из кубиков" маршрут, указать сроки, при необходимости указать различные сроки для каждой фазы луны, или в зависимости от курса доллара. Ничего программировать не надо.
Тем не менее у бизнеса появляются запросы которые ну ни как не были учтены при разработке системы — надо допиливать. Появляются новые внешние системы, новые требования регуляторов и т.д. Какая-то часть решается настройками, но часть ни как не была учтена прежде, совершенно новая функциональность — допиливаем.
Почему стоит обратить внимание на подход low-code/no-code