AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.
Az elmúlt években elég sokat foglalkoztam a kódminőséggel. Nem mondanám, hogy a Clean Code minden egyes szabályát betéve tudtam és alkalmaztam, és nyilván én is követtem el bőven olyan kódolási bűnöket, amiket ma már máshogy csinálnék. De mindig is fontos volt számomra, hogy amit kiadok a kezemből, az ne csak működjön, hanem lehetőleg jó is legyen.
Használtam SonarQube-ot, CodeScene-t, foglalkoztam code smell-ekkel, tartottam erről előadásokat a cégnél, és elég sok vitát lefolytattam már arról, hogy egy-egy megoldás hosszú távon mennyire lesz karbantartható. Magyarul a „jó kód” kérdése soha nem volt számomra valami távoli, akadémiai probléma. Évekig a mindennapi fejlesztői munkám része volt.
Az utóbbi időben van bennem egy furcsa érzés, leginkább azóta, hogy egyre többet dolgozom AI kódoló eszközökkel; egyre kevésbé érzem azt, hogy a kódminőség ugyanúgy központi kérdés lenne, mint korábban. Nem azért, mert szerintem már nem számít. Hanem azért, mert elkezdtem azon gondolkodni, hogy egyáltalán ugyanazt jelenti-e még a jó kód fogalma, ha a kódot már nem feltétlenül mi írjuk.
Kinek írjuk a kódot?
Korábban erre elég egyszerű volt a válasz: embereknek. A gépnek persze végre kellett hajtania, de amikor megírtam egy osztályt, egy függvényt vagy egy egész modult, pontosan tudtam, hogy valamikor később valaki bele fog nyúlni. Lehet, hogy én. Lehet, hogy egy kollégám. Lehet, hogy egy teljesen másik fejlesztő, aki két év múlva csatlakozik a projekthez, és fogalma sem lesz arról, hogy az előző fejlesztő miért döntött úgy, ahogy.
Ezért számított, hogy legyenek értelmes neveink. Ezért próbáltuk kerülni a fölösleges komplexitást. Ezért volt fontos a megfelelő absztrakció, a modularitás, a tesztelhetőség, a code review vagy akár egy olyan eszköz, mint a SonarQube. A jó kód egyik legfontosabb tulajdonsága ugyanis az volt, hogy egy másik embernek ne kelljen minden alkalommal régészetet végeznie, amikor módosítani akar rajta.
Csakhogy most megjelent egy új szereplő, az AI, és eddig alapvetőnek gondolt tézisek kérdőjeleződnek meg bennünk.
Az AI ugyanis nem úgy olvassa a kódot, ahogy mi. Nem kell megjegyeznie, hogy egy adott függvény neve mit jelentett három hónappal ezelőtt, és nem fogja zavarni, ha egy osztályba még bekerült háromszáz sor, amit valójában külön modulokba kellett volna szervezni. Ha megkapja a megfelelő kontextust, meglepően jól elboldogul olyan kóddal is, amire egy ember fejlesztő valószínűleg csak sóhajtana egy nagyot.
Ráadásul az AI számára a módosítás költsége is egészen más. Ha én egy rosszul megtervezett modullal találkozom, akkor nagyon gyorsan elkezdem mérlegelni, hogy hozzányúljak-e egyáltalán. Tudom, hogy lehet belőle fél napos vagy akár több napos refaktorálás, közben pedig könnyen kiderülhet, hogy öt másik helyen is függnek a jelenlegi működésétől. Az AI viszont sokkal könnyebben mondja azt, hogy rendben, akkor ezt alakítsuk át. Ha elrontja, visszacsináljuk. Ha nem tetszik, generálunk egy másik megoldást.
És talán pont itt kezd el megváltozni az egész gondolkodás a kódminőségről.
Ha a kód előállítása és módosítása ennyire olcsóvá válik, akkor nem biztos, hogy ugyanazt a kódot kell ugyanúgy kezelnünk, mint korábban. Egy prototípusnál vagy egy olyan funkciónál, amiről még azt sem tudjuk, hogy egyáltalán szükségünk van-e rá, sokkal kevésbé érzem problémának, ha a megoldás nem tökéletes. Lehet, hogy egy hét múlva kidobjuk az egészet.
Más a helyzet akkor, amikor kiderül, hogy működik, használják, és velünk marad.
Ilyenkor már én is sokkal szívesebben visszamennék, és rendbe tenném azt, amit az első körben csak gyorsan összeraktunk. Nem azért, mert közben hirtelen újra fontos lett a Clean Code minden egyes szabálya, hanem azért, mert most már van értelme hosszú távra tervezni.
Talán ezért nem is az a jó kérdés, hogy kell-e még jó kódot írni. Inkább az, hogy
Mikor érdemes jó kódot írni?
Korábban megpróbáltuk már az első alkalommal jól megírni a kódot, mert tudtuk, hogy később drága lesz hozzányúlni. Most viszont egyre több esetben megengedhetjük magunknak, hogy először csak kiderítsük, egyáltalán érdemes-e megírni.
Ez persze nem jelenti azt, hogy a technikai adósság hirtelen nem számít. Inkább azt, hogy talán jobban meg kell tanulnunk különbséget tenni a valódi technikai adósság és az egyszerűen eldobható kód között.
Viszont van itt még egy érdekes csavar. Attól, hogy az AI nem úgy olvassa a kódot, mint egy ember, a jó struktúra neki sem mindegy. Sőt, bizonyos szempontból még fontosabbá is válhat.
Ha egy funkció szépen el van választva a rendszer többi részétől, egyértelműek a felelősségi körök, értelmesek a fájl- és függvénynevek, és nem kell egy fél alkalmazást végigböngészni ahhoz, hogy megértsük, hol történik valami, akkor az AI-nak is sokkal kevesebb kontextust kell összeszednie egy módosításhoz. Nem kell tíz külön helyről összeszednie az információt ahhoz, hogy megértse, mit kell megváltoztatnia.
Ennek pedig már nagyon is kézzelfogható ára van. Minél több felesleges kódot és összefüggést kell az AI-nak megértenie, annál több kontextust kell feldolgoznia, és annál könnyebben el is veszik a lényeg a sok egyéb információ között. Egy jól strukturált kódbázis tehát nemcsak egy ember számára könnyebben karbantartható, hanem az AI számára is hatékonyabban feldolgozható.
Így végül mégsem jutunk el oda, hogy a kódminőség teljesen elveszíti a jelentőségét. Inkább az történik, hogy bizonyos okokból kevésbé, más okokból viszont még fontosabbá válik.
A kérdés talán már nem az, hogy minden egyes sort tökéletesen kell-e megírnunk, hanem az, hogy olyan rendszert építünk-e, amelyben később egy ember vagy egy AI is könnyen megtalálja, megérti és biztonságosan tudja módosítani azt, amire éppen szükség van.
És valahol számomra pont ez az érdekes az egészben. Az AI miatt nem lett kevésbé fontos, hogy mit építünk és hogyan építjük meg. Viszont egyre kevésbé biztos, hogy ugyanazért kell jó kódot írni, amiért tíz vagy tizenöt évvel ezelőtt.
Régen elsősorban azért próbáltunk jó kódot írni, mert tudtuk, hogy később egy másik embernek kell majd együtt élnie vele. Most már az is lehet, hogy annak a másik „embernek” egy része egy AI lesz.
AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.