Низок код наспроти

Во последните неколку децении имаше голем број иницијативи за отстранување или барем минимизирање на програмирањето од процесот на развој. Тековниот резултат е програмирање со низок код, што, сепак, мора да се мери според функционалното програмирање, кое исто така е на диета со кодови.

Отсекогаш бил голем сон за управување со ИТ: развој на софтвер без програмер. Ако тоа беше можно, тоа ќе значеше во голема мера да се направи без скапи програмери. Во 80-тите години на минатиот век постоеја таканаречени 4GL, програмски јазици од четврта генерација. Овие ги направија типичните функции на многу софтверски апликации веднаш достапни и на тој начин треба драстично да ги намалат напорите за програмирање. Ова обично вклучува апликации во кои корисниците во суштина внесуваат податоци што се зачувани во базите на податоци, повторно се прикажуваат и се обработуваат во извештаи.

Друг аспект на ова размислување може да се најде во безброј листови на Excel кои се користат во компаниите за критични ИТ задачи. Всушност, дури и вработените кои не се обучени за програмирање можат да го користат Excel за извршување задачи со значителна сложеност, можеби поткрепени со код во VBA (Visual Basic за апликации). Најдоцна кога ќе пристигне VBA-кодот, станува очигледно дека креирањето на Excel листови е исто така форма на програмирање. Колку и да е лесно за почеток на не-програмерите, Excel листовите на крајот ќе ги достигнат своите граници. Ова се однесува пред се на автоматизацијата на поголемите процеси, управувањето со поголеми количини на податоци или чистата интеграција во корпоративниот ИТ. Претстојната миграција е често болна и скапа.

Веројатно најуспешниот проект за демократизација на опишаните „апликации за бази на податоци“ е Microsoft Access: Непобедливо е лесно да се собере CRUD апликација (Креирај, читај, ажурирај, избриши) со графички кориснички интерфејс од шеми на бази на податоци со кликнување на глувчето. Но, истото важи и овде: Апликациите за пристап само се обемуваат во многу ограничена мерка. Кога побарувањата се зголемуваат, често има болни миграции.

Од хорор приказна до бајка: Код за пишување што луѓето сакаат да го прочитаат

Мајкл Доуден (галактички решенија на Андромеда)

Создавање хибридна и мулти-облачна стратегија со користење на Azure API Management

ADOC модул - архитектурна документација - запишува и комуницира архитектури на софтвер

со тренерот Стефан Зирнер

Theелбата за „развој на софтвер без програмирање“ доведе до низок код

4GL изгубија важност во одреден момент во 90-тите години на минатиот век, бидејќи тие беа премногу специфични и ограничени. Desireелбата на раководството за „развој на софтвер без програмирање“ остана, и затоа движењето повторно се зголеми во форма на „платформи со низок код“ кои го сугерираат токму тоа. Наместо тоа, апликациите се составени од блокови во графичко опкружување и можат да се стават во функција директно на скалабилни облачни платформи, честопати како мобилни веб-апликации. Ограничената приспособливост на Excel или Access веќе не е проблем тука.

Сепак, одблизу ги открива истите ограничувања на платформите со низок код како во времето со 4GL, пристап и - во одредена смисла - исто така и Excel: Сè додека софтверската апликација има за цел само внесување, прикажување и пријавување табеларни податоци, вие доаѓате со нив доста далеку. Надвор од оваа прилично лоша слика за тоа што може да стори софтверот, низок-кодот го погодува wallидот.

Пример: Програмирање апликација во транспортниот сектор

Како изгледа тој бетон? На пример, да речеме дека целта е да напишете апликација за Министерството за автопати во Тексас што следи што се животните на автопатот и што се случува со нив. Почнуваме мали, со армадило. Агенцијата води евиденција дали армадиловите се живи (многумина се прегазени на автопатот) и колку тежат. Во класична апликација за бази на податоци, ова започнува со табела "Armadillos" како што следува:

ИД	жив?	Тежина
1	Вистина	10
2	Лажни	12-ти
3	Вистина	9

Првата линија претставува жив армадило со тежина од 10 кг, втората мртва со тежина од 12 кг итн. Во апликација со низок код, сега може да се состави маска графички со која може да се управува со оваа табела. Ова значи дека може да се внесат нови армадилови, да се прикаже табелата, итн.

Во „Низок-код“ исто така е можно да се создаде копче што корисникот ќе го притисне кога ќе се објави дека е прегазен армадило. Копчето го опишува работниот тек, честопати во претстава слична на BPMN. Ова вклучува акција што опишува што всушност се случува. Може да изгледа вакво нешто:

