5. rész – Programozás az AI korában
Nagy pénz, nagy kód, kis pénz, kis kód
Az első részben megnéztük, hogyan indul a projekt, majd a második részben jobban is kibontottuk a témát. A harmadik részt itt olvashatod el, a negyedik írást a sorozatban pedig itt találod.
Telepítés
Ha megfelelőnek ítéljük a programunkat, akkor kiadhatjuk. Néhányan még biztosan emlékeztek azokra az időkre, amikor a programok még floppy-n, CD-n, később DVD-n érkeztek. Beraktuk az adathordozót a gépbe, telepítettük a szoftvert. Manapság ezt már inkább az internetről letöltött programokkal tesszük meg (pl. böngésző telepítése), de egyre kisebb volumenben.
Egyre nagyobb azon szoftverek aránya, amelyeket sosem kell a számítógépünkre feltelepíteni, mert mi már csak a szoftver kimenetének megjelenítését végezzük a saját gépünkön (online szoftverek, pl. webes levelezőprogramot – itt a „frontend” program automatikus letöltődése, böngészőben való futtatása a jellemző lépéssor).
Korábban a szoftverek elkészítése és kiadása két külön lépésre bomlott, hiszen az adathordozó (vagy később a letölthető telepítőcsomag) elkészítése egy éles vonal volt a fejlesztés folyamatában.
Manapság ez is felgyorsult, részben automatizált folyamattá vált, előfordulhat olyan is, hogy egy szoftverből naponta jelenik meg új verzió. Gondoljunk csak a telefonos alkalmazásaink és a böngészőprogramunkra: jellemzően a háttérben, automatikusan frissül. Ez nem történhetett volna meg abban a korban, amikor az új verziót CD-re kellett írni (pardon, legyártatni a korongot), és azon keresztül kiadni.
A fejlesztőcsapat oldaláról a folyamat jellemzően úgy néz ki, hogy a szoftverfejlesztéssel foglalkozó csapattagok a programkódot egy forráskódokat tároló ún. verziókövető rendszerbe töltik fel (ez jellemzően a GIT nevű szoftvert jelenti), majd a feltöltődést érzékeli egy automatikus rendszer, opcionálisan különböző vizsgálatokat, teszteket futtat az új verzión, majd ha mindent rendben talál, telepítésre összekészíti az új változatot, majd automatikusan, vagy emberi közbeavatkozásra (egy gomb megnyomása) telepíti is az új verziót.
A megemlítendő fogalmak: continuous testing (az új verziójú forráskód feltöltése után automatikusan ellenőrzések futnak), continuous integration/CI (olyan fejlesztési attitűd, amiben a fejlesztők a változtatásokat kisebb egységekben, gyakran integrálják a szoftver kiadott verziójába – ennek ellentéte az, amikor egy fejlesztő egy jó nagy alrendszeren hónapokat dolgozik, majd utána próbálják beépíteni), continuous delivery/CD (a fejlesztők által gyakran integrált változtatások (majdnem) automatikusan kerülnek tesztelésre, fordításra, telepítésre… az automatikusba egy gombnyomás sokszor belefér). A CI-t és a CD-t együtt szokták emlegetni, mert ezek egymás kiegészítései, így találkozhatsz a CI/CD rendszer elnevezéssel, ha egy a CI-t és a CD-t támogató rendszerről beszélnek.
A szoftverfejlesztő csapat oldaláról is megfigyelhető változás: korábban a fejlesztő, a tesztelő és a szoftvert telepítő és karbantartó kolléga („rendszergazda”) különböző szerepek voltak, különböző csapatban dolgoztak. A nem annyira régi ötlet az, hogy a különböző fázisokon dolgozó kollégákat hozzuk össze egy csapatba, ahol a fejlesztés (development) és az üzemeltetés (operations) egyidőben jelen van. Ezek lettek a DevOps csapatok. Illetve ha nézel álláshirdetéseket, akkor azokban is találkozhatsz a DevOps kifejezéssel, amikor olyan kollégákat keresnek, akik értenek a verziókezelőtől a futó szoftver üzemeltetéséig terjedő támogató szoftverrendszerekhez, és képesek a kapcsolódó munkafolyamatokat elvégezni.
A folyamat gyorsabbnak, automatizáltabbnak tűnik, de itt is egyre nagyobb a tere annak, hogy programozáshoz hasonló munkát kelljen végezni: ismerni kell a rendelkezésre álló eszközöket, analizálni kell a megoldandó feladatot, meg kell alkotni az eszközök segítségével a megoldást a problémára, majd a megoldást létre is kell hozni, aztán az esetlegesen megváltozó követelmények miatt kezdhetjük elölről. Ha régen egy rendszergazdának dolga volt, hogy a szervezet 100 gépén egyesével végighaladva frissítsen egy szoftvert manuálisan, addig a mai „devopsos” kollégának már inkább az a feladata, hogy olyan rendszert építsen, amiben a változtatások minél könnyebben, hatékonyabban végigfutnak, a változások könnyebben alkalmazhatók. Azaz itt is azt látjuk, amit korábban több ponton is észrevehettünk: az IT-világ az automatizáció irányába mozdul(t), és azt is láthatjuk, hogy nem lett ezáltal feltétlenül kevesebb a munka, inkább megváltozott. Ezen kívül ahogy a lehetőségek nőttek, úgy ezzel egyre több és többféle embert kell a folyamatban foglalkoztatni. Lehet, hogy a manuális szoftverkiadásnál kellett egy cégben 100 munkatárs, akik kétévente kihoztak egy új verziót egy szoftverből, úgy valószínűleg ugyanennyi munkatárs kell ma is, csak ők mondjuk kéthetente adnak ki egy újat, többféle szoftverből. Több szoftver és gyakoribb kiadás: ezek nemcsak lehetőségként jelennek meg a cég számára, hanem megteremtődik az ezzel kapcsolatos elvárás is. Az AI bejöhet itt is segítségként, de ez csak egy meglévő trend következő lépcsője, és a trend korábbi lépései nem mutatták azt, hogy üzemeltető/DevOps kollégából egyre kevesebbre lenne szükség.
Üzemeltetés
Sokszor első hallásra nem egyértelmű az ügyfelek számára, úgyhogy hadd említsem meg itt is: ha megrendel valaki egy szoftvert (legyen a már emlegetett webshop), akkor azzal az elkészülte után is foglalkozni kell. Pontosan úgy, ahogyan az analógiában található rendszerrel, az autóval is.
Az autó esetében kézenfekvőnek tartjuk, meg is szoktuk, hogy évente egy-két alkalommal meg kell látogassuk a szervizet, emellett biztosítást, adókat fizetünk, ablaktörlőlapátot cserélünk, ablakmosófolyadékot töltünk… üzemeltetjük, karbantartjuk az autónkat.
A szoftvertermékeknél már nem tűnik ennyire egyértelműnek ugyanez: pedig kell hozzá egy szerver, amin van egy operációs rendszer, amit frissítgetnünk kell. A domaint/szervert fizetnünk kell. Ha a szoftverünkben hiba van, akkor azzal is foglalkoznunk kell, hogy eljusson a fejlesztőkig, és ki legyen javítva. Továbbá – és ez szokott jellemzően kimaradni – fel kell állítanunk a cégünkben is egy részleget, aminek az a feladata, hogy az ügyfelek ügyes-bajos, szoftverrel kapcsolatos dolgaival foglalkozzon: “Nem megy ez, elromlott az”. Ilyenkor ki kell deríteni, hogy a mi szoftverhibánk vagy az ügyfél nem talált meg valamit. Azaz ügyfélszolgálatot kell biztosítanunk a rendszer mellé, illetve kell egy hozzáértő ember vagy team, aki pedig a szoftver és a kapcsolódó rendszerek karbantartását végzi.
… és újra
A fentieket lehetséges egy menetben végigjátszani, tehát elemezzük a programmal szemben támasztott követelményeket, felépítjük az architektúrát, meghatározzuk a szoftver belső felépítését, megírjuk a forráskódot, kiadjuk, teszteljük, üzemeltetjük, aztán egy idő után leállítjuk, és vége a teljes életciklusnak.
Ezt hívják vízesésmodellnek: ha a specifikáció kész, akkor azt kőbe véssük, oda visszatérni nem lehet, ugyanúgy, mintha egy vízesésen keresztül lezúdultunk volna egy alatta lévő tó szintjére.
A probléma ezzel az, hogy a specifikáció általában nem ennyire stabil: én legalábbis még soha életemben nem találkoztam sem olyannal, hogy egy specifikáció teljes és ellentmondásmentes lett volna, sem olyannal, hogy ne jöttek volna menet közben újabb igények a megrendelő részéről.
Ezért jellemzőbb ma az, hogy a korábbi fázisokat újra és újra előveszik, akár újabb és újabb iterációkat végeznek a szoftverfejlesztés során: a nagyvonalú kép után az egyes részletek specifikációját csak később dolgozzák ki, mielőtt a program kapcsolódó fázisához hozzáfognának. Ez könnyebbé teszi a „nagy” specifikáció előkerülő ellentmondásainak kezelését, javítását, illetve a megrendelő új ötleteinek beépítését. Hátránya, hogy ha nem vagyunk előrelátóak, akkor könnyen belefuthatunk olyan változtatásba, mint „szorozzátok meg kettővel az autó végsebességét, és akkor készen vagyunk”.
A lényeg az, hogy ha ide eljutottunk, akkor innen általában visszaugrunk a folyamat legelejére, és újabb kört futunk az újabb módosítási igényekkel.
Számolnunk kell azzal, hogy bármennyire is jól végezte a dolgát mindenki, előfordul, hogy menet közben jön rá valamire az ügyfél, vagy jut eszébe valami új, ami befolyásolja az egész folyamatot. Ez természetes, hiszen sokszor “evés közben jön meg az étvágy”. Mivel bármennyire szeretünk is elbújni a gép mögött sokan, azért ne felejtsük el, ha nem is közvetlenül, de emberekkel dolgozunk, az ő igényeiket elégíti ki a munkánk, így kell némi rugalmasság.
(Képek forrása: freepik, StudiCore, BingAI)
Olvasnál még tőlünk?
Iratkozz fel HÍRLEVELÜNKRE, így biztosan nem maradsz le a legújabb tartalmakról!
Kipróbálnád a programozást? Kipróbálnád magad?
Töltsd ki a tesztünket!
