Утверждают, что прямо сейчас с помощью no-code инструментов не создать сколько-нибудь серьезный продукт. Скептики, к коим относится большинство программистов, считают это невозможным в принципе. На самом деле, продуктами без кода теперь называют то, что раньше было обычными электронными таблицами и конструкторами сайтов из кубиков.

Скептики как будто правы: этот no-code не заменяет код не реализует алгоритм, то есть, ветвления циклы и прочее, а только позволяет накидать на чистый лист квадратики, которые как-то там взаимодействуют друг с другом. Элементы платежных систем, фрагменты веб-документов, формы и чаты, таблицы с фильтрами. Всё это связывается в пёструю мешанину MVP и гордо именуется no-code решением.

Давайте попробуем что-то иное, чем аппликацию готовых блоков с нуля сделаем, например, проводку документа поступления товаров и услуг. Пересчитаем остатки на складах и средневзвешенную себестоимость, обновим сальдо договора и, наконец, пометим документ проведенным. Без написания алгоритма на языке программирования.

Разрушитель модели Лего из 2000+ деталей

Эксперимент проведен в простом no-code конструкторе, где можно задать схему данных, вбить сами данные согласно этой схеме, сделать отчеты в построителе запросов и накликать простые формы.

Кто не любит читать, по запросу в комментариях я дамссылку на видео-версию с более полным описанием процесса.

Важная оговорка: рассмотренная здесь задача выбрана только для демонстрации примера расчетов no-code, а терминология может раздражать, например, специалиста 1С. Терминология и организация не важны, мы обсуждаем механизм расчетов без кода.

Коротко о предметной области. Есть понятие движение в рамках какого-то договора с контрагентом. У договора есть сальдо сумма нашего долга контрагенту. Движение показывает, какое количество товара (номенклатуры) поступает и расходуется со склада. Для каждой номенклатуры мы храним остатки на складах, вычисляем себестоимость.

Схема данных рисуется в визуальном редакторе и пока не требует кода. Вот она: связанные и подчиненные объекты располагаются правее своего родителя.

Проводка означает отражение сумм документов на сальдо договора и остатках на складах. В результате проводки мы снимем пометку Черновик с документа и изменим сальдо по договору на сумму движения. Если на эту дату записи Сальдо нет, то мы создадим её. Также мы пересчитаем остатки товаров на складе. Если записи по остаткам на этот день нет, то мы её создадим.

Данные, введенные в систему согласно этой структуре, выглядят примерно таким образом:

Это шапки наших документов со ссылками на связанные объекты, а ещё у них есть табличная часть, где перечислены товары. Количество это подчиненный массив записей, в который можно провалиться и увидеть список, например, такой:

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

Итак, мы задали структуру и вбили или импортировали данные по документам, номенклатурам, складам и прочему. Пока обошлись без программирования на каком-либо языке.

Чтобы провести документ, нам надо выбрать все данные для расчета, произвести вычисления и записать результаты в эту базу данных. Мы используем механизм запросов. Запросом мы выбираем нужные значения, пишем расчетные формулы и указываем, куда записать результат.

Вот так выглядит и работает конструктор запросов, в котором мы выбираем нужные нам данные:

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

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

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

Если добавить в запрос атрибуты связанных сущностей, то конструктор запросов сам свяжет нужные таблицы и выведет результат.

В следующем случае запрос объединит таблицы шапки документа, справочника договоров, регистров сальдо с фильтром на дату документа:

Будь мы программистами SQL, мы бы написали операторы JOIN ON и WHERE, написав соответствующие условия на объединение таблиц и отбор только тех Сальдо, которые относятся к дате документа. Здесь же мы задали имя формулы в нашей колонке Движение, а затем использовали это имя в фильтре по дате, взяв в квадратные скобки. Конструктор сам извлёк и объединил нужные нам данные, мы только наложили дополнительное условие по дате сальдо.

