A vizuális programozás egy olyan programozási nyelvtípus, amely lehetővé teszi az emberek számára, hogy a folyamatokat illusztráció segítségével írják le. Míg egy tipikus szövegalapú programozási nyelv arra készteti a programozót, hogy úgy gondolkodjon, mint egy számítógép, a vizuális programozási nyelv lehetővé teszi a programozó számára, hogy a folyamatot az ember számára értelmes kifejezésekkel írja le.
A vizuális programozás és a hagyományos programozás közötti szakadék nagysága a vizuális programozási eszköztől függ. Az egyik végletben az eszköz szinte teljesen megvédi a programozót az emberi gondolkodás és a memóriában biteket keverő számítógépek között tátongó szakadéktól.
Itt egy példa. Egy tennivalólista létrehozásához egy vizuális programozóeszközzel a programozó lerajzolja az alkalmazás menetét. Az így kapott folyamatábra leírja a képernyőket, a felhasználói interakciókat és azt, hogy mi történik az adatokkal az egyes fázisokban. Az eszköz ezt aztán szoftverré alakítja.
Fejlesztőként tudjuk, hogy a szövegalapú programozási nyelvek teljes mértékben a megvalósításra összpontosítanak: minden arról szól, hogy a számítógépnek pontosan milyen lépéseket kell megtennie ahhoz, hogy létrehozza azt az élményt, amit a felhasználónak nyújtani szeretnénk. Persze, a magasabb szintű nyelvek és a modern keretrendszerek kényelmes rövidítéseket adnak nekünk. De a fejlesztő feladata az, hogy az emberi igényeket a számítógép korlátozott képességeinek megfelelő folyamatokra fordítsa le.
A többi vizuális kódolási eszköz ugyanazokat a folyamatokat és paradigmákat követi, mint a szövegalapú programozás. Képzeljük el, hogy lerajzolunk egy osztályt és annak kapcsolatát a példányosított objektumokkal, ahelyett, hogy az egészet begépeljük egy szövegszerkesztőbe.
Az egész remekül hangzik! De, kérdezhetnéd, hol vannak a vizuális programozók? Miért írunk még mindig kézzel kódot? Ez azt jelenti, hogy a vizuális programozás rossz ötlet?
Mielőtt megválaszolnánk ezeket a kérdéseket, és belemerülnénk a vizuális programozás mai helyzetébe, meg kell értenünk, mi is valójában a vizuális programozás: honnan jött, hogyan fejlődött, és miért.
Fedezzük fel a vizuális fejlesztőeszközök következő generációját
A vizuális programozó szoftverek rövid története
Az 1990-es években a vizuális programozás – bár a történelem ezt mutatja – nem mondhatjuk, hogy a vizuális programozás a játékkészletekre, multimédiás eszközökre és adatbázisokra korlátozódott. A Rational Software (amelyet 2003-ban felvásárolt az IBM) már az 1980-as évek közepe óta készített egy nem felhasználói felületes Ada IDE-t. Emellett a szoftverfejlesztési folyamat meghatározásával is foglalkoztak. A Rational Unified Process és a kapcsolódó erőfeszítések végül az Unified Modelling Language (egységes modellezési nyelv) kifejlesztéséhez vezettek, amely lehetővé tette egy rendszer minden egyes részének dokumentálását anélkül, hogy egy sor kódot is meg kellett volna írni. Olyan volt, mint a vizuális programozás, de anélkül, hogy futtatható szoftvert hozna létre.
AzUML szabványosított és átfogó nyelvet biztosított az objektumorientált rendszerek leírására. Az UML-láz azonban néhány építészre is lecsapott. A Pragmatikus programozó című könyv társszerzője, Andy Hunt elmeséli egy olyan szoftverprojekt történetét, ahol egy építész két évet töltött UML-diagramok készítésével, mielőtt egy sor kódot is írtak volna.
Amikor az agilitás egyre nagyobb lendületet vett, úgy tűnt, hogy az UML lehetővé teszi a szoftverépítés régi módszereinek minden rossz tulajdonságát: a túl sok tervezést és a túl kevés megvalósítást. A végrehajtható UML kísérlet volt a hiányzó darab – a végrehajtható szoftver – hozzáadására. Több megvalósítás is felbukkant, de nem volt túl nagy hatással a világra, amely gyorsan a PHP, a Ruby on Rails és más dinamikus szkriptnyelvek felé fordult.
Érdekes módon a végrehajtható UML egyik formája, amely megmaradt, szintén a Rational Software-től származik. A Rational Rose egy olyan eszközkészlet, amellyel UML segítségével szoftvereket hozhatunk létre, és végrehajtható kódot generálhatunk egy célnyelven, például C++ vagy Java nyelven.
Back to the Future: A vizuális programozás mai helyzete
A történelem tanúsága alapján felmerülhet benned a kérdés: a vizuális programozás halott? A vizuális programozás szerelmesei azt fogják mondani, hogy messze nem halott. Kérdezd meg tőlük, hogy “mi az a vizuális programozás?”, és először egy homályos szakterület-specifikus eszközt fognak megnevezni. Aztán azt mondják, hogy ez az eszköz a bizonyíték arra, hogy a vizuális programozás él és virul. Eközben te kétségbeesetten keresgélni fogsz a Google-on. Ennek eredményeképpen nemcsak az általuk említett eszközről fogsz tanulni, hanem arról a rendkívül speciális világról is, amelyben az létezik.
Kétségtelen, hogy a vizuális programozásnak megvan a maga szerepe, legyen szó akár a szintetizátorok programozásáról, akár arról, hogy az UML-rajongóknak sikerélményt adjon. Az általános célú szoftverek esetében azonban a világ egyszerűen túl összetett ahhoz, hogy pusztán vizuálisan modellezzük. Amikor a “kódod” úgy néz ki, mint egy CPU áramköri diagram, talán itt az ideje újragondolni a vizuális programozás alkalmasságát a feladatra.
Hasonlóképpen, a vizuális programozási szoftvereket általában a készítő képzelete korlátozza oly módon, ami nem akadályozza az általános célú szöveges programozási nyelveket.
Mégis az olyan eszközök, mint a Visual Basic, a Delphi és leszármazottaik megmutatták nekünk, hogy a vizuális szoftverépítés rendkívül hatékony lehet; csakhogy van egy olyan pragmatikus kompromisszum, ahol néha a kézzel írt kód a helyes megoldás.
Szupersztárok vs. csapatok: A vizuális programozási nyelvek új élete?
A programozás első napjai nehezek voltak, az biztos. De egy ember megérthette és szakértője lehetett mindannak, ami a szoftver létrehozásához szükséges volt. Ha elég idős vagy, gondolj vissza az 1980-as évekbeli szoftvercímekre. Gyakori volt, hogy egyetlen programozó önálló márkává vált.
Sid Meier, Mitch Kapor és Jeff Minter úgy szereztek valamilyen szintű hírnevet, hogy egyedül vagy legfeljebb egy másik munkatárssal közismert alkalmazásokat vagy játékokat hoztak létre. Akkoriban a szoftver- és hardverfrissítési ciklusok évekig tartottak. Ma azzal viccelődünk, hogy minden nap van egy új JavaScript könyvtár. Mégis van némi igazság abban a gondolatban, hogy a modern szoftverfejlesztés olyan ütemben halad, amellyel sokan közülünk nem tudnak lépést tartani.
A szoftvereket ma már nagyrészt szakemberekből álló csapatok készítik. Míg a korai fejlesztők mindent maguk csináltak, egy modern szoftverfejlesztő csapatban lehet egy ember, akinek egyetlen feladata a CI-eszköz gondozása. A fejlesztők egész karrierjüket egy keretrendszerre vagy platformra összpontosítva töltik. Az iOS-fejlesztők iOS-fejlesztők, nem pedig mobilfejlesztők. Egy-két évtizedenként talán egyszer vagy kétszer egy webfejlesztő lecserélheti az általa preferált keretrendszert. Nagyon kevesen írnak kézzel assembly nyelvet hivatásszerűen.
Nem csak arról van szó, hogy a szoftverek köre megváltozott. Bizonyos mértékig maguk a fejlesztők is megváltoztak. A szoftverfejlesztő manapság már csak egy újabb karrier. Az elmúlt évtizedekben ez néhány ember szenvedélye volt, akiknek volt elég elhivatottságuk ahhoz, hogy megtanuljanak egy teljesen új rendszert, hogy megírhassák például a sikeres Amiga-játékuk Atari ST portját. De ez érthető: a számítástechnika ma már nem hiányszakma.
Most olyan világot élünk, ahol a szoftverfejlesztés egyre összetettebb részekből áll, és ahol a fejlesztők hétköznapi emberek, rendkívüli specializációval. Ez a komplexitás és specializáció rosszul illeszkedik az említett korai eszközök tiszta vizuális programozásához, de egyre nehezebbé teszi a kerek szoftverfejlesztő csapatok kialakítását is.
Ahol a tiszta vizuális programozási környezetek kudarcot vallottak, ott van a hasonló eszközök egész tárháza, amelyek a vizuális programozás legjobb tulajdonságait ötvözik a szövegalapú kódolással. Míg a vizuális programozás “no-code” volt, ezek az új eszközök low-code-ot jelentenek.
Az olyan eszközök, mint az OutSystems, lehetővé teszik a fejlesztők számára, hogy vizuálisan hozzák létre a szoftvert az interakciós folyamatok, a felhasználói felületek és az objektumok közötti kapcsolatok megrajzolásával, de kézzel írt kóddal kiegészítve, ahol ez a jobb megoldás.
A vizuális és a szövegalapú programozás e pragmatikus keveréke jól megfelel a modern szoftverfejlesztés igényeinek. Az alacsony kódú platformok csökkentik a szoftverfejlesztés bonyolultságát, és visszavezetnek bennünket egy olyan világba, ahol egyetlen fejlesztő is képes gazdag és összetett rendszereket létrehozni anélkül, hogy az összes mögöttes technológiát meg kellene tanulnia.
A vizuális programozás következő generációja: Az ígéret beváltása
A vizuális programozás oly sok ígéretet tartogatott, és a problémák, amelyeket meg akart oldani, nem tűntek el. Sőt, aktuálisabbak, mint valaha.
A valós problémák azonban nagyobb rugalmasságot igényelnek, mint amit a vizuális programozás nyújtani tudott. A Low-code ezt az ígéretet veszi alapul, és a modern szoftverfejlesztésben tapasztalható komplexitás csökkentésére alkalmazza. Tehát ne azt kérdezzük, hogy “mi az a vizuális programozás?”. Ehelyett inkább azt kérdezzük, hogy “mi a low-code?”. Online bemutatót is szervezhet, vagy akár ki is próbálhatja az OutSystems-t (ingyenes).