Нисък код срещу
© Shutterstock/Визуално поколение
През последните няколко десетилетия имаше редица инициативи за премахване или поне свеждане до минимум на програмирането от процеса на разработка. Текущият резултат е програмиране с нисък код, което обаче трябва да се измерва спрямо функционалното програмиране, което също е на кодова диета.
Винаги е била голямата мечта на ИТ управлението: разработване на софтуер без програмист. Ако това беше възможно, това би означавало, че скъпите разработчици биха могли да се откажат до голяма степен. През 80-те години имаше така наречените 4GL, четвърто поколение езици за програмиране. Те направиха типичните функции на много софтуерни приложения веднага достъпни и по този начин трябва драстично да намалят усилията за програмиране. Това обикновено включва приложения, в които потребителите по същество въвеждат данни, които се съхраняват в бази данни, показват се отново и се обработват в отчети.
Друг аспект на това мислене може да се намери в безбройните листове на Excel, които се използват в компаниите за критични ИТ задачи. Всъщност дори служители, които не са обучени по програмиране, могат да използват Excel за изпълнение на дори задачи със значителна сложност, вероятно подкрепени от код във VBA (Visual Basic за приложения). Най-късно, когато кодът на VBA пристигне, става очевидно, че създаването на листове на Excel също е форма на програмиране. Колкото и лесно да започват непрограмистите, листата на Excel в крайна сметка ще достигнат своите граници. Това се отнася преди всичко за автоматизацията на по-големи процеси, обработката на по-големи количества данни или чистата интеграция в корпоративните ИТ. Предстоящата миграция често е болезнена и скъпа.
Вероятно най-успешният проект за демократизиране на описаните "приложения за бази данни" е Microsoft Access: Ненадминато лесно е да се събере CRUD приложение (Създаване, четене, актуализиране, изтриване) с графичен потребителски интерфейс от схеми на база данни с едно щракване на мишката. Но същото важи и тук: Приложенията за достъп се мащабират в много ограничена степен. Когато изискванията се увеличават, често има болезнени миграции.
От историята на ужасите до приказката: Писане на код, който хората искат да прочетат
Майкъл Даудън (галактически решения Andromeda)
Създаване на хибридна и многооблачна стратегия с помощта на Azure API Management
Модул ADOC - архитектурна документация - запис и комуникация на софтуерни архитектури
с треньор Стефан Цьорнер
Желанието за „разработване на софтуер без програмиране“ доведе до нисък код
4GLs загубиха значението си в даден момент през 90-те години, защото бяха твърде специфични и ограничени. Желанието на ръководството за „разработване на софтуер без програмиране“ остана и затова движението възкръсна под формата на „платформи с нисък код“, които предполагат точно това. Вместо това приложенията са съставени от блокове в графична среда и могат да бъдат пуснати в експлоатация директно на мащабируеми облачни платформи, често като мобилни уеб приложения. Ограничената мащабируемост на Excel или Access вече не е проблем тук.
Въпреки това, по-внимателният поглед разкрива същите ограничения за нискокодовите платформи, както по това време с 4GL, Access и - в определен смисъл - и Excel: Докато софтуерното приложение е само за въвеждане, показване и отчитане на таблични данни, вие идвате с тях доста далеч. Отвъд тази доста лоша картина на това, което може да направи софтуерът, нисък код удря в стена.
Пример: Програмиране на приложение в транспортния сектор
Как изглежда този бетон? Да кажем например, че целта е да се напише заявление за Тексаския магистрален отдел, което да проследява какви животни са на магистралата и какво се случва с тях. Започваме малко, с броненосците. Агенцията следи дали броненосците са живи (много са прегазени по магистралата) и колко тежат. В класическо приложение за база данни това започва с таблица "Armadillos", както следва:
| Документ за самоличност | жив? | тегло |
| 1 | Вярно | 10 |
| 2 | Невярно | 12 |
| 3 | Вярно | 9 |
Първият ред представлява жив броненосец с тегло 10 кг, вторият мъртъв с тегло 12 кг и т.н. В приложение с нисък код вече може да се състави графично маска, с която да се управлява тази таблица. Това означава, че могат да се въвеждат нови броненосци, да се показва таблицата и т.н.
В Low-Code също е възможно да се създаде бутон, който потребителят да натисне, когато се съобщи, че е преминал броненосец. Бутонът описва работен поток, често в BPMN-подобно представяне. Това включва действие, което описва какво всъщност се случва. Може да изглежда по следния начин:
Дотук добре. Да предположим, че приложението се разширява, за да включва папагали, които внезапно се появиха на магистралата. Тези папагали могат да бъдат изброени в таблица "Папагали":
| документ за самоличност | Изречение | Тегло |
| 1 | "Добър ден!" | 2 |
| 2 | "Лека нощ" | 1.5 |
И тук също може да се дефинира действие, което описва прегазването на папагал:
Също така засега добре. Но какво ще кажете, когато броненосците и папагалите трябва да се водят заедно? Те са изброени в две различни таблици, което прави това трудно. Понятието "животно е броненосец или папагал" не може да бъде пряко изразено в релационни бази данни. Струва си да се опитат различни решения,
- голяма таблица с всички колони от „Армадилос“ и „Папагали“ и друга колона, която казва за какво животно става въпрос, или
- таблица с две колони, които съдържат препратки към двете съществуващи таблици, само една от които е активна в даден момент.
Заобиколното решение ще бъде осъществимо за известно време, но бързо ще доведе до бъркотия, която не може да се използва. Как би изглеждало, ако имаше някакъв по-директен начин за моделиране на тези магистрални животни? Формулировка на функционалния език Haskell ще изглежда така:
Вертикалната лента | означава "или". Съответно се казва: Животното е или
- броненосец, Armadillo, със свойството armadilloAlive от тип Bool и свойството armadilloWeight от тип Float или
- папагал с набор и характеристики на теглото
Може да се създаде списък за записване на популацията от животни:
Така че не е проблем да се смесят и двата класа животни. Това разбира се е възможно и при обектно-ориентираното програмиране, но това ще изисква интерфейс и два сравнително сложни класа на програмиране. Следователно решението Haskell има предимствата, че се справя с по-малко код и кодът се основава директно на моделирането.
Операциите също могат да бъдат дефинирани с много малко код. Например, прегазване. Дефиницията на Haskell се състои от две уравнения - по едно за клас:
Що се отнася до количеството код, функционалното програмиране все още има предимство пред ниския код. Много по-важно обаче е, че функционалният код може да се доразвива с нарастването на изискванията, докато средата с нисък код достига своите граници.
Съвременните среди с нисък код са един вид „Enterprise Cloud 4GLs“
Съвременните среди с нисък код несъмнено опростяват много „стандартни задачи“ в програмирането, особено що се отнася до връзката с базата данни и дизайна на графични потребителски интерфейси: достатъчно е да щракнете върху всичко заедно. Така че до известна степен "Enterprise Cloud 4GLs" елиминира оперативните проблеми с мащабирането на Excel и Access. Почти бихме могли да се изненадаме, че „конвенционалните“ програмиращи технологии не предлагат нищо подобно.
Но само почти: За всеки уважаван обектно-ориентиран език за програмиране има "ORMs", т.е. Object-Relational Mappers, които автоматизират много задачи при картографиране на обект на домейн в базата данни. Точно както при ORM, това удобство се купува с цената на първата връзка в нововъзникващата архитектура: моделът на базата данни е неразривно свързан с модела на данни, и двата трябва да се развиват заедно и следователно да наследяват странностите на другия. Това води до множество проблеми, когато кодът расте: споменатите слабости при моделиране, неконтролируемо поведение на кеша, трудно отстраняване на грешки и големи усилия при извършване на промени. Съответно ORM са излезли от мода дори след първоначалната еуфория.
Подобна е ситуацията и с потребителските интерфейси. Те са тясно свързани с моделите на данни в среди с нисък код (както в големите комплекти за изграждане на потребителски интерфейс от миналото - Visual Basic 6 и Delphi).
Ограничена мащабируемост: Какъв изход от дилемата има?
Средите с нисък код позволяват "бързо прототипиране" за прости приложения, но не се развиват заедно с изискванията. Java и C # се мащабират по-добре, но високите разходи и големите обстоятелства изтощават бюджета и най-вече душата на разработчика. Функционалните езици, от друга страна, първоначално произвеждат по-малко код, "по-нисък код", така да се каже. Не автоматизирате всичко, но отличната поддръжка за програмиране на потребителски интерфейс и бази данни води до компактни решения без страховитата архитектурна връзка.
Много по-важно обаче е това, което трябва да ни е на сърцето: Подкрепа за модели на високо ниво, които точно картографират специализирани домейни и растат гъвкаво с тях. Що се отнася до моделирането, във функционалното програмиране се отварят нови светове - чрез еднаквото използване на абстракция и прилагането на математиката. Всичко може да звучи така, сякаш функционалното програмиране е запазено за висококвалифицирани специалисти. Всъщност обаче това е най-успешният подход в обучението по програмиране и следователно може да се научи от всички професионалисти по програмиране.