4. rész – Programozás az AI korában
Most akkor fut vagy nem fut?
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.
Szoftver megírása
Ha kialakítottuk az írandó szoftver felépítését is, akkor jöhet az egyes részek megírása. Ha ügyesek voltunk, akkor itt már jól megfogható, egyszerű darabokat kell megírni, ami egy történet esetében olyasmi lenne, hogy „Mr. Big és Ms. Clever beszélgetése a könyvtárszobában, melyben Ms. Clever kiszedi Mr. Bigből, hogy Mr. Small hol rejtette el az arany könyvjelzőt”. Mikor ezt megírjuk, akkor hozzáteszünk egy fordulatos párbeszédet néhány fifikás kérdéssel, esetlegesen némi romantikával megfűszerezve, de a jelenet célja már megvan, ahogyan azt is kitaláltuk korábban, hogy ki és milyen Mr. Big és Ms. Clever, így az is világos, hogy lesz-e benne romantika, vagy Ms. Clever a hideg racionalitásával ér el eredményt, nem pedig a női bájaival.
Valahogy így van ez a szoftverfejlesztésben is. Mikor ide eljutunk, addigra megvannak már a részegységek, azok homályos vagy pontosabb feladata, a felhasznált egységek tulajdonságai, és csak arra vár, hogy megvalósítsuk, azaz elkészüljön a forráskód.
Ahogyan feltételezhetően az írók egy része is imád párbeszédeket írni, más része pedig inkább a történetvezetést szereti, úgy a programozás esetében is nagyon lehet szeretni azt, amikor az adott feladatra elkészül az azt megvalósító program, a forráskód, és igazából ez valahol a végeredménye a szoftverfejlesztésnek is (mint a párbeszédekkel együtt leírt irodalmi mű az írók esetében).
A szoftverfejlesztésben ez a lépés egy idő után veszt a varázsából, és bár egyesek (én is) szeretik, mások nem, mert azért ez mégiscsak „favágó” munka. Talán akkor kevésbé favágó munka ez a rész, ha hagyunk a történetszövésből is egy kis részt erre az utolsó fázisra, nem mindent rögzítünk le az utolsó gondolatig, mire ideérünk a folyamatban.
Jelenleg ez az a rész, amiben az AI-eszközök legtöbbet tudnak segíteni: megírni a kódot. Mire a folyamatban ide jutunk, addigra már nagyon sokat gondolkoztunk azon, milyen kérdéseket tegyünk fel az ügyfélnek, hogyan építsük fel a rendszer architektúráját, kifejtettük a részletesebb terveket, elhatároztuk, hogy az adott részegységek milyen feladatokat látnak el, igyekeztünk karbantartható módon kialakítani a struktúrát. Végül megírjuk a kódot. Amit vagy mi végzünk manuálisan, vagy AI-ra bízzuk. Előbbi esetben emberi tévedés, utóbbi esetben AI hallucináció miatt kaphatunk hibás programot. Mindenesetre nagyon érteni kell a programozáshoz, hogy ki tudjuk szúrni a problémákat, hibákat. Enélkül könnyen “bevihet az erdőbe” bármilyen AI segédeszköz.
Van még egy dolog, amit itt meg kell említeni: kódírás esetében sincs az, hogy eddig semmilyen segítségünk nem volt, mostantól meg egy AI megírja nekünk a kódot. 2008-ban indult el a stackoverflow.com, ami egy kérdés-válasz platform: fejlesztők felteszik a kérdéseiket ide, és néhány más fejlesztő megválaszolja, a témával találkozó többi fejlesztő pedig fel- vagy lepontozza a kérdést is és a választ is, ebből lehet utána következtetni a minőségre. Az évek során ez azt eredményezte, hogy létrejött egy nagyon jó minőségű tudásbázis a legkülönbözőbb szoftverfejlesztési témákban. Gyakorlatilag bármilyen programozással kapcsolatos (szabatosan megfogalmazott) kérdést tettél fel, szinte biztosan volt a Stackoverflow-n válasz rá. Vagy ha nem, akkor lett. A Google be is indexelte, ezeket a találatokat mindig érdemes volt megnézni. Sok esetben a válaszban még teljes példakódrészletek is voltak, amiket csak be kellett illeszteni a programba, és sokszor kész is volt az adott részlet. Az AI annyival tud többet a Stackoverflow-nál, hogy önállóan képes a programodhoz igazítani ezeket a példakódokat, ami sokszor pontosan illeszkedik (máskor meg nem, néha meg még le sem fordul).
Ha visszaemlékszel, 2008 és 2023 között nem azt olvashattuk a médiában, hogy “Most, hogy van Stackoverflow, mindenki képes programozni, hiszen csak be kell másolni a kódot a programba”, és azt sem, hogy “nem lesz többé szükség programozókra, mert a Stackoverflow-ról mindent össze lehet már ollózni”. Helyette mindenhonnan azt hallottuk, hogy még-még-még kell programozó, óriási a hiány, és ez önmagában visszafogja a világgazdaság fejlődését. Most meg ugyanaz a média azzal riogatja az embereket, hogy a “felokosított Stackoverflow” miatt nem lesz szükség programozókra, ennek a szakmának vége, meg hogy bárki, aki be tud kapcsolni egy airfryert, már programozóként meg tud alkotni komplex informatikai rendszereket.
(A média befolyását a közhangulatra, azonban ebben a témában sem szabad elhanyagolni. Manapság a tartalomgyártók is kettéváltak újságírókra, akik tisztelik a témát, a hírt az olvasót és igyekeznek felkészülten, tény alapon bemutatni egy-egy témát, valamit a médiamunkásokra, akik egész nap ontják magukból a szövegeket különösebb utánajárás, vagy szakmai ismeret nélkül, a cél pedig kizárólag a hangulatkeltés és a kattintások számának növelése.)
Folytassuk az utazásunkat a hibák kezelésével:
Tesztek
A program hibáinak kiszűrése és a helyességének ellenőrzése egy fontos cél a szoftverfejlesztés folyamán.
Minden programhoz vannak tesztek, csak legrosszabb esetben a program használója fogja a haját tépve „tesztelni” és jobb esetben jelezni a hibát, rosszabb esetben pedig otthagyni az adott céget (… khm… banki rendszerek… khm…)
A végfelhasználó általi tesztelésnél még mindig jobb, ha a fejlesztői csapat egy erre szakosodott (vagy kevésbé jó esetben összetrombitált) része végzi úgy, hogy végignézegeti, végigkattintgatja a programot. Ez a manuális tesztelés.
„Összetrombitált” esetben ez sajnos sokszor annyiból áll, hogy megnyitják az alkalmazást, kattintanak kettőt és ha minden jó, akkor jó, ha nem jó, akkor meg nem. Részletes, mélyreható tesztelés általában nem várható.
Ha jól csinálják a manuális tesztelést, akkor a szoftverhez vannak tesztforgatókönyvek, amik megmondják, hogy pontosan mi a teendő, amikor tesztelünk. Tehát kell tudni rendelni egy terméket a webshopban, amihez ide és oda kell kattintani… és a tesztforgatókönyv leírja a teljes elvárt folyamatot. Ezeket a tesztforgatókönyveket végig kell csinálgatni, ezek biztosítják azt, hogy minden tesztelés után minden részegység le legyen ellenőrizve. Ha viszont vannak tesztforgatókönyvek, akkor ez azt is jelenti, hogy valaki már foglalkozott vele, végiggondolta, hogy mit és hogy kell letesztelni, akik pedig végrehajtják, azok már lehetnek kevésbé hozzáértők. (V.ö. a nagy hamburgerláncokban sem a diákmunkás az értékesítőexpert, aki kitalálja a kérdést, hogy kéred-e nagyobb üccsivel és krumplival a hambit, vagy kérsz-e hozzá epershake-et, hanem kiírja nekik a kütyü). A tesztforgatókönyveket folyamatosan kell fejleszteni, ahogyan a program fejlődik, mert egy idő után már nem lesz érvényes.
Továbbá azt is érdemes látni, hogy ha már vannak tesztforgatókönyveink, akkor onnan már csak egy lépés az, hogy azokat a kevésbé hozzáértő végrehajtókat számítógépes megoldásra cseréljék. Sok esetben ezt meg is teszik, de azért teljesen így sem lehet kiváltani a manuális tesztelést, mert az ember mégiscsak ember, és észrevesz olyanokat is, amit egy tesztforgatókönyv nem tartalmaz, illetve ha kudarcot vall az automata, az ember képes megoldani a problémákat. Mindenesetre az ismétlődő munkák automatizálása és a kreatív munkák felé való eltolódás már ebben a lépésben is megfigyelhető.
Az automatizált tesztelés a tesztforgatókönyves manuális tesztelés számítógépes változata: megvan a tesztforgatókönyv, és annak végrehajtását egy számítógépes rendszerre/programra bízzuk. Már néhány éve léteznek olyan rendszerek, amiben többé vagy kevésbé angolul leírva a követelményeket a program elvégzi a többit.
A tesztek esetében fontos megemlíteni a tesztelés hatókörét: a program legkisebb önálló egységétől kezdve az alrendszereken át vonatkozhat a teszt a teljes rendszerre. Így beszélhetünk egységtesztről (legkisebb önálló egységre, „osztályra”), integrációs teszt (osztálynál nagyobb, teljes rendszernél kisebb, egy önálló alrendszer), vagy rendszerteszt (teljes rendszer). Az egységtesztet még jellemzően a programozó írja, a többit már nem feltétlenül, vannak erre specializált szakemberek (automata tesztelők).
A tesztelés itt bemutatott fejlődési folyamatában is tetten érhető az a trend, hogy egyre inkább számítógépes rendszerek veszik át az emberi feladatokat, az emberre az egyre inkább kreatív, tudást is igénylő munkarészek maradnak. Ez a folyamat nem a mesterséges intelligenciával kezdődött el, ez csak a következő lépést jelenti a meglévő, automatizációs folyamatban. A tesztelés története inkább azt mutatta, hogy az automatizáció lehetővé tette a nagyobb, komplexebb rendszerek építését, így ezen nagyobb rendszerekben arányaiban kevesebb, de összességében nem feltétlenül kevesebb manuális tesztelőre van szükség – és emellett sok olyan szakemberre is támaszkodni kell, akik a tesztelésen kívül a programozásban is jártasabbak.
Korábban már írtam az automatikus tesztekről, megemlítve, hogy ha vannak ilyenjeink, akkor magabiztosabban tudjuk módosítani a programunkat, mert ha a program egy részén és a tesztjein fejlesztünk, attól a program többi részét ellenőrző tesztek kiszúrják a menet közben behozott hibát.
A tesztelés esetében érdemes még két fogalmat tisztázni: lehet egy program azért rossz, mert a leírt követelményeknek nem felel meg („olyan 5 üléses személyautót szeretnék, ami 180 km/h-val képes menni”, és az autó nem képes, csak 170-nel menni, akkor az egy egyértelmű hiba). A követelményeknek való megfeleltetés folyamatát verifikációnak hívjuk. Ez az egyszerűbb része, mert látjuk, hogy mi van leírva, és egyszerűbben eldönthető, hogy megfelelő-e a rendszer vagy sem.
A rosszabb eset az, amikor a rendszer megfelel a leírtaknak (tényleg megy 180-nal a személyautó), de az ügyfél nem ezt akarta (hanem hajót – vagy még rosszabb esetben kapott egy fehér, kombi, 180-nal menő személyautót, de ő kék szedánra gondolt). Az ügyfél igényeinek való megfeleltetés folyamatát hívjuk validációnak. Az ügyfél igényeinek feltárása és az annak való megfeleltetés területén tapasztalataim szerint jelenleg is rengeteg a kihívás, és várakozásaim szerint ez a jövőben sem lesz másképp: az informatikai megoldások évről évre egyre komplexebbek és bonyolultabbak, amit a megrendelői oldal nem feltétlenül tud követni.
Valamint érdemes még megemlékezni a gumikacsa módszerről is.
Ez a szoftverfejlesztés bármelyik pontján használható, a tervezéstől a hibakeresésig. De, hogy mi is a lényeg: tapasztalsz egy jelenséget/problémát és megoldást keresel rá. Nem megy a dolog, hiába facsarod az agyadat. Ilyenkor érkezett el a gumikacsa ideje: fogod a kacsát, kiteszed magad elé, és hangosan elmagyarázod neki, hogy mi is a probléma, mintha egy gyereknek/laikusnak magyaráznád. Hogy ez mire jó? Amikor megpróbálod elmagyarázni a problémát, akkor még egyszer az elejétől nekifutsz, eközben más struktúrába helyezed, kicsit eltávolítod magadtól, így lehet, hogy olyan dolgokat is észreveszel, amikre korábban nem gondoltál. Nézőpontot váltasz. (Persze nem kell feltétlenül konkrétan gumikacsának lenni, lehet az a macskád, a fikuszod vagy a lego Batmaned az asztalon, én néha a feleségem türelmét is igénybe szoktam venni erre a célra. A lényeg, hogy az alapoktól újra felépíted a gondolatmenetet, és eközben más szemszögből gondolod végig a dolgokat.)
A mi képzési rendszerünkben nemcsak a gumikacsa módszer használatát támogatjuk, de az automata tesztelésről is részletesen szó van, így akár ha erről a témáról szeretnél többet megtudni, érdemes megkeresni bennünket.
(Képek forrása: freepik, StudiCore, BingAI)
Kipróbálnád a programozást? Kipróbálnád magad?
Töltsd ki a tesztünket!
