Интерпретация Low-Code с точки зрения SPL с открытым исходным кодом

Какой код считается низким？

Термин «Low-Code» стал популярным в последние годы, породив ряд соответствующих предпринимательских команд. Мы только знали, что раньше были длинные и короткие коды, только теперь мы знаем, что все еще есть высокие и низкие коды.

Интуитивно так называемый низкий код предназначен для облегчения написания кода, другими словами, объем кода (который можно понимать как рабочую нагрузку) меньше при выполнении одной и той же задачи; Кроме того, еще одним важным показателем low code является то, что требования к разработчикам должны быть достаточно низкими. Если бы все коды были написаны мастерами с многолетним опытом, было бы трудно достичь цели снижения затрат и повышения эффективности, даже если код написан коротко.

Очевидно, что при обсуждении лоу-кода сначала нужно иметь какой-то код и посмотреть, не является ли этот код немного ниже других кодов.
Однако многие так называемые платформы разработки, хвастающиеся лоу-кодом, не имеют своего собственного код на самом деле, но просто сделать несколько фреймворков и шаблонов. Разработчики могут создать систему приложений, просто заполнив шаблоны. Да, эти шаблоны легко использовать для обработки простых требований, и они довольно просты в использовании, но когда требование становится настолько сложным, что вам нужно использовать код для его решения, вам все равно придется использовать такие коды, как Java/C#.
Низкий код заключается в том, чтобы сделать код низким, а не фреймворком.Шаблоны без кода действительно могут решить некоторые проблемы, но все еще слишком много компаний, которые нужен код, чтобы сделать их. Таким образом, высокий и низкий уровень кода действительно тесно связан с эффективностью разработки.

Итак, какой код считается низким кодом?
Низкий код в основном ориентирован на разработку информационных систем (известных в широком смысле как ИИС), потому что только эти приложения имеют множество требований, и каждое требование различных сценариев отличается и всегда меняется без конца. В этом случае средства разработки с высокой эффективностью и низким порогом имеют особое значение.
Основная задача информационной системы фактически состоит в том, чтобы делать три вещи с данными: ввод, обработка и вывод. Инициалы трех слов, объединенных вместе, представляют собой IPO, где I и O теперь могут быть решены с помощью зрелых инструментов отчетности и элементов управления интерфейсом, и, следовательно, единственная проблема — это P. Большая часть бизнес-логики, которая должна быть закодирована в процессе разработки, точно решить п.

Поэтому, когда мы оцениваем, является ли код достаточно низким, нам нужно знать, удобен ли этот код для обработки данных.

Тогда какие данные обрабатывать?

В основном это относится к структурированным данным, то есть к данным, существующим в реляционной базе данных, которая является наиболее распространенным типом данных в информационной системе. Другие неструктурированные данные подходят только для некоторых специальных и фиксированных требований к обработке. В противном случае только преобразование таких данных в структурированные данные или извлечение из них структурированных данных может удовлетворить потребности гибкой обработки.

В этом случае нужно просто определить, какой код лучше всего подходит для обработки структурированных данных.

В соответствии с этим критерием код Java, безусловно, не является низким, потому что Java не имеет приемлемого структурированного объекта данных. Хотя новая версия Java поставляется с библиотекой классов, ориентированной на наборы, такой как Stream, и начинает поддерживать синтаксис Lambda, она по-прежнему нацелена и может ориентироваться только на очень общие объекты данных (это определяется целью самой Java). и по-прежнему относительно сложно кодировать при работе со структурированными данными. Более того, Java является компилируемым языком и по своей природе трудно быть динамичным. Более того, Java — сильный объектно-ориентированный язык, и глубоко понять объектно-ориентированную концепцию непросто. При разработке Java-приложений также необходимо создать сложную проектную среду, что не является низким порогом для разработчиков.
Аналогичная ситуация с языком C#.

