Antifragiális programozás és miért nem veszi el az AI a m...
Amikor elmondom, hogy utálok hibákat keresni és éppen ezért úgy szervezem a programozási szokásaimat, hogy elkerüljem a hibakeresést, gyakran kapok visszajelzést: „Biztos nem használsz jó debug eszközt.” Nézzük röviden az...
Nézzük röviden az álláspontomat: szeretném, ha a szoftverem antifragiális lenne (ez a fogalom Nassim Taleb nevéhez fűződik). Minél tovább dolgozom egy kódon, annál könnyebbé kellene válnia a hibák javításának.
Minden egyes kódrészlet hozzáadását egyfajta terhelésként tekintek. Ha nem teszünk semmit, a kód fokozatosan romlik, egyre nehezebben karbantarthatóvá válik, és több hibával indul meg. Szerencsére ez elkerülhető.
Ez azonban nem természetes állapot. A legtöbb fejlesztő számára, akinek nincs mély szakértelme, a kód bővülésével a hibák javítása egyre nehezebb lesz: tüneteket kergetünk a kódrétegek között, hajszolunk heisenbugokat, amik eltűnnek a hibakeresőben, vagy egy hibát javítva épp egy újat hozunk létre. A több kód több problémát jelent. Ez a törékeny kód jelensége. Egy új funkció hozzáadása kockázatot jelenthet, hogy eltörjük a régi, látszólag független részeket.
Számomra az nem képesség, hogy a legtöbb kód, amire nap mint nap támaszkodunk, egy szűk réteg műhelyéből származik, akik pedig az antifragiális programozás mesterévé váltak.
Hogyan lehet ezt megváltoztatni? Hogyan biztosíthatjuk, hogy minél tovább dolgozunk egy kódon, annál egyszerűbbé váljon a hibajavítás?
Léteznek jól ismert technikák, és rengeteg teszt, valamint ellenőrzés hozzáadása kétségtelenül segít. Lehet antifragiális kódot írni tesztek vagy hibakeresési ellenőrzések nélkül is, de ilyenkor valami funkcionálisan hasonlóra lesz szükség.
Az olyan messzemenő szabályok – mint „kell nyelv X, eszköz Y vagy módszer Z használata” – többnyire értelmetlen próbálkozások. Linus Torvalds eszközeinek vagy írási stílusának lemásolása nem garantálja a sikert. Az antifragiális működés nem recept, hanem inkább egy kívánatos eredmény.
Az önvédő programozás maga nem vitatott – mégis, az 1980-as években nem volt igazán elterjedt, és ma sem alapértelmezett sokak számára.
Természetesen a teljes önvédő szemlélet nem mindig alkalmazható vagy megéri az árát.
Például, ha gyorsan összedobok egy weblapot, ahol több JavaScriptet használok, mint amennyit elolvasnék, egyszerűen a böngésző hibakeresőjével futtatom. Ez jól működik. Nem egy pacemaker vezérléséről van szó, és nem várom, hogy karácsonykor éjjel felkeljenek és javítsák.
Ha a programod 500 sor és évente körülbelül 20-szor fut, az antifragilitás hajszolása nem biztos, hogy megéri.
A nagy nyelvi modellek képesek önvédő kódot generálni, de ha soha nem írtál te magad védekező kódot, és az AI segítségét veszed igénybe fő programozási eszközként, akkor a szoftvered valószínűleg törékeny marad.
Gyorsan tudsz kódot hozzáadni, de minél többet, annál nagyobbak lesznek a problémák.
Ez itt a lényeg. Kódot írni sosem volt a nehéz rész – már 12 évesen is tudtam kódolni, és napjainkban számtalan 12 éves készít egyszerű játékokat vagy alkalmazásokat. Akárcsak egy tizenéves, aki kalapáccsal, szögekkel és fával kutyaházat épít. A célig eljutni mindig könnyű volt.
De a bonyolultság skálázása úgy, hogy ne omoljon össze minden – na, ez a nehéz feladat.