Miért számít a tiszta és újrahasznosítható kód

Miért számít a tiszta és újrahasznosítható kód – egy tanóra és a Dalbe mindennapjainak tanulsága

Ma (2025. október 27-én), az objektumorientált programozás (OOP) Java-órán az egyik hallgató feltett egy egyszerűnek tűnő, mégis nagyon fontos kérdést:

„Hogyan tudom a kódom egy részét átemelni és felhasználni egy másik projektben?”

Elsőre banális kérdésnek hangzik, valójában viszont a programozás egyik legnagyobb kihívását érinti: a kód újrahasznosíthatóságát és a projektek logikus felépítését.

Az órán beszéltünk a JAR csomagokról, arról, hogyan lehet őket létrehozni, importálni és más projektekben használni anélkül, hogy ugyanazokat a függvényeket újra és újra meg kellene írni. Innen természetes módon jutottunk el a SOLID elvekhez, amelyek minden hosszú távon életképes kód alapját képezik.

Miért hozom ezt szóba itt? Azért, mert pontosan ugyanezekkel a problémákkal találkozunk nap mint nap a Dalbénál is, amikor meglévő projekteket veszünk át. Legyen szó egy mobilalkalmazásról vagy egy WordPress-oldalról, ugyanaz a különbség jön elő újra és újra: rendezett, átgondolt kód vs. kaotikus, összedobált megoldások.

Tiszta kód vs. összeollózott kód

A tiszta kód olyan, mint egy rendezett lakás. Tudod, hol van minden, logikus az elrendezés, és bárki beléphet, gyorsan átlátja, mi történik.

A kaotikus, mindenfelől összemásolt kód inkább egy raktárra hasonlít, ahová mindent csak bedobáltak. Lehet benne élni, de csak az igazodik el benne, aki összerakta. Ha másnak kell belépnie, az hamar elakad.

Dolgoztunk már olyan projekteken, ahol a kód korrekt volt, dokumentált, logikus kommentekkel ellátva. Ezeknél azonnal lehetett haladni, felesleges időveszteség nélkül. De láttunk olyat is, ahol minden össze volt másolva, funkciók évek óta nem működtek, és ugyanaz a kódrészlet öt külön fájlban szerepelt.

Ez nem újrahasznosítás. Ez káosz.

Ha nincsenek egyértelmű kommentek, előbb-utóbb eljutunk oda, hogy: „Mire gondolt a költő?” 

Kommentek és szabványok – nem opcionálisak

Egy jó kód sokszor önmagáért beszél, de a rövid, lényegre törő kommentek óriási különbséget jelentenek.

A kommenteknek nem azt kell elmagyarázniuk, mit csinál a kód, hanem azt, miért.

// Ellenőrzi, hogy a felhasználónak van-e admin jogosultsága – hasznos

// Ha ide eljutsz, elvesztél – nem az

Találkoztunk már olyan projekttel, ahol egy komment így szólt: „Ez a projekt egy káosz, soha nem fog működni.” Egy másikban cinikus üzenetek várták a következő fejlesztőt.

Lehet, hogy ez belső poénnak tűnik, de amikor az ügyfél fizet a kódért, ez már nem humor, hanem professzionalizmus hiánya.

Kódbeli komment egy átvett Shopify projektben

A Dalbénál úgy gondoljuk, hogy minden fejlesztő felelős azért a kódért, amit kiad a kezéből. Ha az ügyfél fizet, akkor olyan megoldást kell kapnia, amely karbantartható, frissíthető, és később más csapatnak is átadható.

Miért beszélünk erről ennyit a Dalbénál?

Azért, mert ez a mindennapi valóságunk. Folyamatosan veszünk át mások által elkezdett projekteket. Vannak köztük jól átgondolt, tiszta rendszerek. És vannak valódi labirintusok.

Ha a kód rendezett, dokumentált és szabványokat követ, az átvétel gördülékeny. Meg lehet érteni, elemezni és továbbfejleszteni.

Ha nem, minden nehézzé válik. Rossz struktúra, beszédes nevek hiánya, értelmetlenül másolt függvények, mert ilyenkor gyakran nincs más megoldás, mint a projekt egyes részeinek újraírása.

Ez senkinek sem jó. Az ügyfélnek drágább. Nekünk kiszámíthatatlanabb.

Ezért mondjuk mindig: jobb tiszta kódot írni az elején, mint később drágán javítani.

Technikai adósság amit előbb-utóbb meg kell fizetni

A technical debt (technikai adósság) fogalma pontosan ezt jelenti: gyors kompromisszumokat, amelyek később súlyos költségekké válnak.

Amikor egy projekt nem kap frissítéseket, a csomagok elavulnak, a figyelmeztetéseket figyelmen kívül hagyják, az adósság csak nő. Egy ponton olcsóbb újraírni mindent, mint javítgatni.

Ezt számtalanszor láttuk. Olyan rendszereket, ahol egy frissítés az egész projekt összeomlását jelentette volna. Vagy pluginokat, amelyeket a fejlesztőjük már rég elhagyott – az ügyfél tudta nélkül.

Ezért a rendszeres karbantartás nem extra, hanem alapkövetelmény.

ChatGPT és más AI eszközök

Sokan használnak ChatGPT-t kódírásra. Ez nem probléma. Mi is napi szinten használjuk.

De egy dolgot tisztán kell látni: a ChatGPT eszköz, nem gondolkodás helyettese.

Egy jó fejlesztő tudja, mit csinál minden egyes sora. Ha valaki csak másol anélkül, hogy értené, mit illeszt be, hibákat visz be és nem fogja tudni, miért.

Ez a különbség egy fejlesztő és egy „copy-paste user” között.

Az AI kiváló inspirációra, példákra, gyors ellenőrzésekre. De a végeredményt mindig érteni, ellenőrizni és testre szabni kell.

Megértés nélküli kódra építeni olyan, mint egy időzített bomba.

Saját tapasztalat

A Dalbénál nap mint nap ezzel foglalkozunk. Projekteket veszünk át, stabilizáljuk őket, karbantartunk, kódot tisztítunk, és amikor kell, újraírunk.

Így került hozzánk például a Bikeathon, amelyet több mint három éve fejlesztünk és üzemeltetünk. Jó példa arra, mit jelent a jól megírt kód: bővíthető, frissíthető, optimalizálható. Igen, ott is megjelenik már a technikai adósság, de kezelhető formában.

Ez a különbség, amit a fegyelem jelent a kódírásban.

Ha a projekted segítségre szorul

A Dalbénál segítünk a cégeknek visszaszerezni az irányítást a saját kódjuk felett. Ha a projekted nehezen karbantartható, lassú, vagy gyanús biztonsági és teljesítményproblémák vannak, egy őszinte, átlátható értékelést adunk.

Mini-audit időpontfoglalás itt.

A mini-audit ingyenes. Megmondjuk, hogy menthető-e a rendszer, vagy hosszú távon jobb újraírni.

A cél egyszerű: olyan kód, ami működik hosszú távon, kellemetlen meglepetések nélkül.