Код SQL относительно невелик в определенной степени. Многие непрофессионалы умеют кодировать запросы на SQL. При написании кода на SQL разработчикам не нужно особо заботиться об архитектуре приложения, а нужно только понимать данные и сам бизнес, а это те знания, которыми разработчики должны обладать.
Однако у SQL есть два серьезных недостатка. в двух аспектах: упорядоченные вычисления и процедурная логика. Такие недостатки сделают несколько более сложную обработку очень проблематичной, часто приводя к письменному синтаксису с сотнями строк и вложенными уровнями, который не может быть понят даже самим разработчиком через несколько месяцев. Более того, особенно сложно отлаживать код SQL, и, следовательно, стоимость разработки еще больше возрастает.
Если вместо этого использовать хранимую процедуру, то можно реализовать процедурную операцию, но это все равно, что вернуться к Java. Хотя хранимая процедура написана на языке SQL, она также не имеет простых в использовании объектов структурированных данных (разработчик может полагаться только на временную таблицу) и операции установки. Поэтому обычно лучше использовать Java, чтобы заставить SQL работать (на самом деле многие приложения написаны на Java + SQL). Кроме того, при использовании хранимых процедур разработчик также сталкивается с некоторыми проблемами архитектуры приложения.
«Низкий» код SQL подходит только для относительно простых сценариев. Когда бизнес-требования становятся сложными, сложность кода возрастает в геометрической прогрессии.

Что касается Python, то здесь ситуация немного лучше. Pandas имеет фрейм данных, который можно считать структурированным объектом данных. К сожалению, Python относительно плохо интегрируется, если только все приложение не было написано на Python, что, однако, бывает редко. Более того, фрейм данных можно рассматривать только как дилетанта, поскольку он по сути является матрицей, а не таблицей данных в нашем обычном смысле, и многие операции очень запутаны для размышлений. Более того, мы должны повторить это еще раз, pandas — это пакет стороннего класса, среда его приложений не очень проста, а отладка по-прежнему проблематична.

Scala — еще один вариант, у него также есть фрейм данных, который может выполнять некоторую структурированную обработку данных, но он также не очень профессионален. Хотя сам код Scala относительно невелик, порог понимания таких вещей, как объектно-ориентированные концепции, вовсе не низок, и он также столкнется со сложной средой проекта.

SPL — низкий код

Разве не существует достаточно низкого кода?

Да, есть! SPL esProc с открытым исходным кодом — это low code и, вероятно, единственный в настоящее время.
Собственно, поэтому SPL был изобретен: поскольку Raqsoft является поставщиком инструментов для создания отчетов, он, естественно, включает в себя множество сложных операций. Однако компании Raqsoft было сложно кодировать эти операции как на SQL, так и на Java, и такие трудности нельзя решить, усовершенствуя существующую систему. Чтобы решить эти проблемы, Raqsoft после долгих лет напряженной работы изобрел новый язык — SPL.

В SPL есть хорошо зарекомендовавшие себя структурированные объекты данных, и он может обрабатывать как большие данные, так и малые данные. Хотя он использует небольшое количество объектно-ориентированного синтаксиса, он не использует эзотерические объектно-ориентированные концепции, а фокусируется на обработке данных и операциях. С точки зрения программной логики, немного похожий на ранний язык BASIC, SPL имеет базовые ответвления, циклы и подпрограммы, которые делают его очень простым для понимания. Кроме того, SPL предоставляет типы наборов на основе структурированных данных и богатые библиотечные функции, в частности, он хорош для поддержки сложных операций с наборами и упорядоченными операциями, что значительно упрощает написание кода.

Говорить дешево, давайте покажем код.
Код SPL записывается в виде сетки и может напрямую использовать ячейки в качестве имени переменной (пользователям Excel это покажется знакомым). Более того, SPL обладает следующими характеристиками: естественно поддерживает пошаговую работу; уровни кода могут быть четко отражены отступом сетки, и он снабжен отличными функциями отладки.

Богатые библиотечные функции; общие основные операции могут быть выполнены всего в одной строке.

В SPL вы даже можете использовать SQL напрямую (независимо от базы данных):

