Поэтому если у вас есть идея, вам нужно собрать MVP (минимально жизнеспособный продукт), и протестировать его на реальных клиентах. Убедитесь, что они готовы за него платить, и только после этого начинать полноценную разработку в коде, зная, что вы идете в верном направлении.
Любой кто работал в разработке более-менее крупных систем понимает, что никаких подобных конструкторов там никогда не будет. Периодически в мире всегда возникало желание избавиться от кодинга, ручного ввода разметки и т.п. в сторону подобных решений. И к чему это привело? Помню, про Dreamviewer в свое время яростно кричали как про инструмент, который позволит избавиться от написания html/css и т.п. На выходе в результате получили почти unsupported решения. Вспомним примеры из Desktop: Winforms предлагал создавать приложения для Win при помощи подобного конструктора со стандартными элементами. Потом все равно ушли в сторону WPF с XAML-разметкой, так как это гораздо более гибко, с ужесточением требований заказчиков и расширением возможностей по разработке, усложнением дизайнов использовать типовые элементы редактора стало просто нереально. И куча таких примеров. Это если ещё не вдаваться в подробности про back-end (архитектура, нагрузка, интеграция, масштабирование и т.п ). Для мелкого бизнеса может и подойдут простенькие конструкторы, которые, к слову, есть и сейчас. Но для серьезных решений это всегда будет только кодинг. Причем команда разработки - это не только программисты, это дизайн, аналитика, тестирование, нагрузка... Это все конструктором просто не заменить. А учитывая, что иногда требования заказчика даже формализовать сложно, то ни о каких конструкторах речи вообще идти не может ) Да что говорить, все профессиональные инструменты для разработки сейчас уходят в сторону командных строк, а не визуальных интерфейсов (менеджеры пакетов и т.п.)
Не совсем согласен. Есть, например, Microsoft Access, на котором можно сделать законченное многопользовательское СУБД под многие задачи без кодирования на VBA. А если по ODBC прикрутить какую-нибудь SQL - то масштабировать можно до уровня среднего предприятия. Dreamviewer был вполне себе нормальным WYSIWYG в своё время - уж получше Microsoft FrontPage.
Верно, разработчикам пока не о чем переживать
Ну окей, я работаю в компании, которая разрабатывает системы ДБО. Достаточно сложно?
И вот последнее время при реализации каких либо новых банковских продуктов в системе все чаще используется внутренний конструктор документов. Изначально он был придуман под нужды заказчиков, чтобы они могли на нем сочинять какие либо свои нестандартные банковские документы, впоследствии его допилили до возможности создать полноценные новые документы, справочники, с контролем реквизитов и всякое такое. Как итог - разработка и вывод в прод нового функционала значительно ускорилась
Понятно, что никто не будет целиком и полностью разрабатывать системы целиком на подобном подходе, но упростить жизнь разработке такие инструменты более чем способны.
Комментарий недоступен
Действительно похоже! Google переводчик не избавил мир от профессиональных переводчиков, но все-таки значительную часть работы по переводам во всем мире взял на себя.
Как по мне no/low-code хрень полнейшая. Если запиливать всякие сайтики или помойные приложения-однодневки — да, шансы ещё есть. Когда же требуется нормальный бэкэнд написать для производства, то это выглядит как минимум смешно.
В своём лучшем исполнении no/low-code может в максимуме достичь аналогов фреймворков по работе с БД, где знание SQL не обязательное. Но производительность такого куска кода будет не высокой. Если бизнес устраивают такие издержки, то будет и жизнь у no/low-code.