Досега добро. Да претпоставиме дека апликацијата се прошири и вклучува папагали кои одеднаш се појавија на автопатот. Овие папагали може да бидат наведени во табелата „Папагали“:

ид	Реченица	Тежина
1	"Добар ден!"	2
2	"Добра ноќ"	1.5

И тука исто така може да се дефинира акција што го опишува прегазениот папагал:

Исто така досега толку добро. Но, што е со тоа кога армадилите и папагалите треба да бидат водени заедно? Тие се наведени во две различни табели, што го отежнува тоа. Концептот „животно е армадило или папагал“ не може директно да се изрази во релациони бази на податоци. Вреди да се испробаат разни решенија,

голема маса со сите колони од „Армадилос“ и „Папагали“ и друга колона на која пишува за какво животно станува збор, или
табела со две колони кои содржат упатувања на двете постојни табели, од кои само едната е активна истовремено.

Заобиколувањето сепак би било изводливо за некое време, но брзо би резултирало во несервисен хаос. Како би изгледало ако има некој подиректен начин за моделирање на овие автопатски животни? Формулација на функционалниот јазик Хаскел би изгледала вака:

Вертикалната лента | значи „или“. Соодветно на тоа, се вели: Anивотно е или

армадило, Армадило, со имотот армадило lив од типот Бул и имотот армадило Тежина од типот Плови или
папагал и со во собата и со карактеристиките на тежината

Може да се креира список за евидентирање на популацијата на животните:

Значи, не е проблем да се мешаат двете класи животни. Ова е, се разбира, исто така можно во објектно-ориентираното програмирање, но за ова ќе бидат потребни интерфејс и две релативно сложени програмски класи. Затоа, решението Haskell има предности што управува со помалку код и кодот е директно заснован на моделирањето.

Операциите исто така може да се дефинираат со многу малку код. На пример, прегазен. Дефиницијата Хаскол се состои од две равенки - една по класа:

Што се однесува до количината на код, функционалното програмирање сè уште има предност во однос на нискиот код. Сепак, многу поважно е дека функционалниот код може да се развива понатаму како што растат барањата, додека околината со низок код ги достигнува своите граници.

Современите средини со низок код се еден вид „Enterprise Cloud 4GL“

Современите средини со низок код несомнено поедноставуваат многу „стандардни задачи“ во програмирањето, особено во поврзувањето со базата на податоци и дизајнот на графички кориснички интерфејси: доволно е да кликнете на сè заедно. Значи, тоа е до одредена мерка „Enterprise Cloud 4GL“ кои ги елиминираат проблемите со оперативното скалирање на Excel и Access. Скоро би можело да се изненади што „конвенционалните“ технолошки програми не нудат ништо слично.

Но, скоро скоро: За секој респектабилен објектно-ориентиран програмски јазик има „ORM“, т.е. Објектно-релациони пресликувачи, кои автоматизираат многу задачи при мапирање на доменските објекти на базата на податоци. Исто како и со ORM, оваа погодност се купува по цена на првата врска во новонастанатата архитектура: моделот на база на податоци е неразделно поврзан со моделот на податоци, и двете мора да се развиваат заедно и затоа да ги наследуваат едни со други чудаци. Ова доведува до мноштво проблеми кога кодот расте: споменатите слабости на моделирање, неконтролирано однесување на кешот, тешко дебагирање и голем напор при правење измени. Соодветно на тоа, ОРМ паднаа од мода дури и по првичната еуфорија.

Слична е ситуацијата и со интерфејсите. Тие се тесно поврзани со моделите на податоци во средини со низок код (како во големите комплети за конструкција на UI од минатото - Visual Basic 6 и Delphi).

Ограничена приспособливост: Каков излез од дилемата постои?

Средините со низок код овозможуваат „брзо прототипирање“ за едноставни апликации, но не растат заедно со барањата. Java и C # скалата се подобри, но големиот напор и трошок го трошат буџетот, а особено душата на инвеститорот. Функционалните јазици, од друга страна, првично произведуваат помалку код, „понизок код“, така да се каже. Вие не автоматизирате сè, но одличната поддршка за програмирање и бази на податоци на кориснички интерфејс доведува до компактни решенија без застрашувачката архитектонска спојка.

Сепак, многу поважно е она што треба да ни биде при срце: Поддршка за модели на високо ниво кои прецизно мапираат специјализирани домени и растат флексибилно со нив. Што се однесува до моделирањето, се отвораат нови светови во функционалното програмирање - преку униформна употреба на апстракција и примена на математика. Сето тоа може да звучи како функционалното програмирање да е резервирано за високо квалификувани специјалисти. Всушност, сепак, тоа е најуспешниот пристап во програмската обука и затоа може да го научат сите професионални програмисти.