Низькокодовий проти

За останні кілька десятиліть було здійснено низку ініціатив щодо вилучення або принаймні мінімізації програмування з процесу розробки. Нинішнім результатом є програмування з низьким кодом, яке, однак, слід вимірювати по відношенню до функціонального програмування, яке також діє на кодовій дієті.

Завжди великою мрією ІТ-управління було розробка програмного забезпечення без програміста. Якби це було можливо, це означало б в основному можливість обійтися без дорогих розробників. У 1980-х існували так звані 4GL, мови програмування четвертого покоління. Це зробило типові функції багатьох програмних додатків одразу доступними, і, отже, повинно значно зменшити зусилля програмування. Зазвичай це стосується додатків, в яких користувачі по суті вводять дані, які зберігаються в базах даних, відображаються знову і обробляються у звіти.

Ще одну грань цього мислення можна знайти в незліченних аркушах Excel, які використовуються компаніями для вирішення важливих ІТ-завдань. Насправді навіть співробітники, які не навчені програмуванню, можуть використовувати Excel для виконання завдань значної складності, можливо, підкріплених кодом у VBA (Visual Basic for Applications). Найпізніше, коли надходить код VBA, стає очевидним, що створення аркушів Excel - це також форма програмування. Настільки легко, як непросто для початку, аркуші Excel з часом досягнуть своїх меж. Це стосується насамперед автоматизації великих процесів, обробки більших обсягів даних або чистої інтеграції в корпоративні ІТ. Майбутня міграція часто болюча і дорога.

Ймовірно, найуспішнішим проектом демократизації описаних "програм баз даних" є Microsoft Access: Незрівнянно просто зібрати CRUD-додаток (Створити, Читати, Оновити, Видалити) із графічним інтерфейсом користувача зі схем баз даних клацанням миші. Але те саме стосується і цього: Доступ до програм масштабується лише в дуже обмеженому обсязі. Коли вимоги зростають, часто трапляються болісні міграції.

Від історії жахів до казки: Написання коду, яке люди хочуть прочитати

Майкл Дауден (Галактичні рішення Андромеди)

Створення гібридної та багатохмарної стратегії за допомогою Azure API Management

Модуль ADOC - архітектурна документація - запис та передача архітектур програмного забезпечення

з тренером Штефаном Цорнером

Прагнення «розробити програмне забезпечення без програмування» призвело до низького рівня коду

4GL в якийсь момент втратили своє значення у 1990-х роках, оскільки були надто специфічними та обмеженими. Прагнення керівництва до "розробки програмного забезпечення без програмування" залишалося, і тому рух знову піднявся у вигляді "платформ з низьким кодом", які натякають саме на це. Натомість програми складаються з блоків у графічному середовищі і можуть вводитися в експлуатацію безпосередньо на масштабованих хмарних платформах, часто як мобільні веб-програми. Обмежена масштабованість Excel або Access тут більше не є проблемою.

Однак при детальному розгляді виявляються ті самі обмеження на платформи з низьким кодом, що і в той час, коли застосовувались 4GL, Access і - в певному сенсі - також Excel: Поки програмний додаток стосується лише введення, відображення та звітності табличних даних, ви з ними досить далеко. Крім цього досить поганого уявлення про те, що може зробити програмне забезпечення, низькокод бивається про стіну.

Приклад: Програмування програми в транспортному секторі

Як виглядає цей бетон? Наприклад, припустимо, що мета - написати заяву для Техаського департаменту шосейних доріг, яка відстежує, які тварини перебувають на шосе і що з ними відбувається. Ми починаємо з малого, з броненосців. Агентство відстежує, чи броненосці живі (багатьох переїхали на шосе) і скільки вони важать. У класичному додатку бази даних це починається з таблиці "Armadillos" наступним чином:

Ідентифікатор	живий?	вага
1	Правда	10
2	помилковий	12-й
3	Правда	9

Перший рядок представляє живого броненосця вагою 10 кг, другий мертвого вагою 12 кг тощо. У додатку з низьким кодом тепер маску можна скласти графічно, за допомогою якої можна управляти цією таблицею. Це означає, що можна вводити нові броненосці, відображати таблицю тощо.

У Low-Code також можна створити кнопку, яку користувач натискає, коли повідомляється про перебіг броненосці. Кнопка описує робочий процес, часто у поданні, подібному до BPMN. Сюди входить дія, яка описує, що насправді відбувається. Це може виглядати приблизно так:

Все йде нормально. Припустимо, програма розширюється, включаючи папуг, які раптово з’явилися на шосе. Ці папуги можуть бути перелічені в таблиці "Папуги":

