Cod scăzut vs.

În ultimele decenii au existat o serie de inițiative pentru eliminarea sau cel puțin minimizarea programării din procesul de dezvoltare. Rezultatul actual este programarea cu cod redus, care, totuși, trebuie măsurată în raport cu programarea funcțională, care este, de asemenea, pe o dietă de cod.

A fost întotdeauna marele vis al managementului IT: dezvoltarea de software fără programator. Dacă acest lucru ar fi posibil, ar însemna că dezvoltatorii scumpi ar putea fi renunțați în mare măsură. În anii 1980 existau așa-numitele 4GL, limbaje de programare de a patra generație. Acestea au făcut funcțiile tipice ale multor aplicații software disponibile imediat și ar trebui astfel să reducă drastic efortul de programare. Aceasta implica de obicei aplicații în care utilizatorii introduc în esență date stocate în baze de date, afișate din nou și procesate în rapoarte.

O altă fațetă a acestei gândiri poate fi găsită în nenumăratele foi Excel care sunt utilizate în companii pentru sarcini IT critice. De fapt, chiar și angajații care nu sunt instruiți în programare pot folosi Excel pentru a efectua chiar sarcini de o complexitate considerabilă, eventual susținute de cod în VBA (Visual Basic pentru aplicații). Cel târziu la sosirea codului VBA, devine evident că crearea foilor Excel este, de asemenea, o formă de programare. Pe cât de ușor este pentru neprogramatori, foile Excel vor ajunge în cele din urmă la limitele lor. Acest lucru se aplică mai ales automatizării proceselor mai mari, manipulării unor cantități mai mari de date sau integrării curate în IT-ul corporativ. Viitoarea migrație este adesea dureroasă și costisitoare.

Probabil cel mai reușit proiect de democratizare a „aplicațiilor bazei de date” descrise este Microsoft Access: Este imbatabil de ușor să asamblați o aplicație CRUD (Creați, Citiți, Actualizați, Ștergeți) cu o interfață grafică de utilizator din schemele de baze de date cu un clic de mouse. Dar același lucru este valabil și aici: aplicațiile de acces se extind doar într-o măsură foarte limitată. Când cererile cresc, există adesea migrații dureroase și aici.

De la Horror Story la Fairy Tale: Scrierea codului pe care oamenii vor să o citească

Michael Dowden (Andromeda Galactic Solutions)

Crearea unei strategii hibride și multi-cloud folosind Azure API Management

Modul ADOC - documentație de arhitectură - înregistrează și comunică arhitecturi software

cu antrenorul Stefan Zörner

Dorința de „dezvoltare de software fără programare” a dus la scăderea codului

4GL-urile și-au pierdut importanța la un moment dat în anii 1990, deoarece erau prea specifice și limitate. Dorința conducerii de „dezvoltare de software fără programare” a rămas, astfel încât mișcarea a crescut din nou sub forma „platformelor cu cod redus” care sugerează tocmai acest lucru. În schimb, aplicațiile sunt compuse din blocuri într-un mediu grafic și pot fi puse în funcțiune direct pe platforme cloud scalabile, adesea ca aplicații web mobile. Scalabilitatea limitată a Excel sau Access nu mai este o problemă aici.

Cu toate acestea, o privire mai atentă relevă aceleași restricții pe platformele cu cod redus ca în acel moment cu 4GL-uri, Access și - într-un anumit sens - și cu Excel: Atâta timp cât o aplicație software se referă doar la introducerea, afișarea și raportarea datelor tabulare, veniți cu ele destul de departe. Dincolo de această imagine destul de slabă a ceea ce poate face software-ul, codul scăzut lovește un perete.

Exemplu: Programarea unei aplicații în sectorul transporturilor

Cum arată concret? De exemplu, să presupunem că scopul este să scrieți o aplicație pentru Departamentul Autostrăzii din Texas care să urmărească ce animale sunt pe autostradă și ce li se întâmplă. Începem mici, cu armadelele. Agenția ține evidența dacă armadelele sunt în viață (multe sunt lovite pe autostradă) și cât de mult cântăresc. Într-o aplicație clasică de baze de date, aceasta începe cu un tabel „Armadillos” după cum urmează:

Id	în viaţă?	greutate
1	Adevărat	10
2	Fals	Al 12-lea
3	Adevărat	9

Primul rând reprezintă un armadillo viu care cântărește 10 kg, al doilea un mort care cântărește 12 kg și așa mai departe. Într-o aplicație cu cod redus, o mască ar putea fi acum asamblată grafic cu care acest tabel poate fi gestionat. Aceasta înseamnă că pot fi introduse armadillo-uri noi, afișat tabelul etc.

În Low-Code este de asemenea posibil să creați un buton pe care utilizatorul îl apasă atunci când este raportat că un armadillo a fost rulat. Butonul descrie un flux de lucru, adesea într-o reprezentare asemănătoare BPMN. Aceasta include o acțiune care descrie ceea ce se întâmplă de fapt. Ar putea arăta cam așa:

Până acum, bine. Să presupunem că aplicația se extinde pentru a include papagali care au apărut brusc pe autostradă. Acești papagali ar putea fi enumerați într-un tabel „Papagali”:

