A low-code platformok megjelenésével valóban kezünkbe került a szoftverfejlesztés Szent Grálja? Beköszöntött az a világ, amelyben már fejlesztői ismeretek nélkül is lehet kódolni? Hogyan változtak meg az üzleti elemző, a szoftvertervező és a programozó szerepei a low-coding megjelenésének köszönhetően? Az alábbi cikkben a jelenség mélyére nézünk.

Mielőtt a kérdések megválaszolásába kezdenénk, vizsgáljuk meg, mit is takar pontosan a „low-code”! A tankönyvi definíciók azt sejtetik, hogy ezek a platformok hagyományos, formális kódolás nélkül, grafikus eszközök használatával teszik lehetővé az alkalmazásfejlesztést, és ebből fakadóan akár olyanok is részt tudnak venni a folyamatban, akik nem rendelkeznek hagyományos kódolói ismeretekkel. A továbbiakban a no-code fogalmat is beleértjük az itt használt low-code fogalmába.

Rögtön az elején zárjuk rövidre ezt a gondolatot: természetesen a definíció ebben a formában nem igaz. Szép lenne egy olyan világ, amelyben nincs szükség programozói, programtervezői, matematikai, logikai háttértudásra, és boldog-boldogtalan pár kattintással működő szoftvereket tudna létrehozni – de itt még nem tartunk.

‍

Ezzel szemben mi a valóság?

‍

Tömören annyi, hogy a formális programozási nyelv helyett – vagy mellett – meg kell tanulni egy formális modellezési nyelvet, amelynek segítségével magasabb absztrakciós szinten tudjuk megfogalmazni (specifikálni és implementálni) a feladatot. Nem saját kézzel, sorról sorra írjuk meg az alkalmazás kódjait, de pontosan értenünk kell, hogy a platform mit és hogyan csinál – így az ilyen rendszerek használata továbbra is szakértelmet kíván, csak egy kicsit más jellegűt. Óriási előny ugyanakkor, hogy ezekkel az eszközökkel sokkal gyorsabbá válik a munka, és lehetővé teszik, hogy a szakértő az alacsony szintű kódok megírása és tesztelése helyett a magasabb szintű, üzleti területhez közelebb álló tervezési feladatokra fordítsa az idejét. Nem véletlen, hogy a low-code platformok gyorsan népszerűvé váltak, és ma már bőven van miből válogatnunk, ha ilyen eszközt keresünk: a Mendix, az Outsystems, az Appian vagy a PowerApps mellett például használhatjuk a BlackBelt saját platformját, a JUDO-t is. Bár az eszközök száma folyamatosan nő, az igazat megvallva ezen a területen még van hova fejlődnie a világnak.

‍

Nézzük, hol tapasztaljuk majd a legtöbb változást!

‍

Mindezek után kézenfekvően adódik a kérdés, hogy egy ilyen fontos újítás hogyan alakítja át a fejlesztési folyamatokat? Egyrészt kis túlzással mondhatjuk, hogy ahogy a kerék feltalálása után sem maradt semmi a régiben, úgy a szoftverkészítés, alkalmazásfejlesztés világában is jelentős változások zajlanak napjainkban: egy olyan eszköz került a kezünkbe, amivel feljebb léphetünk egy absztrakciós szinttel, s így a specifikációk és az implementációk megfogalmazása/leírása egyszerűbbé, könnyebben érthetőbbé válik. Ennek köszönhetően kihagyható számos köztes lépés a fejlesztési folyamatokból, valamint megszűnnek az unalmas ismétlődő feladatok, és marad idő a produktív munkára. Másrészt azonban azt is látni kell, hogy a low-code nem maga a Szent Grál; nem old meg minden kihívást egy csapásra. A fejlesztők munkájának egy része megváltozik, más területek viszont továbbrais megkívánják majd az emberi munkaerőt. Csupán az arányok tolódnak el.

Ahogy korábban már említettük: a low-coding lehetővé teszi, hogy ne kelljen minden kódot megírnunk és minden tesztelést saját kezűleg elvégeznünk, hiszen ezek a feladatok vagy okafogyottá válnak, vagy a platform automatikusan elvégzi helyettünk. A jelenleg bevett fejlesztési folyamatokban – a projektmenedzsmentet és a tesztelést nem számítva – általában három jól elkülöníthető szerepkör létezik, amelyekhez más-más tudás és soft skillek szükségesek: az üzleti elemzőké, akik a megrendelőkkel kapcsolatot tartva kibontják, részletezik a fejlesztési igényeket; a szoftvertervezőké, akik a megoldandó feladatot részfeladatokra bontják, és specifikálják a rendszertervet; illetve a programozóké, akik a gyakorlatban elvégzik a kódolást.