ідентифікатор	Вирок	Вага
1	"Хороший день!"	2
2	"Надобраніч"	1.5

І тут теж можна визначити дію, яка описує перебіг папуги:

Також поки що добре. Але як щодо того, коли броненосці та папуги повинні керуватися разом? Вони перелічені у двох різних таблицях, що ускладнює це. Поняття "тварина - броненосець або папуга" не може бути прямо виражене в реляційних базах даних. Варто спробувати різні обхідні шляхи,

великий стіл із усіма колонками з "Armadillos" та "Parrots" та ще однією колонкою, яка говорить про те, що це за тварина, або
таблиця з двома стовпцями, які містять посилання на дві існуючі таблиці, лише одна з яких активна одночасно.

Вирішення проблеми ще деякий час було б можливим, але це швидко призвело б до безладу. Як би це виглядало, якби існував якийсь більш прямий спосіб моделювання цих шосейних тварин? Формулювання на функціональній мові Haskell буде виглядати так:

Вертикальна смуга | означає "або". Відповідно, там сказано: Тварина - це або

броненосець, Armadillo, із властивістю armadilloAlive типу Bool та властивістю armadilloWeight типу Float або
папуга як з комплектом, так і з ваговими характеристиками

Можна створити список для реєстрації популяції тварин:

Тож не проблема змішати обидва класи тварин. Це, звичайно, також можливо в об'єктно-орієнтованому програмуванні, але для цього потрібен інтерфейс та два порівняно складні класи програмування. Тому рішення Haskell має ті переваги, що їм вдається керувати меншою кількістю коду, і код безпосередньо базується на моделюванні.

Операції також можна визначити з дуже невеликим кодом. Наприклад, наїзд. Визначення Хаскелла складається з двох рівнянь - по одному на клас:

Що стосується кількості коду, функціональне програмування все ще має перевагу перед низьким кодом. Однак набагато важливішим є те, що функціональний код можна розвивати далі у міру зростання вимог, тоді як середовище з низьким кодом досягає своїх меж.

Сучасні середовища з низьким кодом - це свого роду "Enterprise Cloud 4GLs"

Сучасні середовища з низьким кодом, безсумнівно, спрощують багато “стандартних завдань” у програмуванні, особливо при підключенні до бази даних та дизайні графічних інтерфейсів користувача: досить клацнути все разом. Тож певною мірою "Enterprise Cloud 4GL" усувають проблеми масштабування операційної системи Excel та Access. Можна майже здивуватися, що “звичайні” технології програмування не пропонують нічого подібного.

Але лише майже: Для кожної респектабельної об’єктно-орієнтованої мови програмування існують “ORM”, тобто об’єктно-реляційні картографи, які автоматизують багато завдань при відображенні об’єктів домену в базі даних. Як і у випадку з ORM, ця зручність купується за рахунок першого підключення в новій архітектурі: модель бази даних нерозривно пов’язана з моделлю даних, обидві повинні розвиватися разом і, отже, успадковувати примхи один одного. Це призводить до безлічі проблем, коли код зростає: згадані слабкі сторони моделювання, неконтрольована поведінка кешу, складна налагодження та великі зусилля при внесенні змін. Відповідно, ORM вийшли з моди навіть після початкової ейфорії.

Подібна ситуація і з інтерфейсами користувача. Вони тісно пов'язані з моделями даних у середовищах з низьким кодом (як у великих наборах побудови інтерфейсу в минулому - Visual Basic 6 та Delphi).

Обмежена масштабованість: Який вихід із дилеми існує?

Середовища з низьким кодом дозволяють "швидке прототипування" для простих додатків, але не зростають разом із вимогами. Java і C # краще масштабуються, але великі зусилля та витрати витрачають бюджет і особливо душу розробника. З іншого боку, функціональні мови спочатку виробляють менше коду, так би мовити "нижчий код". Ви не все автоматизуєте, але відмінна підтримка програмування інтерфейсу та баз даних призводить до компактних рішень без страшної архітектурної зв'язку.

Однак набагато важливіше те, що повинно бути нам близьким: Підтримка моделей високого рівня, які точно відображають спеціалізовані домени та гнучко зростають разом із ними. Що стосується моделювання, то у функціональному програмуванні відкриваються нові світи - завдяки рівномірному використанню абстракції та застосуванню математики. Все це може звучати так, ніби функціональне програмування зарезервоване для висококваліфікованих фахівців. Насправді, це найуспішніший підхід у навчанні програмуванню, тому його можуть навчитися всі фахівці з програмування.