id	Sentință	Greutate
1	"O zi buna!"	2
2	"Noapte bună"	1.5

Și aici, de asemenea, ar putea fi definită o acțiune care descrie alergarea unui papagal:

De asemenea, până acum, bine. Dar ce zici de când armadillo și papagali trebuie ghidați împreună? Acestea sunt listate în două tabele diferite, ceea ce face acest lucru dificil. Conceptul „un animal este un armadillo sau un papagal” nu poate fi exprimat direct în baze de date relaționale. Merită încercate diverse soluții,

o masă mare cu toate coloanele din „Armadillos” și „Papagali” și o altă coloană care spune ce fel de animal este sau
un tabel cu două coloane care conțin referințe la cele două tabele existente, dintre care doar una este activă la un moment dat.

Soluția de rezolvare ar fi totuși fezabilă pentru o vreme, dar ar duce rapid la o mizerie care nu este reparabilă. Cum ar arăta dacă ar exista un mod mai direct de a modela aceste animale de pe autostradă? O formulare în limbajul funcțional Haskell ar arăta astfel:

Bara verticală | înseamnă „sau”. În consecință, scrie: Un animal este fie

un armadillo, Armadillo, cu proprietatea armadilloAlive de tip Bool și armadillo proprietate Greutatea de tip Float sau
un papagal cu caracteristici atât de set cât și de greutate

Se poate crea o listă pentru a înregistra populația de animale:

Deci nu este o problemă să amesteci ambele clase de animale. Acest lucru este, desigur, posibil și în programarea orientată pe obiecte, dar acest lucru ar necesita o interfață și două clase de programare relativ complexe. Soluția Haskell are avantajele pe care le obține cu mai puțin cod, iar codul se bazează direct pe modelare.

Operațiunile pot fi, de asemenea, definite cu foarte puțin cod. De exemplu, a fi răsturnat. Definiția Haskell constă din două ecuații - una pe clasă:

În ceea ce privește cantitatea de cod, programarea funcțională are încă un avantaj față de codul redus. Cu toate acestea, mult mai important este că codul funcțional poate fi dezvoltat în continuare pe măsură ce cerințele cresc, în timp ce mediul cu cod redus își atinge limitele.

Mediile moderne cu cod redus sunt un fel de „Enterprise Cloud 4GL”

Mediile moderne cu cod redus simplifică, fără îndoială, multe „sarcini standard” în programare, în special în conexiunea la baza de date și proiectarea interfețelor grafice de utilizator: este suficient să faceți clic pe toate împreună. Deci, într-o anumită măsură, „Enterprise Cloud 4GL” elimină problemele operaționale de scalare ale Excel și Access. S-ar putea aproape să ne mirăm că tehnologiile de programare „convenționale” nu oferă nimic similar.

Dar aproape aproape: pentru fiecare limbaj de programare respectabil orientat pe obiecte există „ORM-uri”, adică Mappere relaționale cu obiectele, care automatizează multe sarcini atunci când mapează obiecte de domeniu în baza de date. La fel ca în cazul ORM-urilor, această comoditate este cumpărată cu prețul primei conexiuni din arhitectura emergentă: modelul bazei de date este legat indisolubil de modelul de date, ambele trebuie să se dezvolte împreună și, prin urmare, să moștenească ciudățile reciproce. Acest lucru duce la o multitudine de probleme atunci când codul crește: slăbiciunile de modelare menționate, comportamentul cache incontrolabil, depanarea dificilă și efortul mare la efectuarea modificărilor. În consecință, ORM-urile au căzut din modă chiar și după euforia inițială.

Este similar cu interfețele UI. Acestea sunt strâns legate de modelele de date din medii cu cod redus (la fel ca în seturile mari de construcție UI din trecut - Visual Basic 6 și Delphi).

Scalabilitate limitată: Ce cale de ieșire din dilemă există?

Mediile cu cod redus permit „prototiparea rapidă” pentru aplicații simple, dar nu cresc împreună cu cerințele. Java și C # se potrivește mai bine, dar costurile ridicate și circumstanțele extraordinare epuizează bugetul și, mai presus de toate, sufletul dezvoltatorului. Limbajele funcționale, pe de altă parte, produc inițial mai puțin cod, „cod mai mic” ca să spunem așa. Nu automatizați totul, dar suportul excelent pentru programarea UI și bazele de date duce la soluții compacte fără temuta cuplare arhitecturală.

Cu toate acestea, mult mai important este ceea ce ar trebui să ne fie aproape de inimă: asistență pentru modele la nivel înalt care să mapeze cu precizie domeniile de specialitate și să crească flexibil cu ele. În ceea ce privește modelarea, noi lumi se deschid în programarea funcțională - prin utilizarea uniformă a abstractizării și prin aplicarea matematicii. Totul poate suna ca și cum programarea funcțională este rezervată specialiștilor cu înaltă calificare. De fapt, totuși, este cea mai reușită abordare în formarea în programare și, prin urmare, poate fi învățată de toți profesioniștii în programare.