$select * from d:/Orders.csv where (OrderDate<date('2020-01-01') and Amount<=100)or 
(OrderDate>=date('2020-12-31') and Amount>100)
$select year(OrderDate),Client ,sum(Amount),count(1) from d:/Orders.csv  
group by year(OrderDate),Client  
having sum(Amount)<=100
$select o.OrderId,o.Client,e.Name e.Dept from d:/Orders.csv o  
join d:/Employees.csv e on o.SellerId=e.Eid
$with t as (select Client ,sum(amount) s from d:/Orders.csv group by Client)  
select t.Client, t.s, ct.Name, ct.address from t  
left join ClientTable ct on t.Client=ct.Client

Сам SPL имеет возможность управления процессом, аналогичную Java, поэтому SPL может достичь эффекта Java + SQL независимо от того, есть база данных или нет.

Давайте сравним его с другими кодами. Например, мы хотим рассчитать максимальное количество последовательных дней, в течение которых цена акций продолжает расти.
Запишите это на SQL следующим образом:

select max(consecutive_days)
from (select count(*) consecutive_days
      from (select sum(updown_flag) over(order by sdate) no_up_days
            from (select sDate,
                         case when price>LAG(price) over(order by sDate)
                              then 0 else 1 end updown_flag
                  from share))
      group by no_up_days)

Этот код немного сложно понять, верно? Вы можете принять это как упражнение и подумать о том, как это работает.

Кодирование в Python выглядит следующим образом:

import pandas as pd
aapl = pd.read_excel(‘d:/AAPL.xlsx’)
continue_inc_days=0;
max_continue_inc_days=0
for i in aapl['price'].shift(0)>aapl[‘price’].shift(1):
    continue_inc_days =0 if i==False else continue_inc_days+1
    max_continue_inc_days = continue_inc_days if max_continue_inc_days < continue_inc_days else max_continue_inc_days
print(max_continue_inc_days)

Хотя эта логика не сложна, кодировать ее не очень просто.

Что касается Java, мы не будем пытаться. Вы сами можете представить его сложность.

Для той же операции кодирование в SPL выглядит следующим образом:

В этом коде нет оператора цикла, потому что SPL имеет большое количество сильных функций набора в стиле лямбда-синтаксиса. Многие задачи, которые можно решить только с помощью циклов в других языках, можно выполнить с помощью одного оператора в SPL.

SPL устраняет серьезные недостатки SQL и сочетает в себе общие преимущества Java и SQL. Кроме того, SPL может легко поддерживать операции с большими данными и многопоточные параллельные вычисления, но Python растеряется, когда столкнется с такой ситуацией. Если вам интересно узнать больше примеров кода SPL, перейдите на Raqforum.

Больше, чем просто низкий код

SPL обеспечивает идеальную поддержку источников данных; он может поддерживать почти все источники данных, о которых вы, возможно, слышали или не слышали:

Таким образом, снижается объем работы по подготовке интерфейса данных и преобразованию.

Поскольку SPL реализован на Java, он поставляется с драйвером JDBC и может быть легко встроен в приложения Java:

…
Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement st = connection.();
CallableStatement st = conn.prepareCall("{call xxxx(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();
…

Таким образом, SPL можно легко интегрировать в некоторые фреймворки приложений. Большинству разработчиков нужно заботиться только о бизнес-логике и структуре данных, и им даже не нужно разбираться в сложной архитектуре приложений.

В частности, эти «платформы с низким кодом» без кода будут иметь настоящий низкий код после интеграции SPL с открытым исходным кодом. Позволить шаблону и коду дополнять друг друга — это полноценная платформа с низким кодом.

SPL также является динамическим языком интерпретируемого исполнения, и написанные сценарии могут быть размещены вне основного приложения. Таким образом, не только уменьшается связь между сценарием и основным приложением, но также предоставляются преимущества горячей замены. В конце концов, бизнес-логика (особенно запросы и отчеты) часто меняется. Когда требование изменилось, оно может вступить в силу немедленно, пока сценарий переписан, и нет необходимости перезапускать приложение. Если в данном случае используется Java-код, то… (это также показывает, что Java-код вовсе не низкий).

Официальный сайт SPL 👉 https://www.scudata.com

Отзывы и помощь SPL 👉 https://www.reddit.com/r/esProc

Учебные материалы по SPL 👉 https://c.raqsoft.com

Исходный код и пакет SPL 👉 https://github.com/SPLWare/esProc