Считается, что крутой разработчик программного обеспечения должен обладать как минимум десятилетним опытом, активно участвовать в проектах и решать задачи абсолютно любого уровня сложности. Так оно и есть, однако демократизация в сфере ИТ, в том числе в разработке, вносит свои коррективы, делая доступнее для конечных потребителей все больше инструментов и сервисов. «Разработчиком» теперь можно стать и без кода.
Я занимаюсь разработкой на платформе ТУРБО (одного из ключевых направлений бизнеса «Консист Бизнес Групп») уже 20 лет. И, как и многие тут, к low-code-решениям относился настороженно. Что заставило меня поменять мнение, попробую рассказать на примере нашей платформы.
Начнем с того, что развитие low-code/no-code технологий можно уже наблюдать и на примере сложных информационных систем управления, в проектировании которых на базе отечественной платформы ТУРБО я принимаю непосредственное участие. Хотя есть и отличия.
Речь идет о тиражных продуктах в категориях ERP, CRM, CPM, EAM – широком спектре задач учета и управления ресурсами, процессами, данными в организациях и на предприятиях.
Такие системы обладают, как правило, встроенными инструментальными средствами или набором интерфейсов для внешних интегрированных сред разработки. Поэтому их можно рассматривать не как черные ящики с конечным набором функций, а как конструкторы с типовыми бизнес-процессами и сущностями в конкретной области управления.
Совокупность серверов и сервисов ядра таких систем поддерживает набор характеристик, важных для высоконагруженных приложений – sustainability, scalability и др. В то же время эта совокупность дает возможность быстрой реализации бизнес-задач на основе готового набора сущностей и типовых процессов. Такая быстрая разработка – не с нуля, а путем переиспользования или расширения готового кода – похожа на подход low-code.
Low-code в системах управления
Тренд на уход от большого объема разработки к механизмам настройки бизнес-приложений получил отражение и в решениях, построенных на нашей платформе. Они позволяют на каждой стадии своего жизненного цикла формировать на лету сложную взаимосвязь объектов системы (измерения, формы, расчеты, отчеты) и гибко менять эту взаимосвязь без программирования. Целенаправленное развитие концепции low-code продолжается в новых релизах платформы и ее приложений.
В качестве примера разберем работу с некоторыми типовыми бизнес-приложениями ТУРБО.
В решении “ТУРБО Учет и финансы” подход low-code применяется в большом количестве объектов, определяющих базовые принципы формирования балансов по объектам учета и управления. К ним относятся:
учетная политика и план счетов;
аналитические признаки для учетных операций (тип операции);
типовые операции;
параметрические отчеты;
регламентированные отчеты.
В решении “ТУРБО Управление цепочками поставок” low-code, помимо параметрических настроек, применяется во фреймворке обмена ресурсов, который:
обеспечивает фиксацию количественных и качественных изменений состояния процессов;
формирует оценку ресурсов в накопленной стоимости и распределенной ценности;
создает ссылочные связи внутри системы, формирует временные ряды информации и выстраивает аналитические in-memory OLAP-кубы.
В “ТУРБО Бюджетировании” low-code применяется в настройке объектов:
измерения (справочники) – в виде набора преднастроенных перечней, смысловую нагрузку по которым можно задать перед началом формирования бюджетной модели;
формы ввода (ввод по аналогии Excel, ячейки и формулы) – развернутая система настроек, определяющая не только расположение объектов по страницам, строкам, столбцам, но и управление внешним отображением, включая цветовое, и группировку различных данных по сегментам вывода;
расчеты – формирование «легких» скриптов по бюджетной модели, объединяет измерения и данные, введенные в формах, для автоматизированного формирования расчетных значений ячеек, параллельно отражает схему расчета бюджетных показателей;
отчеты (табличные, графические, презентационные) – получение итоговых результатов процесса бюджетирования и преобразование их под различные цели (просмотр, отражение в виде графиков и диаграмм, подготовка презентации полученных результатов).
В “ТУРБО BI” (аналитика и отчеты) low-code используется в следующих объектах и настройках:
интеграционная шина – инструментарий интеграции в существующую экосистему;
отчеты – через визуальное задание наборов параметров вывода и группировки;
интерактивные панели – группировка элементов (отчеты, таблицы, графики, перечни) с указанием взаимодействия и детализацией.
Модель имеет значение
В сфере управления ресурсами, процессами и данными предприятий концепция low-code связана с воплощением в информационной системе модели деятельности организации – графического и алгоритмического цифрового двойника ее процессов. И здесь low-code – это, по сути, параметрическая донастройка деятельности и ее визуального отражения на рабочих местах непосредственных пользователей системы управления. Причем пользователей разного уровня, от исполнителей до бизнес-аналитиков и разработчиков.
Важно следующее. Если модель создания цифровых двойников деятельности поддерживается информационной системой управления, как в нашем случае ТУРБО, то есть если архитектура моделирования деятельности задана, то для запуска в промышленную эксплуатацию или перенастройки такой системы функциональные архитекторы и программисты не потребуются – квалифицированного пользователя и бизнес-аналитика будет достаточно.
Современная информационная система управления должна реализовывать модель деятельности предприятия на различных ее уровнях.
Реляционная модель – табличное представление данных и связей, работа с множествами.
Учетная модель – «проводка» по бухгалтерским счетам с отражением структуры изменения и формированием баланса.
Процессная модель – обмен ресурсами (деньги, сотрудники, ТМЦ) в процессе под контролем его участников.
Событийная модель – отражает основные качественные или количественные параметры у каждого события, возникающего в организации или системе.
Финансовая модель – моделирование ключевых показателей деятельности с учетом различных параметров и сценариев.
Развитие подобного рода моделей смещает фокус компетенций от ИТ в предметную область управления и тем самым концентрирует бизнес не на обеспечивающих, а на ключевых бизнес-задачах.
Как ТУРБО делал low-code в 90-е
Многие технологические подходы и нововведения, реализованные в ранних версиях ТУРБО, впоследствии были реализованы и стали массовым явлением в ИТ. На заре появления персональных компьютеров в бизнесе их использовали для простейших задач – распечатки документов. Для более сложных задач просто не существовало ПО, а даже самым компетентным сотрудникам тотально недоставало «компьютерной грамотности».
Эта ситуация не могла не привести к мысли о создании программных продуктов, которые позволяли бы пользователям в понятной им форме использовать программы для решения прикладных задач. Такой программой в начале 1990-х и стал «Турбо Бухгалтер». Для запуска продукта в эксплуатацию в текстовых файлах надо было заполнить несколько списков – счета, ТМЦ, сотрудники, контрагенты, проводки. Программа обрабатывала эти данные и позволяла стразу получить все нужные бухгалтерские отчеты – оборотные и аналитические ведомости, карточки счетов.
С такой задачей мог справиться любой бухгалтер с высшим образованием и профильным опытом работы. Три простых перечня и многодневная кропотливая работа стала укладываться в несколько часов, высвободив время на основную деятельность. Концепция «Турбо Бухгалтера» не имела отдельного названия, но полностью укладывалась в идеологию low-code.
Ок, что завтра?
Low-code существует не только в виде инструментов для нарезки сайтов и не очень сложных workflow над таблицами google. Его все больше и внутри сложных информационных систем, как мы и увидели на примере нашей платформы. Очевидно, что внешний инструментарий и встроенные фреймворки будут взаимно влиять друг на друга, встраиваясь, реализуя коннекторы и воспроизводя лучшие практики. Уже сегодня любой внешний low-code/no-code инструмент – это совокупность коннекторов с разными внешними системами и сервисами.
Информационные системы управления характеризуются большими объемами отслеживаемых событий и объектов, в них одновременно работает много пользователей. Дальше – больше. Плотность событий, количество пользователей и устройств, объем обрабатываемой информации растет лавинообразно. Поэтому ближайший фокус развития low-code – в отработке повышения плотности информации, со всеми механизмами упрощения восприятия, интеллектуальными помощниками и одновременным использованием устройств разных форматов для разных целей.
Следующее перспективное направление – принятие решения и реализация ответной реакции программного или аппаратного робота (в растущих объемах такая реакция становится чрезмерной для человека, но вполне подлежит алгоритмизации для исполнителя). Типичный пример – интерпретация совокупности сигналов о режиме работы оборудования и автоматическое создание тикета на сервисное обслуживание.
Нужно ли на фоне всего происходящего создавать сложные информационные системы с нуля или стоит попробовать промышленную платформу с элементами low-code? Это зависит от многих факторов и, в первую очередь, от компетенций команды-исполнителя. Поэтому в разработке ПО гиганты в виде компетентной команды, гарантирующей реализацию замысла, либо мощной платформы разработки лишними точно не будут.
А что думаете вы? Готов к обсуждению в комментариях.
Комментарии (10)
Muzzy0
04.10.2021 00:54Я тоже скептически к лоу коду относился. А потом подумал: есть же разница между, например, реализацией записи текстового файла на ассемблере и на C++/C#, например. В последних это буквально пара строк. Самый настоящий лоу-код. Код, от которого мы избавились, представляет интерес исключительно в учебных целях. Это справедливо и для многих других задач.
Лоу-код даёт возможность тратить значительно меньше времени на подобные вспомогательные задачи и освобождает больше времени на, собственно, разработку алгоритма, ноу-хау конкретной задачи.
TURBO_Solution Автор
08.10.2021 11:56Если уметь говорить на машинных языках, то общение с техникой и сам диалог (Код) будет очень небольшой и очень структурированный. И будет совсем "Low Code" с точки зрения «мало». Но суть технологии в другом. В том, чтобы перевести решение задач в сферу предметной области, ближе к потребителю (к его задачам), чтобы их решение было сделано самим пользователем, чтобы были решены только ему известные цели и задачи, а также нужный ему внешний вид, последовательность действий и т.д. То, что будет являться результатом устраивающим пользователя как человека. Low code - это подход не написания кода (маленького), а создание алгоритмов для облегчения (улучшения) исполнения деятельности человека (пользователя) и той окружающей действительности, которую он меняет (адаптирует) под себя.
Muzzy0
10.10.2021 13:14Если уметь говорить на машинных языках, то общение с техникой и сам диалог (Код) будет очень небольшой и очень структурированный. И будет совсем «Low Code» с точки зрения «мало».
Если мы говорим о решении какой-либо прикладной задачи — то, наоборот, в машинных языках кода будет больше. Я имею в виду тот код, который придётся написать. Уже существующий и взятый из библиотек я в расчёт не беру: он уже написан.
LordDarklight
Я пока скептически отношусь к 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 конструкторами, сниппетами и прочими адаптивными абстрактными шаблонами. Ручной набор программного кода существенно сократится - но ещё очень не скоро сойдёт на нет
TURBO_Solution Автор
Low/no code ещё не имеет такого широкого применения, как языки более низкого уровня (3 и ниже), но вопрос о будущем. Занимаясь практикой применения low code в корпоративном секторе и «ручками» реализовывая разнофункциональные проекты, перечисленные вами проблемы полностью присутствуют на практике. Но опыт проектов (low code с 2005 года) позволяет провести анализ и за более чем 15 лет придумать и воплотить обновлённый подход, нивелирующий негативные стороны. Первое, технология не стала языком программирования 4го поколения, но получила название «алгоритмического программирования» (проектирования), когда создание функциональности делается аналитиками, формирующими бизнес правила (алгоритмы), создавая их в отдельности, но в целом – формируют «сеть» исполнения алгоритмов для достижения нужной сложной функциональности. При этом, достигая 80%, т. е. 5 аналитиков на 1 программиста. Что в свою очередь позволяет сильно приблизить «алгоритмическое программирование» к бизнес заказчику и прикладной сфере. Проблемы тиражируемости решены автоматической «кодогенерацией», когда аналитики сделали бизнес алгоритм (настройки) и отладили, то платформа (бизнес слой) генерирует код по созданным настройкам, помещая его для повторного применения. Таким же способом решается проблемы шаблонов и наличия библиотек. Добавление в платформу возможности органичной интеграции js позволяет решить вопросы визуализации и разного рода мелких удобств - сервисов. Визуальное чтение алгоритмов сильно облегчается.
Вопросы скорости создания лежат в области изучения методики создания бизнес систем на основе low code и знаний общих подходов к моделированию бизнес деятельности. Многие умеют работать с электронными таблицами, но это только потому, что изучение начинается ещё в школе и продолжается в трудовой деятельности. То же справедливо и для алгоритмического программирования. Если его начинать изучать хотя бы в институте, то скорость создания будет очень высокой, при этом это будет справедливо для любой low code платформы. Многолетняя практика применения low code показывает что преимуществ становится больше, а отрицательных сторон (детских болячек) - меньше. Ничего не стоит на месте, и на текущий момент можно говорить уже о применении low code при создании "цифровых сотрудников". Более подробно постараюсь осветить в следующей статье.
LordDarklight
Как можно заметить в конце моего первого комментария я склоняюсь к такому же будущему развития ЯП. За исключением того - что я против визуального и схематичного
кодированиянастройки правил. А придерживаюсь мнения о более традиционном подходе к текстовому описанию правил, больше - что-то среднее между абстрактным высокоуровневым кодированием - условно сленговом немного ограниченном строгой терминологией описательным повествованием условно на литературном языке (но не разговорном) - то к чему стремилась например компания SAP. Близким простым примером такового описания можно назвать семейство языков SQL.То есть в текстовом виде (который снимает кучу описанных мною в первом посте проблем и дающий такую же кучу традиционных для современных ЯП возможностей) + с интеллектуальной поддержкой со стороны IDE (построенной с применением AI) - надо описывать исходные данные, действия и цели - обработки тех или иных данных или выполнения операций вне контура данных. Действия как раз и должны описывать в простых, понятных, но в то е время гибких терминах , напоминающих литературный текст, но в то же время близких именно к указанию выполнению необходимых команд над сущностями (как встроенных, так и библиотечных, кастомных, полиморфных) - где от редактора скрыты детали реализации (которые в итоге могут вести к более низкоуровневой реализации).
AI должен это всё анализировать как декларируемую схему - и встроить по ней план исполнения а затем и компилировать в промежуточный код (который далее уже компилируется более традиционно, например в режиме JIT, во время использования). По сути, получается чуть более сложная и интеллектуально гибкая схема как в используется в ряде классических СУБД.
При этом, никто не отменяет и визуального схематичного подхода - такие тексты могут быть сгенерированы конструкторами/мастерами-визадрдами/конвертерами из других представлений. Так и наоборот - на основе таких текстов можно строить схемы и визуализацию в нужном формате (AI ассистенты в IDE позволят провести оптимизацию конечного представления). Главное тут то - что описания алгоритмов должны быть относительно просты (все сложности скрыты с глаз долой в действиях, которые в схемах не раскрываются без должной на то необходимости).
Мне не нравится такое соотношение. Это как Карлсон которому не понравился один торт со свечкой а "лучше восемь пирогов и одна свечка!". Личное моё мнение - программистов всегда должно значительно быть больше чем "бездельников" аналитиков. Создавать бизнес-схемы большого труа не составляет - а вот развивать возможности конструктора бизнес-схем - вот тут пока ещё нужно прикладывать много усилий. Но, возможно, лет через 50 Вы будете правы - и программистов будет нужно меньше - так как их процесс кодинга будет более продуктивным. Но... даже тогда я думаю что и число аналитиков сократится - их подвытеснят те же AI-аналитики (а такие системы сейчас развиваются куда быстрее чем AI-кодогенераторы).
Говоря о повторном использовании кода и его переносимости я в первую очерель говорил именно об описании аналитики, а не о деталях её реализации - поэтому я сугубо за текстовую базу такого описания.
Вопрос же обучения сам по себе очень обширен. В вкратце соглашусь - что прививать возможности low code решения задач лучше уже в школе - более того - с этого надо начинать знакомство с IT - прям с ранних классов - и такие визуальные системы программирования для детей уже есть. В средней школе - можно перейти к более интересным задачам для данного возраста школьников - программирования внутриигровых механик и скриптов с применением комбинации как визуальных конструкторов так и текстовых скриптов. Ну а позже всё-таки лучше перейти к изучению более традиционных современных ЯП. Вернуться с к схематичному аналитическому программированию можно на старших курсах ВУЗов - разбирая уже конкретные практические системы и платформы
TURBO_Solution Автор
• Проблема в том, что настраивать алгоритмы надо через веб, а в виде кода это делать сложно. Также визуальное отражение важно, т.к. человек более 80% информации получает через зрение, и подготовка информации (структурно и в цвете) позволит ему делать это более быстро и более информативно.
• Для того, чтобы писать на языках программирования, нужно хорошо знать синтаксис, а многие аналитики к этому не приучены. Тот же язык SQL понятен техническим специалистам и полностью не понятен обычным опытным пользователям прикладной сферы. Также он сильно далек от практической области. Он абстрактен (это его и преимущество, и слабость).
• Для AI нужны алгоритмы и, если просто абстрактно, то язык не важен, а если конкретная область, то нужны термины для описания социально-экономических систем и конструкции, алгоритмы для них. Тогда вырабатывается более специализированный механизм, который собирает в себе инструменты в структуру. Он получил название "Структура бизнеса" (немного устаревшее, возможно требующее расширения). При этом, структура не содержит пользовательских данных, она описывает сущности (бизнес сущности), которые взаимоувязаны между собой алгоритмами. Впоследствии формируются объекты на основе данной структуры, их создают пользователи (экземпляры - документы), а AI работает уже с данными, но с оглядкой на "структуру бизнеса" Это повышает его эффективность, т.к. он решает больше прикладную задачу и на более понятном объеме данных. Также согласен, что "структуры бизнеса" должны все более развиваться в направлении описания их в "гибких терминах напоминающий литературный текст", но это достаточно далекое будущее. (а сейчас таблицы, настройки и диаграммы, схемы)
• Хотелось бы, чтобы в нашем обществе людей со знаниями программирования было больше, но увы, мой опыт показывает, что их намного меньше, а хороших, понимающих предметную область, - еще меньше. Практика показывает, что более перспективно привлечь для разработки алгоритмов работников прикладной области, чем "заставить" программистов погрузиться в предметную область.
50 лет не требуется, достаточно более 15 лет практики :) , в которой соотношение 5 к 1 - это параметр, который закладывается при расчете потребности в ресурсах для конкретной реализации проекта.
• Многолетние усилия и практическая апробация, теоретическое обобщение показывают, что "Будущее намного ближе".
LordDarklight
WEB - не более чем средство передачи информации (и в меньшей степени визуализации - но это не принципиально)
Как я уже написал - против конструкторов и всяких мастеров, и схематичного преставления и редактирования ничего против не имею. Когда есть возможность текстового представления. Оба подхода имеют свои плюсы и минусы. Но на мой взгляд, именно текстовое представление даёт больше возможностей, и, чаще всего, удобства - но соглашусь, что работа секстовым представление требует больше навыков и привыкания. Но в конечном итоге - это будет куда более быстрый и эффективный путь. Особенно, когда работе с текстом будет активно помогать IDE, включая продвинутых AI-Ассистентов.
Текстовый подход - уже давно активно развивает свою как юзабилити, так свои возможности, как в глубину, так и в ширину - тут многое уже эффективно придумано, и многое ещё будет придумано. Тут много общих, условно, стандартизированных подходов. И очень просто делать новые инструменты, анализаторы, препроцессоры, генераторы и т.п. - что снижает нагрузку на человека и повышает эффективность работы. Не нужно изобретать эффективные средства редактирования - огромная база уже есть, но её можно и нужно ещё расширять, но не как что-то проприетарное - как что-то общее - со временем понятное и доступное многим, вне зависимости от их языков программирования и платформ.
И сейчас, благодаря продвинутым IDE, текстовый подход уже не так сильно уступает по визуализации графическим схемам и конструкторам, как, скажем лет 20-40 назад. И тут много чего ещё можно сделать. И зрение при работе с текстом сейчас очень даже задействовано.
Трудности с текстами могут быть только у тех, у кого просто психологически индивидуально плохое восприятие текста - как при чтении, так и при вводе (в т.ч. проблемы с моторикой пальцев). В большинстве случаев - это преодолимо. Но, соглашусь, заставить это преодолевать может быть не очень просто.
Поэтому, иметь возможность иного визуального представления я не отменяю - но только как дополнение.
Я хорошего ЯП недалёкого будущего синтаксис не должен быть сложным, и должен легко усваиваться за пару вечеров (накрайняк - нескольких недель). При вводе алгоритма так же активно должна помогать IDE, со встроенной быстрой справкой по синтаксису.
Визуальный ввод тоже нужно изучать - и, на мой взгляд, это требует куда больше усилий.
Не согласен, что sQL хорошо понятен только техническим специалистам. На практике встречал людей (не программистов) - которые сами готовили себе отчёты на SQL-подобном языке запросов (после небольшого обучения и подготовленной инструкции). Да - это были несложные отчёты - но их это вполне устраивало, и разгружало работу программистов.
Согласен, что декларативные языки (как SQL) - достаточно высокоабстрактны - и я за повышение этого уровня абстракции. Это их сила и их же слабость. Но, лично я за такой подход, как минимум, в прикладном программировании. И да - ЯП SQL уже давно устарел, ему на смену должны прийти более мощные ЯП (как более сложные синтаксически, так и наоборот - более "человеколюбивые" с более ярко выражено близким к письменной человеческой речи синтаксисом).
Но из моей практики, как раз наоборот - проще программиста затащить в предметную область, чем из пользователя делать программиста.
Другое дело - нужно ли так поступать? Об этом ниже.
Вот именно такой подход я и пропагандирую. Я называют это "Бизнес сущностями" - блоки конструктора модульного подхода, определяющие топологию данных, взаимодействий, интерактивной работы и различных форматов ввода/вывода. Из таких "Бизнес сущностей" в итоге складывается единое приложение (или распределённая система). "Бизнес сущности" комбинируются и интегрируются друг с друг с другом - подвергаясь мусингу, расширению и полиморфизму. Вернее не сами сущности - а их содержимое, ведь они - лишь унифицированные контейнеры.
Настройку взаимодействия "Бизнес сущностей" (Business Entity) я пока представляю (вопреки сказанному выше) в виде визуального редактора, в виде схем, таблиц, опций. Но текстовое представление схемы тоже должно быть - скорее в виде сериализации - хотя бы чтобы эффективно работать с GIt
Но как только дело доходит до более глубоких алгоритмов обработки данных - там уже первенствует текст и какой-то ЯП (его синтаксис я пока прорабатываю).
Над "Бизнес сущностями" (помимо модулей и пакетов) - находится процесс "Сборка" - он отвечает за сборку из "Бизнес сущностей" итогового приложения или модуля/библиотеки. Главное его действие - это объединение по заданным правилам содержимого "Бизнес сущностей" в единые прикладные объекты (до этого момента один и тот же объект может быть сильно размазан по разным "Бизнес сущностям", как размазаны могут быть и отдельные части алгоритмов). Так же "Сборка" финального приложения может раскрывать большую часть абстракций (уже оперируя готовыми структурами данных), проводить кодогенерацию и все возможные статические подстановки; прогонять тесты. Более того, получать доступ к данным и статистики использования этого приложения (предыдущих сборок) и на её основе осуществлять ещё и глубокую оптимизацию, включающую AI-анализ и обращение к базам знаний готовых паттернов алгоритмов.
Считаю, что такой подход в прикладном программировании доступен уже сейчас - а AI возможности будут его расширять с каждым годом и уже во второй половине XXI века это будет наиболее востребовано и популярно.
Не стоит жить прошлым - нужно смотреть в будущее - тогда будет успех!
Мне кажется - во второй половине XXI века ситуация вкорне изменится. Аналитиков будет мало (вернее, их то будет много - а вот спрос на них будет невелик). Аналитическую работу в основном будут выполнять системы Искусственного Интеллекта. Вероятно даже научаться формулировать вполне сносные ТЗ в бизнес-терминах. И это всё будет уже направлено не на человеческое юзабилити, а на машинную обработку - поэтому аналитики-люди уже будут не удел. Да и аналитика будет уже строиться на машинном обучение.
И вот тут как раз будет уже большой спрос на программистов.
Тогда может не нужно тащить аналитиков в программисты (ну разве что для переквалификации, на ущербном рынке труда по профессии аналитика). Как и наоборот, но в меньшей степени, может и не надо будет глубоко погружать программистов (в общей массе) в предметную область - ему на помощь придут AI-аналитики.
Да и программистов тоже всё больше будут подменять на AI-программистов. А им (и AI-аналитикам) как раз работать с текстовой информацией в виде, инструкций и команд, будет куда сподручнее, чем с графической, и в виде схем.
Эти тенденции уже начались - и уже скоро (лете через 10-20-30) будут весьма заметны.
О чём я и говорю. Пора перестраиваться. Не живите в прошлом - где во главе угла стоят не особо интеллектуально одарённые топ-менеджеры. Ориентируетесь на будущее - где во главе угла стоят AI системы обработки и генерации информации. И программисты - которые их настраивают и поддерживают. И им всем тексты куда важнее, чем визуальное представление - оно так о останется в прошлом. Придут новые ЯП 5-го поколения, и они не будут визуально-ориентированными, как это предполагалось в ЯП 4-го поколения. Этой революции не случилось - и вряд ли уже случится.
А если и случится в будущем - то совсем в другом виде - когда в обиход придёт глубокий VR, AR и голосовое взаимодействие - и, возможно, изменится сам подход к интерактивному взаимодействию человека и компьютера. Но это уже не ранее конца XXI - я так считаю, до середина века эти технологии буду ещё буксовать - их время пока не пришло, но обязательно придёт в будущем. А 50 лет - это не так уж и много для человеческого общества. Но за 50 лет всё то, что актуально сейчас - 100% уйдёт в небытие - или как минимум сильно видоизменится. Сейчас можно только предполагать как пойдёт развитие.... или же - начать потихоньку его направлять - в новое русло - главное не обшиться с вектором приложения усилий, чтобы они не были напрасны (против течения). Но даже если они будут ошибочны - это тоже может пойти на пользу развития - негативный опыт - тоже опыт, вот только успеха тем, кто его придерживался, это вряд ли принесёт (если у них не будет и другой альтернативы). Движение, условно, во всех направления - это ключевой закон эволюции - и эта техника весьма эффективна - в т.ч. в IT индустрии (и даже применяется на практике - просто об этом мало кто знает)
Muzzy0
Muzzy0