«Области тьмы» ИТ: платформы управления данными

[DenSigma]

Я правильно понимаю, что вы показываете, как запрограммировать систему, вместо Java, на JSON?

[ilemusic]

Чуть подробнее вот здесь описано:

Можно сказать, что такие платформы можно отнести к low-code классу. Частично это так, но не совсем. Low-code во многом применяется только в части построения модели данных или UI, но для сложных процессов в любом случае требуется полноценное программирование. Платформа как раз "убирает" рутинные операции, а разработчик сосредотачивает всё своё время на программировании конкретного процесса, используя простые платформенные абстракции.

Это означает, что если требуется обеспечить пользователей какими-то простыми CRUD-операциями, то программирование не потребуется вообще. Если например, при смене статуса объекта, необходимо выполнить отправку "хитрого" уведомления, то конечно эту функцию надо написать (или взять готовую платформенную), а затем указать в конфиге, что-то типа этого:

{
  "states": {
    "New" : {
      "promoteAction": "ru.platform.Mail:sendEmail"
    },
    "Approval": {
      
    }
  }
}

Здесь я показал на JSON'e, некоторые платформы используют XML или более специфичные форматы. Так было раньше. Сейчас, на мой взгляд, есть более удачное и современное решение для конфигураций. Думаю напишу об этом в следующей статье.

[DenSigma]

Позволю себе еще раз повторить свою мысль.

Программирование требуется всегда. Это заблуждение и маркетинговое вранье продаванов "нокод" систем, что вам не придется программировать. Для разработки, доработки, "конфигруции" и прочего допиливания всегда необходимо программирование. Программирование - суть появления софта.

Только вместо программирования на Java, Delphi, Шарпа, вы будете "программировать" на джейсоне, каких-то самопальных языках разметки, скриптовых общепринятых и самопальных скриптовых языках, типа одинэсной ахинеи.

В crud-операциях, как минимум, надо где-то описать модель базы данных, связи и прочее. Вместо java-кода, вам придется "программировать" на Json, или упаси боже, на xml. Аргумент, почему эти конфиги хуже простого кода на Java - в Spring ушли от конфигов на xml в сторону кода Java. И стало проще и читабельнее.

Ваш пример с конфигурацие хитрого уведомления - просто пример ужаса. Код Java, который будет решать данный функционал, будет проще и короче. Его можно будет отлаживать очень просто. Код на Java отлично автодополняется и проверяется компилятором. Вашу конфигурацию, чтобы проверить, что вы не наврали с синтаксисом, придется проверять запуском приложения и тычком на кнопку. При этом надо промудохаться с поднятием стенда. Да еще надо сформировать пример Customer-а, к примеру, чтобы добраться к нужному интерфейсу и функционалу. Чтобы удостовериться, что вы не написали ru.platform.Mail:sеndEmail (найдите здесь ошибку).

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

[ilemusic]

Да, в целом всё верно мыслите, я абсолютно согласен.

либо сбрасывают эту работу на команды лохов из регионов, чтобы они деградировали.

Грубовато. Обижаете спецов. В каждой системе есть свои особенности, где-то ABAP, где-то синтаксис на русском... Каждый сам выбирает "сторону". Кому-то - узкая специализация равна смерти, а кто-то прекрасно себя чувствует в ней.

И тем не менее, конкретно в нашей индустрии, факт остаётся фактом - то что будет 6 месяцев разрабатываться с нуля на java плюс frontend, на платформе я легко сделаю за 3 недели.