Мы не учим SQL, чтобы сконфигурировать всё это, но нам пришлось изучить некоторые правила работы с функциями и использование квадратных скобок, чтобы конструктор однозначно понял, чего мы хотим.

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

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

Вычисленные значения можно присвоить вместо имеющихся в базе данных, записав их в поле SET Присвоить:

Мы задаем нужное нам выражение в поле SET колонки Сальдо, а конструктор запишет его результат вместо существующего значения сальдо.

Если требуется, мы можем посмотреть, какие изменения будут внесены в базу, прежде чем подтвердим их. Содержание будущих изменений выделено красным:

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

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

Получившийся запрос Сальдо вставим в выражение в поле SET, чтобы получить корректное значение сальдо, даже если записи о предыдущем сальдо нет:

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

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

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

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

• ROUND(x, 2) округление x до двух знаков после запятой (аналог в экселе ОКРУГЛ())

• IF(A, B, C) если условие A верно, то вернуть B, иначе C (аналог ЕСЛИ())

• x IS NULL Истина, если x пустое или неизвестно (аналог ЕПУСТО())

• SUM(x) просуммировать все x с группировкой по остальным полям (аналог СУММА())

• abn_ID возвращает внутренний ID объекта, нужна для однозначного его определения

Этот запрос делает всё то, что мы собирались сделать в начале этой заметки инвертирует пометку Черновик у документа, пересчитывает сальдо договора, остатки товаров на складе и их средневзвешенную себестоимость. То есть, он проводит документы, но также умеет откатить проводку и вернуть все остатки, себестоимости и сальдо, как было!

Он использует результаты трёх вложенных запросов собирает данные по остаткам, себестоимости и сальдо. Они просты и однотипны:

Запрос на выборку последнего известного сальдо до даты проводки включительноПоследняя посчитанная себестоимость этого товараПоследний известный остаток номенклатуры этой позиции документа

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

На базу данных, механизмы проводки документов, отчеты и сводные формы вам понадобится всего пара дней в no-code платформе общего назначения (всё-в-одном). Чаще всего, придется доделать ещё какие-то элементы визуализации, например, вызов того же запроса проводки, с ожиданием результата и перенаправлением в следующее рабочее место. Эти элементы, вероятно, займут больше времени, чем накликать то, что я вам здесь показал.

Подводя итог, вам часто придется программировать даже в no-code и low-code системах, однако большую часть функционала вы сможете сделать, не владея программированием, и в достаточно короткий срок.

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

---

Применимость low-code: случаи, когда уникальная интеграция и визуализация занимают 90% усилий проекта и длятся, условно, 4 дня на проекте в 1 неделю. Часто базу данных и бэкенд можно накликать за 1 день, вместо 1-2 недель в традиционной разработке.

---

Пример, рассмотренный в статье, был сделан по ТЗ для простого приложения в 1С. В конструкторе с чистого листа были реализованы бизнес-сущности и формы ввода документов, которые уже есть в 1С. Для сравнения приведу некоторые факты (сравнение весьма субъективное, ибо 1С крут в своём сегменте, а тут нам нужно быстро собрать MVP):

Ссылки на исходники, демо-версию сервиса и ролики по мотивам этой заметки, если кому захочется пощупать и во всем убедиться, я дам в комментариях.

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

Другое дело, что следует продумать архитектуру системы, а в случае необходимости трансформировать её, для чего нужен опыт разработки. Да, сильные разработчики будут востребованы даже во времена no-code, если таковые всё-таки наступят.

Ещё, говоря о серьезном продукте, следует вспомнить про релизы, версионность, масштабируемость, авто-тесты, CI/CD и прочие сопутствующие вещи. Здесь всё достаточно просто конструктор, так же как и любая система, может быть покрыт стандартными процедурами. Можно выгрузить его состояние в гит, сравнить версии, оформить релиз и процедуру отката, но это тема отдельной статьи.