Könnyű belátni, hogy ez a klasszikus felosztás az új technológiai megoldásoknak köszönhetően bizonyos mértékig szükségszerűen átalakul.

‍

Milyen súlypontváltozásokhoz vezet, ha elkezdünk használni egy low-code platformot?

‍

Először is, ahogy már rögzítettük: ezek a rendszerek nem alkalmasak minden igény kezelésére, vagyis az összetettebb, egyedi fejlesztést igénylő feladatoknál továbbra is szükség lesz mindhárom szerepkörre. Az egyszerűbb, „sorozatgyártható” fejlesztéseknél azonban sok minden változik. Ezekben az esetekben azt látjuk, hogy legtöbbször elég, ha a projektben csak a tervező vesz részt, hiszen a low-code keretrendszer segítségével gyakorlatilag készre tudja gyártani a megbízó által elvárt alkalmazást. Ha nem is jelenthetjük ki, hogy innentől minden kevésbé bonyolult projekthez összesen egy tervezőre lesz szükség, az mindenképpen helytálló, hogy a korábban 5-6 fős, üzleti elemzőből, architektből és több programozóból álló csapatok létszáma lecsökken 1-3 főre.

‍

Mit vár el egy low-code platformtól a szoftvertervező?

‍

Ha az előző bekezdés végén leírtakat elfogadjuk, akkor fel kell ismernünk, hogy a munkafolyamat kulcstényezője az lesz, hogy mennyire képes hatékonyan dolgozni a szoftvertervező az eszközként használt low-code platformmal. Ennek számos feltétele van.

• Ezek egyike például, hogy a keretrendszer által végeredményként legenerált alkalmazás minősége előre ismert legyen, és abban meg lehessen bízni. Néhány példa erre a teljesség igénye nélkül:

                 ◦ a biztonsági előírásoknak/protokolloknak mindig feleljen meg,

                 ◦  legyenek konzisztensek az alkalmazáson belüli képernyő elrendezések,

                 ◦ az adatbázis legyen mindig következetes.

• A következő, legalább ilyen fontos elvárás, hogy a fejlesztés alapjául szolgáló modellt ki lehessen terjeszteni, vagyis elég rugalmas legyen ahhoz, hogy egymástól eltérő projektekben is használható legyen; ki lehessen egészíteni egyedi elemekkel az eszközkészletet. Persze ilyen esetekben mindig szükség van programozói közreműködésre is, hogy az új fogalmak jelentését implementálják.
• Elengedhetetlen az is, hogy a tervező automatikusan ellenőrizni tudja a létrehozott modell konzisztenciáját; tehát a rendszernek alkalmasnak kell lennie a terv validálására.
• A rendszernek lehetővé kell tennie, hogy a szoftvertervező fel tudja használni a már meglévő ismereteit és eszközeit.
• A terv legyen maga a dokumentáció. Szükség esetén a tervből lehessen a különböző szereplőknek megfelelő dokumentumokat vagy nézeteket kigenerálni.
• Nélkülözhetetlen, hogy maga a low-code platform is folyamatosan fejlődjön.

Konklúzió

Láthatjuk, hogy a világ abba az irányba tart, hogy egyre elterjedtebbek lesznek a különböző low-code architektúrák, és ezzel összefüggésben nő a tervezők szerepe a fejlesztési folyamatban. Ez azonban nem jelenti azt, hogy gyökeres változásokra kéne készülni. Némileg leegyszerűsítve: kevesebb kis komplexitású feladat elvégzésére képes kódolóra, és több kis komplexitású feladat elvégzésére képes tervezőre lesz szükség, de közben bonyolult feladatok is mindig lesznek. A low-code platformok elterjedése tehát egy olyan hatékonyságnövelő újítás, melynek köszönhetően a fejlesztések menete nem változik meg lényegesen, csak a súlypontok tolódnak el; konkrétan a feladatok megfogalmazási módja emelkedik egy-két absztrakciós szinttel magasabbra. Ennek következtében az üzleti emberek számára könnyebben érthetővé válik a terv és maga az implementáció, és a fejlesztés sebessége is jelentősen felgyorsul.