Comments 10
Я пока скептически отношусь к Low-code - считаю, что в глобальном контексте время таких систем не пришло. Возможно в виде визуального программирования (когда-то преподносимого как 4-ое покидание языков программирования) в глобальном контексте это время никогда не настанет (будет вытеснено другими средствами Low-code - на основе отдаваемых команд (например голосовых) искусственному интеллекту - но это пока не скоро.
Но для ряда задач (отчасти показанных здесь) Low-code может быть вполне жизнеспособен уже сейчас, в частности:
Аналитические выборки, да и, вообще, любые выборки данных - конструировать их без ручного написания запросов к СУБД или к объектной модели вполне годная задача для Low-code
Визуализация данных, будь то формы взаимодействия с пользователем или выходные форумы - печатные формы, отчёты - тоже вполне можно решать в формате Low-code
Описание схем данных, в т.ч. со встройкой готовых адаптивных компонент работы с этими данными и их чтения/записи/сериализации/транспортировки/визуализации - тоже вполне можно решать на уровне Low-code уже сейчас (и в некоторых средах так и делается уже давно)
Описание схем бизнес-процессов, в т.ч. с последующей автогенерацией программного кода исполнения этих бизнес-процессов - тоже вполне посильная задача для Low-code подхода
Описание схем настройки и калибровки систем обработки данных с привлечение ML и AI - это тоже вполне может быть Low-code, как и задачи программирования AI и баз знаний
Построение алгоритмов специфической обработки данных - ну... отчасти Low-code тут тоже может быть очень полезен, особенно когда нужно создавать асинхронные, параллельные и распределённые системы обработки данных. Но тут пока ещё не всё так гладко как хотелось бы - но в будущем наверняка доля Low-code схем будет быстро расти
Конструирование алгоритмов отражения данных в учёте, да хоть просто для сохранения в СУБД, или задачи конвертации данных - это очень даже Lowe-code задачи - главное, чтобы была продвинутая система консолидации и оптимизации этих схем - чтобы их итоговое исполнение имело как можно меньше повторных обращений к данным и тем де исходным данным или многократным поискам.
Low-code решение задач неплохо помогает когда сразу нужно "убить двух-трёх... зайцев" - и структуры данных обозначить, и методы работы с ними, и интерфейсные элементы задать, и контроль доступа обеспечить и т.д. и т.п.
Задачи построения автотестов и отладки - тоже Low-code freinldy-задачи
Задачи построения автодокументации - тоже Low-code freinldy-задачи
А ещё Low-code - это очень хорошее решение для достижения кросс-платформенности и оптимизации приложений (не ручного тюнинга, когда нужно выжимать максимум, конечно, а возможности без больших усилий создавать вполне оптимальные и кросс-платформенные приложения для широкого круга потребления)
И последнее - Low-code схемы могут быть очень удобны в задачах, требующих сравнение и сопоставление схем (читай - задачи мерджа гит)
Вот такой вот я скептик - набросал кучу вариантов, где считаю Low-code вполне применимым. Но есть большая ложка дёгтя в этой бочке low-code-мёда. А именно:
Средства его формирования. Как выше написал - визуальные средства программирования так и не стали 4-ым поколением языков программирования - вообще не стали популярны, и заняли весьма унитарные и разрозненные ниши. А всё почему? А потому что:
Не так уж быстро с помощью них создаётся готовое решение (простое быстро - посложнее - уже скорость быстро падает)
Есть проблемы с переносимостью такого кода - решения разрозненны и для каждой целевой платформы (исполнения верхнего уровня) создаются отдельно - даже в рамках одной целевой платформы перенос готовых блоково очень ограничен
Проблемы повторного использования кода тоже очень существенны - библиотеки и шаблоны в таких системах редкость, наследование, миксины, интерфейсы, функциональный подход - ещё большая редкость , макросы - почти отсутствуют вовсе везде (я не про макросы - аналоги горячих клавиш и запись действий пользователя - хотя и с ними всё тоже туго; я про макросы повышения уровня абстракции и автогенерации Low-code конструкций)
Актуальны и проблемы адаптивности и повышения уровня абстракции - ни дженериков, ни виртуализации, даже шаблонная подстановка редка
Проблемы анализа готовых схем - их зачастую анализировать (изучать и дорабатывать) бывает куда сложнее, чем просто готовый текст. Печатать их тоже весьма проблемно
Проблема обучаемости - может надуманная - но если для изучения ЯП полно курсов, литературы и сайтов. То для Low-code такой базы нет - все они проприетарный - каждую систему придётся изучать индивидуально на основе той документации, что авторы предложили. В лучше случае будет одна книжка. Но это не сравнится с тем многообразием источников информации, что есть по традиционным популярным ЯП
Возможно есть и другие проблемы - просто навскидку не назову.
Вот поэтому я скептически отношусь к Low-code - да - это здорово - да это может быть полезно- да это может реально ускорять процесс разработки и расширять сферу итогового результата и его качество - но только если это будет идти как довесок к классическому текстовому программированию и текстовому преставлению схем.
И в будущем, как мне кажется, куда эффективнее будет модель именно текстового абстрактного программирования скорее ближе к декларативному - к процессу описания сущностей и отдачи команд - а уже AI cсистемы будут это всё анализировать и генерировать уже готовый традиционный кросс-платформенный программный код - который затем уже будет компилироваться под целевую платформу исполнения. При наборе такого текста AI-ассистент в IDE тоже будет активно помогать. Ну и отчасти можно будет пользоваться готовыми Low-code конструкторами, сниппетами и прочими адаптивными абстрактными шаблонами. Ручной набор программного кода существенно сократится - но ещё очень не скоро сойдёт на нет
Low/no code ещё не имеет такого широкого применения, как языки более низкого уровня (3 и ниже), но вопрос о будущем. Занимаясь практикой применения low code в корпоративном секторе и «ручками» реализовывая разнофункциональные проекты, перечисленные вами проблемы полностью присутствуют на практике. Но опыт проектов (low code с 2005 года) позволяет провести анализ и за более чем 15 лет придумать и воплотить обновлённый подход, нивелирующий негативные стороны. Первое, технология не стала языком программирования 4го поколения, но получила название «алгоритмического программирования» (проектирования), когда создание функциональности делается аналитиками, формирующими бизнес правила (алгоритмы), создавая их в отдельности, но в целом – формируют «сеть» исполнения алгоритмов для достижения нужной сложной функциональности. При этом, достигая 80%, т. е. 5 аналитиков на 1 программиста. Что в свою очередь позволяет сильно приблизить «алгоритмическое программирование» к бизнес заказчику и прикладной сфере. Проблемы тиражируемости решены автоматической «кодогенерацией», когда аналитики сделали бизнес алгоритм (настройки) и отладили, то платформа (бизнес слой) генерирует код по созданным настройкам, помещая его для повторного применения. Таким же способом решается проблемы шаблонов и наличия библиотек. Добавление в платформу возможности органичной интеграции js позволяет решить вопросы визуализации и разного рода мелких удобств - сервисов. Визуальное чтение алгоритмов сильно облегчается.
Вопросы скорости создания лежат в области изучения методики создания бизнес систем на основе low code и знаний общих подходов к моделированию бизнес деятельности. Многие умеют работать с электронными таблицами, но это только потому, что изучение начинается ещё в школе и продолжается в трудовой деятельности. То же справедливо и для алгоритмического программирования. Если его начинать изучать хотя бы в институте, то скорость создания будет очень высокой, при этом это будет справедливо для любой low code платформы. Многолетняя практика применения low code показывает что преимуществ становится больше, а отрицательных сторон (детских болячек) - меньше. Ничего не стоит на месте, и на текущий момент можно говорить уже о применении low code при создании "цифровых сотрудников". Более подробно постараюсь осветить в следующей статье.
«алгоритмического программирования» (проектирования), когда создание функциональности делается аналитиками, формирующими бизнес правила (алгоритмы), создавая их в отдельности, но в целом – формируют «сеть»
Как можно заметить в конце моего первого комментария я склоняюсь к такому же будущему развития ЯП. За исключением того - что я против визуального и схематичного кодирования настройки правил. А придерживаюсь мнения о более традиционном подходе к текстовому описанию правил, больше - что-то среднее между абстрактным высокоуровневым кодированием - условно сленговом немного ограниченном строгой терминологией описательным повествованием условно на литературном языке (но не разговорном) - то к чему стремилась например компания SAP. Близким простым примером такового описания можно назвать семейство языков SQL.
То есть в текстовом виде (который снимает кучу описанных мною в первом посте проблем и дающий такую же кучу традиционных для современных ЯП возможностей) + с интеллектуальной поддержкой со стороны IDE (построенной с применением AI) - надо описывать исходные данные, действия и цели - обработки тех или иных данных или выполнения операций вне контура данных. Действия как раз и должны описывать в простых, понятных, но в то е время гибких терминах , напоминающих литературный текст, но в то же время близких именно к указанию выполнению необходимых команд над сущностями (как встроенных, так и библиотечных, кастомных, полиморфных) - где от редактора скрыты детали реализации (которые в итоге могут вести к более низкоуровневой реализации).
AI должен это всё анализировать как декларируемую схему - и встроить по ней план исполнения а затем и компилировать в промежуточный код (который далее уже компилируется более традиционно, например в режиме JIT, во время использования). По сути, получается чуть более сложная и интеллектуально гибкая схема как в используется в ряде классических СУБД.
При этом, никто не отменяет и визуального схематичного подхода - такие тексты могут быть сгенерированы конструкторами/мастерами-визадрдами/конвертерами из других представлений. Так и наоборот - на основе таких текстов можно строить схемы и визуализацию в нужном формате (AI ассистенты в IDE позволят провести оптимизацию конечного представления). Главное тут то - что описания алгоритмов должны быть относительно просты (все сложности скрыты с глаз долой в действиях, которые в схемах не раскрываются без должной на то необходимости).
т. е. 5 аналитиков на 1 программиста. Что в свою очередь позволяет сильно приблизить «алгоритмическое программирование» к бизнес заказчику и прикладной сфере
Мне не нравится такое соотношение. Это как Карлсон которому не понравился один торт со свечкой а "лучше восемь пирогов и одна свечка!". Личное моё мнение - программистов всегда должно значительно быть больше чем "бездельников" аналитиков. Создавать бизнес-схемы большого труа не составляет - а вот развивать возможности конструктора бизнес-схем - вот тут пока ещё нужно прикладывать много усилий. Но, возможно, лет через 50 Вы будете правы - и программистов будет нужно меньше - так как их процесс кодинга будет более продуктивным. Но... даже тогда я думаю что и число аналитиков сократится - их подвытеснят те же AI-аналитики (а такие системы сейчас развиваются куда быстрее чем AI-кодогенераторы).
Говоря о повторном использовании кода и его переносимости я в первую очерель говорил именно об описании аналитики, а не о деталях её реализации - поэтому я сугубо за текстовую базу такого описания.
Вопрос же обучения сам по себе очень обширен. В вкратце соглашусь - что прививать возможности low code решения задач лучше уже в школе - более того - с этого надо начинать знакомство с IT - прям с ранних классов - и такие визуальные системы программирования для детей уже есть. В средней школе - можно перейти к более интересным задачам для данного возраста школьников - программирования внутриигровых механик и скриптов с применением комбинации как визуальных конструкторов так и текстовых скриптов. Ну а позже всё-таки лучше перейти к изучению более традиционных современных ЯП. Вернуться с к схематичному аналитическому программированию можно на старших курсах ВУЗов - разбирая уже конкретные практические системы и платформы
• Проблема в том, что настраивать алгоритмы надо через веб, а в виде кода это делать сложно. Также визуальное отражение важно, т.к. человек более 80% информации получает через зрение, и подготовка информации (структурно и в цвете) позволит ему делать это более быстро и более информативно.
• Для того, чтобы писать на языках программирования, нужно хорошо знать синтаксис, а многие аналитики к этому не приучены. Тот же язык SQL понятен техническим специалистам и полностью не понятен обычным опытным пользователям прикладной сферы. Также он сильно далек от практической области. Он абстрактен (это его и преимущество, и слабость).
• Для AI нужны алгоритмы и, если просто абстрактно, то язык не важен, а если конкретная область, то нужны термины для описания социально-экономических систем и конструкции, алгоритмы для них. Тогда вырабатывается более специализированный механизм, который собирает в себе инструменты в структуру. Он получил название "Структура бизнеса" (немного устаревшее, возможно требующее расширения). При этом, структура не содержит пользовательских данных, она описывает сущности (бизнес сущности), которые взаимоувязаны между собой алгоритмами. Впоследствии формируются объекты на основе данной структуры, их создают пользователи (экземпляры - документы), а AI работает уже с данными, но с оглядкой на "структуру бизнеса" Это повышает его эффективность, т.к. он решает больше прикладную задачу и на более понятном объеме данных. Также согласен, что "структуры бизнеса" должны все более развиваться в направлении описания их в "гибких терминах напоминающий литературный текст", но это достаточно далекое будущее. (а сейчас таблицы, настройки и диаграммы, схемы)
• Хотелось бы, чтобы в нашем обществе людей со знаниями программирования было больше, но увы, мой опыт показывает, что их намного меньше, а хороших, понимающих предметную область, - еще меньше. Практика показывает, что более перспективно привлечь для разработки алгоритмов работников прикладной области, чем "заставить" программистов погрузиться в предметную область.
50 лет не требуется, достаточно более 15 лет практики :) , в которой соотношение 5 к 1 - это параметр, который закладывается при расчете потребности в ресурсах для конкретной реализации проекта.
• Многолетние усилия и практическая апробация, теоретическое обобщение показывают, что "Будущее намного ближе".
Проблема в том, что настраивать алгоритмы надо через веб, а в виде кода это делать сложно. Также визуальное отражение важно, т.к. человек более 80% информации получает через зрение, и подготовка информации (структурно и в цвете) позволит ему делать это более быстро и более информативно.
WEB - не более чем средство передачи информации (и в меньшей степени визуализации - но это не принципиально)
Как я уже написал - против конструкторов и всяких мастеров, и схематичного преставления и редактирования ничего против не имею. Когда есть возможность текстового представления. Оба подхода имеют свои плюсы и минусы. Но на мой взгляд, именно текстовое представление даёт больше возможностей, и, чаще всего, удобства - но соглашусь, что работа секстовым представление требует больше навыков и привыкания. Но в конечном итоге - это будет куда более быстрый и эффективный путь. Особенно, когда работе с текстом будет активно помогать IDE, включая продвинутых AI-Ассистентов.
Текстовый подход - уже давно активно развивает свою как юзабилити, так свои возможности, как в глубину, так и в ширину - тут многое уже эффективно придумано, и многое ещё будет придумано. Тут много общих, условно, стандартизированных подходов. И очень просто делать новые инструменты, анализаторы, препроцессоры, генераторы и т.п. - что снижает нагрузку на человека и повышает эффективность работы. Не нужно изобретать эффективные средства редактирования - огромная база уже есть, но её можно и нужно ещё расширять, но не как что-то проприетарное - как что-то общее - со временем понятное и доступное многим, вне зависимости от их языков программирования и платформ.
И сейчас, благодаря продвинутым IDE, текстовый подход уже не так сильно уступает по визуализации графическим схемам и конструкторам, как, скажем лет 20-40 назад. И тут много чего ещё можно сделать. И зрение при работе с текстом сейчас очень даже задействовано.
Трудности с текстами могут быть только у тех, у кого просто психологически индивидуально плохое восприятие текста - как при чтении, так и при вводе (в т.ч. проблемы с моторикой пальцев). В большинстве случаев - это преодолимо. Но, соглашусь, заставить это преодолевать может быть не очень просто.
Поэтому, иметь возможность иного визуального представления я не отменяю - но только как дополнение.
Для того, чтобы писать на языках программирования, нужно хорошо знать синтаксис, а многие аналитики к этому не приучены. Тот же язык SQL понятен техническим специалистам и полностью не понятен обычным опытным пользователям прикладной сферы. Также он сильно далек от практической области. Он абстрактен (это его и преимущество, и слабость).
Я хорошего ЯП недалёкого будущего синтаксис не должен быть сложным, и должен легко усваиваться за пару вечеров (накрайняк - нескольких недель). При вводе алгоритма так же активно должна помогать IDE, со встроенной быстрой справкой по синтаксису.
Визуальный ввод тоже нужно изучать - и, на мой взгляд, это требует куда больше усилий.
Не согласен, что sQL хорошо понятен только техническим специалистам. На практике встречал людей (не программистов) - которые сами готовили себе отчёты на SQL-подобном языке запросов (после небольшого обучения и подготовленной инструкции). Да - это были несложные отчёты - но их это вполне устраивало, и разгружало работу программистов.
Согласен, что декларативные языки (как SQL) - достаточно высокоабстрактны - и я за повышение этого уровня абстракции. Это их сила и их же слабость. Но, лично я за такой подход, как минимум, в прикладном программировании. И да - ЯП SQL уже давно устарел, ему на смену должны прийти более мощные ЯП (как более сложные синтаксически, так и наоборот - более "человеколюбивые" с более ярко выражено близким к письменной человеческой речи синтаксисом).
Но из моей практики, как раз наоборот - проще программиста затащить в предметную область, чем из пользователя делать программиста.
Другое дело - нужно ли так поступать? Об этом ниже.
Для AI нужны алгоритмы и, если просто абстрактно, то язык не важен, а если конкретная область, то нужны термины для описания социально-экономических систем и конструкции, алгоритмы для них. Тогда вырабатывается более специализированный механизм, который собирает в себе инструменты в структуру. Он получил название "Структура бизнеса" (немного устаревшее, возможно требующее расширения)...
Вот именно такой подход я и пропагандирую. Я называют это "Бизнес сущностями" - блоки конструктора модульного подхода, определяющие топологию данных, взаимодействий, интерактивной работы и различных форматов ввода/вывода. Из таких "Бизнес сущностей" в итоге складывается единое приложение (или распределённая система). "Бизнес сущности" комбинируются и интегрируются друг с друг с другом - подвергаясь мусингу, расширению и полиморфизму. Вернее не сами сущности - а их содержимое, ведь они - лишь унифицированные контейнеры.
Настройку взаимодействия "Бизнес сущностей" (Business Entity) я пока представляю (вопреки сказанному выше) в виде визуального редактора, в виде схем, таблиц, опций. Но текстовое представление схемы тоже должно быть - скорее в виде сериализации - хотя бы чтобы эффективно работать с GIt
Но как только дело доходит до более глубоких алгоритмов обработки данных - там уже первенствует текст и какой-то ЯП (его синтаксис я пока прорабатываю).
Над "Бизнес сущностями" (помимо модулей и пакетов) - находится процесс "Сборка" - он отвечает за сборку из "Бизнес сущностей" итогового приложения или модуля/библиотеки. Главное его действие - это объединение по заданным правилам содержимого "Бизнес сущностей" в единые прикладные объекты (до этого момента один и тот же объект может быть сильно размазан по разным "Бизнес сущностям", как размазаны могут быть и отдельные части алгоритмов). Так же "Сборка" финального приложения может раскрывать большую часть абстракций (уже оперируя готовыми структурами данных), проводить кодогенерацию и все возможные статические подстановки; прогонять тесты. Более того, получать доступ к данным и статистики использования этого приложения (предыдущих сборок) и на её основе осуществлять ещё и глубокую оптимизацию, включающую AI-анализ и обращение к базам знаний готовых паттернов алгоритмов.
Считаю, что такой подход в прикладном программировании доступен уже сейчас - а AI возможности будут его расширять с каждым годом и уже во второй половине XXI века это будет наиболее востребовано и популярно.
Не стоит жить прошлым - нужно смотреть в будущее - тогда будет успех!
Хотелось бы, чтобы в нашем обществе людей со знаниями программирования было больше, но увы, мой опыт показывает, что их намного меньше, а хороших, понимающих предметную область, - еще меньше
Мне кажется - во второй половине XXI века ситуация вкорне изменится. Аналитиков будет мало (вернее, их то будет много - а вот спрос на них будет невелик). Аналитическую работу в основном будут выполнять системы Искусственного Интеллекта. Вероятно даже научаться формулировать вполне сносные ТЗ в бизнес-терминах. И это всё будет уже направлено не на человеческое юзабилити, а на машинную обработку - поэтому аналитики-люди уже будут не удел. Да и аналитика будет уже строиться на машинном обучение.
И вот тут как раз будет уже большой спрос на программистов.
Тогда может не нужно тащить аналитиков в программисты (ну разве что для переквалификации, на ущербном рынке труда по профессии аналитика). Как и наоборот, но в меньшей степени, может и не надо будет глубоко погружать программистов (в общей массе) в предметную область - ему на помощь придут AI-аналитики.
Да и программистов тоже всё больше будут подменять на AI-программистов. А им (и AI-аналитикам) как раз работать с текстовой информацией в виде, инструкций и команд, будет куда сподручнее, чем с графической, и в виде схем.
Эти тенденции уже начались - и уже скоро (лете через 10-20-30) будут весьма заметны.
Многолетние усилия и практическая апробация, теоретическое обобщение показывают, что "Будущее намного ближе".
О чём я и говорю. Пора перестраиваться. Не живите в прошлом - где во главе угла стоят не особо интеллектуально одарённые топ-менеджеры. Ориентируетесь на будущее - где во главе угла стоят AI системы обработки и генерации информации. И программисты - которые их настраивают и поддерживают. И им всем тексты куда важнее, чем визуальное представление - оно так о останется в прошлом. Придут новые ЯП 5-го поколения, и они не будут визуально-ориентированными, как это предполагалось в ЯП 4-го поколения. Этой революции не случилось - и вряд ли уже случится.
А если и случится в будущем - то совсем в другом виде - когда в обиход придёт глубокий VR, AR и голосовое взаимодействие - и, возможно, изменится сам подход к интерактивному взаимодействию человека и компьютера. Но это уже не ранее конца XXI - я так считаю, до середина века эти технологии буду ещё буксовать - их время пока не пришло, но обязательно придёт в будущем. А 50 лет - это не так уж и много для человеческого общества. Но за 50 лет всё то, что актуально сейчас - 100% уйдёт в небытие - или как минимум сильно видоизменится. Сейчас можно только предполагать как пойдёт развитие.... или же - начать потихоньку его направлять - в новое русло - главное не обшиться с вектором приложения усилий, чтобы они не были напрасны (против течения). Но даже если они будут ошибочны - это тоже может пойти на пользу развития - негативный опыт - тоже опыт, вот только успеха тем, кто его придерживался, это вряд ли принесёт (если у них не будет и другой альтернативы). Движение, условно, во всех направления - это ключевой закон эволюции - и эта техника весьма эффективна - в т.ч. в IT индустрии (и даже применяется на практике - просто об этом мало кто знает)
Личное моё мнение — программистов всегда должно значительно быть больше чем «бездельников» аналитиковСамо собой. Один аналитик за день способен придумать столько, сколько 10 программистов не реализуют за месяц.
Лоу-код даёт возможность тратить значительно меньше времени на подобные вспомогательные задачи и освобождает больше времени на, собственно, разработку алгоритма, ноу-хау конкретной задачи.
Если уметь говорить на машинных языках, то общение с техникой и сам диалог (Код) будет очень небольшой и очень структурированный. И будет совсем "Low Code" с точки зрения «мало». Но суть технологии в другом. В том, чтобы перевести решение задач в сферу предметной области, ближе к потребителю (к его задачам), чтобы их решение было сделано самим пользователем, чтобы были решены только ему известные цели и задачи, а также нужный ему внешний вид, последовательность действий и т.д. То, что будет являться результатом устраивающим пользователя как человека. Low code - это подход не написания кода (маленького), а создание алгоритмов для облегчения (улучшения) исполнения деятельности человека (пользователя) и той окружающей действительности, которую он меняет (адаптирует) под себя.
Если уметь говорить на машинных языках, то общение с техникой и сам диалог (Код) будет очень небольшой и очень структурированный. И будет совсем «Low Code» с точки зрения «мало».Если мы говорим о решении какой-либо прикладной задачи — то, наоборот, в машинных языках кода будет больше. Я имею в виду тот код, который придётся написать. Уже существующий и взятый из библиотек я в расчёт не беру: он уже написан.
Low-code в системах управления: разбираемся на примере платформы ТУРБО