Alacsony kód vs.

Az elmúlt évtizedekben számos kezdeményezés történt a programozásnak a fejlesztési folyamatból való eltávolítására vagy legalábbis minimalizálására. A jelenlegi eredmény az alacsony kódú programozás, amelyet azonban a funkcionális programozáshoz kell mérni, amely szintén kóddimenziós.

Mindig is ez volt az informatikai menedzsment nagy álma: szoftver fejlesztése programozó nélkül. Ha ez lehetséges lenne, az nagyrészt azt jelentené, hogy drága fejlesztők nélkül is meg tudnánk menni. Az 1980-as években voltak úgynevezett 4GL-ek, negyedik generációs programozási nyelvek. Ezek sok szoftveralkalmazás tipikus funkcióit azonnal elérhetővé tették, és ezzel drasztikusan csökkenteniük kellett a programozási erőfeszítéseket. Ez általában olyan alkalmazásokat érintett, amelyekbe a felhasználók lényegében adatbázison tárolt, újra megjelenített és jelentésekké feldolgozott adatokat adnak meg.

Ennek a gondolkodásmódnak egy másik aspektusa megtalálható a számtalan Excel lapban, amelyeket a vállalatok kritikus informatikai feladatokhoz használnak. Valójában még azok az alkalmazottak is használhatják az Excel-t, amelyek nem rendelkeznek programozási képzettséggel, még a bonyolult feladatok elvégzésére is, amelyeket valószínűleg a VBA kódja támaszt alá (Visual Basic for Applications). Legkésőbb, amikor a VBA kód megtalálja az utat, nyilvánvalóvá válik, hogy az Excel lapok létrehozása a programozás egyik formája is. Amilyen egyszerű a nem programozók számára kezdeni, az Excel lapok végül elérik a határaikat. Ez mindenekelőtt a nagyobb folyamatok automatizálására, nagyobb mennyiségű adat kezelésére vagy a vállalati informatikába történő tiszta integrációra vonatkozik. A közelgő migráció gyakran fájdalmas és drága.

A leírt "adatbázis-alkalmazások" demokratizálásának valószínűleg a legsikeresebb projektje a Microsoft Access: Verhetetlenül könnyű egy grafikus felhasználói felülettel rendelkező CRUD-alkalmazást (létrehozás, olvasás, frissítés, törlés) adatbázis-sémákból egérkattintással összeállítani. De ugyanez vonatkozik itt: Az Access alkalmazások csak nagyon korlátozott mértékben terjednek. Amikor az igények növekednek, gyakran fájdalmas migrációk vannak.

A horrortörténettől a meséig: Kód írása, amit az emberek el akarnak olvasni

Michael Dowden (Andromeda Galactic Solutions)

Hibrid és többfelhős stratégia létrehozása az Azure API Management használatával

ADOC modul - architektúra dokumentáció - szoftver architektúrák rögzítése és kommunikálása

Stefan Zörner edzővel

A „szoftverfejlesztés programozás nélkül” vágy alacsony kódhoz vezetett

A 4GL-ek az 1990-es években valamikor elvesztették jelentőségüket, mert túl specifikusak és korlátozottak voltak. A vezetés vágya a „programozás nélküli szoftverfejlesztésre” továbbra is fennmaradt, ezért a mozgalom „alacsony kódú platformok” formájában feltámadt, amelyek pontosan erre utalnak. Ehelyett az alkalmazások grafikus környezetben lévő blokkokból állnak, és közvetlenül méretezhető felhőplatformokon működtethetők, gyakran mobil webalkalmazásokként. Az Excel vagy az Access korlátozott méretezhetősége itt már nem kérdés.

Közelebbről megnézve azonban ugyanazokat a korlátozásokat tárják fel az alacsony kódú platformokon, mint annak idején a 4GL-ek, az Access és - bizonyos értelemben - az Excel esetében is: Amíg egy szoftveralkalmazás csak táblázatos adatok bevitelére, megjelenítésére és jelentésére irányul, addig velük jársz elég messze. Ezen a szoftverképesség meglehetősen gyenge képén túl az alacsony kód a falhoz ütközik.

Példa: Alkalmazás programozása a közlekedési ágazatban

Hogy néz ki ez a konkrét? Tegyük fel például, hogy a cél egy olyan alkalmazás megírása a Texas Highway Department-hez, amely nyomon követi, hogy milyen állatok vannak az autópályán, és mi történik velük. Kicsiben kezdünk, a páncélosokkal. Az ügynökség nyomon követi, hogy a páncélosok élnek-e (sokukat elgázolnak az autópályán), és mennyit nyomnak. Egy klasszikus adatbázis-alkalmazásban ez egy "Armadillos" táblával kezdődik az alábbiak szerint:

Id	élő?	súly
1	Igaz	10.
2	Hamis	12.
3	Igaz	9.

Az első vonal egy élő, 10 kg súlyú fegyvert jelent, a második egy halott 12 kg-ot stb. Egy alacsony kódú alkalmazásban most grafikusan össze lehetne állítani egy maszkot, amellyel ez a táblázat kezelhető. Ez azt jelenti, hogy új páncélosokat lehet bevinni, a táblázatot megjeleníteni stb.

Az Low-Code-ban lehetőség van egy olyan gomb létrehozására is, amelyet a felhasználó megnyom, amikor azt jelentik, hogy egy fegyverzetet elgázoltak. A gomb egy munkafolyamatot ír le, gyakran BPMN-szerű ábrázolásban. Ez magában foglal egy olyan műveletet, amely leírja, mi történik valójában. Valami így nézhet ki:

Eddig jó. Tegyük fel, hogy az alkalmazás kibővíti az autópályán hirtelen megjelent papagájokat. Ezek a papagájok felsorolhatók egy "Papagájok" táblázatban:

id	Mondat	Súly
1	"Jó nap!"	2
2	"Jó éjszakát"	1.5

És itt is meghatározható egy olyan művelet, amely leírja a papagáj elgázolását:

Eddig is nagyon jó. De mi van akkor, ha a páncélosokat és a papagájokat egy nézetben akarják összefogni? Két különböző táblázatban szerepelnek, ami ezt megnehezíti. Az "állat egy fegyver vagy papagáj" fogalom nem fejezhető ki közvetlenül relációs adatbázisokban. Különböző megoldásokat érdemes lenne kipróbálni,

egy nagy tábla az "Armadillos" és a "Papagájok" összes oszlopával, és egy másik oszlop, amely megadja, hogy milyen állatról van szó, vagy
egy táblázat két oszloppal, amelyek hivatkozásokat tartalmaznak a két meglévő táblára, amelyek közül egyszerre csak az egyik aktív.

A megoldás egy ideig még megvalósítható lenne, de gyorsan rendetlenséget eredményez, amely nem használható. Hogyan nézne ki, ha lenne közvetlenebb módja ezeknek az autópálya-állatoknak a modellezésére? A Haskell funkcionális nyelvű megfogalmazás így néz ki:

A függőleges sáv | jelentése: "vagy". Ennek megfelelően azt mondja: Az állat vagy

Armadillo armadillo, Bool típusú armadilloAlive tulajdonsággal és Float vagy ArmadilloWeight tulajdonsággal
egy papagáj, mind a készlet, mind a súly jellemzőivel

Az állatpopuláció rögzítésére felsorolás hozható létre:

Tehát nem probléma az állatok mindkét osztályának keverése. Ez természetesen objektum-orientált programozásban is lehetséges, de ehhez interfészre és két, viszonylag összetett programozási osztályra lenne szükség. A Haskell megoldás előnyei tehát, hogy kevesebb kóddal kezelhető, és a kód közvetlenül a modellezésen alapul.

A műveletek nagyon kevés kóddal is meghatározhatók. Például elgázolják. A Haskell-definíció két egyenletből áll - osztályonként egy:

Ami a kód mennyiségét illeti, a funkcionális programozás még mindig előnyben van az alacsony kóddal szemben. Sokkal fontosabb azonban, hogy a funkcionális kód továbbfejleszthető legyen a követelmények növekedésével, miközben az alacsony kódú környezet eléri a határait.

A modern alacsony kódú környezetek egyfajta "Enterprise Cloud 4GLs"

A modern alacsony kódú környezetek kétségtelenül sok „szokásos feladatot” egyszerűsítenek a programozásban, különösen az adatbázissal és a grafikus felhasználói felületek tervezésével kapcsolatban: elég mindent összepattintani. Tehát bizonyos mértékig az "Enterprise Cloud 4GLs" kiküszöböli az Excel és az Access működési méretezési problémáit. Szinte meg lehet lepődni azon, hogy a „hagyományos” programozási technológiák nem kínálnak semmi hasonlót.

De csaknem: Minden tekintélyes objektum-orientált programozási nyelvhez léteznek „ORM-ek”, azaz Object-Relational Mappers, amelyek számos feladatot automatizálnak, amikor a tartományi objektumokat leképezik az adatbázisra. Az ORM-ekhez hasonlóan ezt a kényelmet is a kialakulóban lévő architektúra első kapcsolatának árán vásárolják meg: az adatbázis-modell elválaszthatatlanul kapcsolódik az adatmodellhez, mindkettőnek együtt kell fejlődnie, és ezért örökölniük kell egymás furcsaságait. Ez sokféle problémához vezet, amikor a kód növekszik: az említett modellezési gyengeségek, a kontrollálatlan gyorsítótár-viselkedés, a nehéz hibakeresés és a változtatások során nagy erőfeszítés. Ennek megfelelően az ORM-ek a kezdeti eufória után is kiesnek a divatból.

Hasonló a felhasználói felületekkel. Szorosan kapcsolódnak az alacsony kódú környezetek adatmodelljeihez (mint a múltbeli nagy felhasználói felület-készítő készleteknél - Visual Basic 6 és Delphi).

Korlátozott méretezhetőség: Milyen kiút van a dilemmából?

Az alacsony kódú környezetek lehetővé teszik az egyszerű alkalmazások „gyors prototípus-készítését”, de nem nőnek a követelményekkel együtt. A Java és a C # jobban skálázható, de a magas költségek és a nagy körülmények elárasztják a költségvetést és mindenekelőtt a fejlesztő lelkét. A funkcionális nyelvek viszont kezdetben kevesebb kódot, úgymond "alacsonyabb kódot" állítanak elő. Nem automatizál mindent, de a felhasználói felület programozásának és adatbázisainak kiváló támogatása kompakt megoldásokhoz vezet a rettegett építészeti összekapcsolás nélkül.

Sokkal fontosabb azonban, hogy mi legyen a szívünkhöz: Támogatás olyan magas szintű modellekhez, amelyek pontosan feltérképezik a szakterületeket és rugalmasan növekednek velük. Ami a modellezést illeti, új világok nyílnak meg a funkcionális programozásban - az absztrakció egységes és a matematika alkalmazásán keresztül. Úgy hangozhat, mintha a funkcionális programozás magasan képzett szakemberek számára lenne fenntartva. Valójában ez a legsikeresebb megközelítés a programozási képzésben, ezért minden programozási szakember megtanulhatja.