Mikor érdemes a kód újraírásán, refaktorálásán elgondolkodnunk?

Eljöhet az a pillanat, mikor annyira keszekusza lesz az általunk megírt kódbázis, hogy azt mondjuk magunkban: ez nem mehet így tovább, tennünk kell valamit.

Sok esetben, mikor programozni kezdünk, eszünkbe jut, hogy a kódunk talán nem a legigényesebb, nem kifejezetten átlátható. Vagy, amit készítettünk, abban vannak szinte ugyanolyan feladatot betöltő függvények, vagy akár egy adott „érték” több változó alatt lett bevezetve, és arra gondolunk, hogy nem csupán azok számára fog nehézséget jelenteni a logikai struktúra megtalálása a munkánkban, akik átveszik majd azt, hanem még számunkra is.

Ilyen esetben felmerülhet bennünk, hogy a kódot refaktorálni kellene, valamilyen módon újra írni. Ehhez természetesen mérlegelnünk kell, hogy ez mennyire lenne nehéz feladat, van-e olyan komplexitású a projekt, hogy megérje erre plusz időt szánni, és hogy a határidő mennyire engedné mindezt számunkra.

Annak érdekében, hogy picit jobban átlássuk a témát,  érdemes lehet ennek az okait, előnyeit, hátrányait összeszednünk.

Miért fontos a kód „tisztasága”?

Mikor programozói munkát keres az ember, sok alkalommal találkozik azzal az igénnyel a munkáltatók részéről, hogy megfelelő igényességgel, és átláthatósággal legyen valaki képes dolgozni.

Ennek egész egyszerűen az az oka, hogy sok esetben a fejlesztők együtt dolgoznak nagyobb méretű projekteken, és ha valaki működő kódot ír, de az nem átlátható, akkor több időbe fog telni a csapat többi tagjának értelmezni a munkánkat, mint azt nekik elkészíteni. Anno, volt, hogy amiatt nem vettek fel egy helyre, mert azt mondták, hogy „ismered a technológiákat, de nem elég átlátható a munkád”.

Rengeteg helyen alapvetően nem folyik „technikailag” magas szintű munka: ismert keretrendszerekkel készítenek akár komplexebb webáruházakat is, annak logikai felépítése pedig nem olyan nehézségű, hogy egy erős matematika érettségivel ne lehetne megérteni.

Manapság talán a technikai tudásnál is fontosabb a modularitás, átláthatóság, és a minőség. Illetve: a munka nagy részét az új igényeknek való megfelelés, kód tisztán tartása teszi ki: a refaktorálás.

Mikor lehet szükségünk refaktorálásra?

Ha tudjuk, hogy mit jelent a tiszta, és rendezett kód, akkor mindig lesz mihez viszonyítanunk magunkban, és az ezektől való eltérések fogják megadni számunkra a refaktorálás célját. Igénytelennek minősül a kód, vagy érdemes refaktorálni, amennyiben

• Inkonzisztens egy függvény, változó, konstans elnevezése: a fejlesztés során más funkciót kezdett betölteni, és a neve már nem pontos.
• Kód duplikáció fordul elő.
• Egy osztály, függvény túl nagyra nőtt, és szét kell bontani.
• Egy osztályban levő tulajdonságok, függvények az új igények miatt máshol is kellenének.
• Egy függvény új igényei miatt annak argumentumlistáját át kell alakítani.
• Egy osztályban nem megfelelőek a láthatóságok.
• Van a kódunknak olyan része, ami igazából „haszontalan”, nincs szükség egy külön változóra, függvényre, osztályra.
• A fájlok struktúrája számít rendezetlennek, az új igények miatt.
• Natív nyelvek helyett keretrendszert akarunk használni, mert hosszútávon átláthatóbb. Például, JavaScript helyett Vue.js-t.

Ezek a fent felsorolt elemek inkább az általunk írt kódban lehetséges hibákat jelzik, és jelentik, habár a teljes lista csupán kicsi részét képezik. Sok esetben a refaktorálási igény nem ezekből származik, hanem abból, hogy egy rendszert nem a megfelelő architektúrában kezdtek el fejleszteni, például, jobb lett volna egyedi fejlesztésű keretrendszert használni. 

Mikor érdemes a refaktoráláson ténylegesen elgondolkodnunk?

Abban az esetben, ha már eszükbe jutott a munkánk újra írásának gondolata, akkor érdemes egy meetinget tartanunk ezzel kapcsolatban. Ha már felmerült bennünk egy komolyabb refaktoringra való igény, akkor annak biztosan lehetnek okai. És ha valóban lenne rá, akkor még a továbbfejlesztés előtt kellene erről döntenünk, hogy megtegyük-e.

Ez természetesen nem jelenti azt, hogy mindenképp szükség lenne az újraírásra, de ha szeretnénk, vagy nagyon reális esély van a későbbi szükségessége, akkor most tegyük meg, amit kell.

Mennyi pénzbe, időbe kerülhet egy refaktorálás?

Itt érdemes leszögezni, hogy a komplexebb, több időt igénybe vevő refaktorálásokról van szó. Egy jó fejlesztő „napi rutinjához” tartozik az, hogy az éppen most, vagy az utóbbi pár óra során létrehozott osztályokat újraírja, és átnevezi, és ezek sok esetben nem is igazán „lassítják” a munkát. Hiszen, csupán pár helyen kell valamit átírni egy döntés meghozatalakor, és ezek ott vannak a fejünkben.

Komplexebb, sok éve fejlesztett rendszerek esetén akár sokmilliós nagyságrendre is rúghat egy rendszer refaktorálása, és ez még akkor is igaz, ha funkcionális tesztekkel minden pillanatban ellenőrizhető, hogy működnek-e azok az elemek, amikre szükségünk van. Gyakori probléma lehet, hogy valamit nem a megfelelő eszközökkel kezdtek el fejleszteni, tehát mondjuk rossz keretrendszert választottak egy komolyabb projekthez.

A refaktorálás egy pár órás munkától kezdve akár hónapokig is eltarthat. Éppen ezért, alapvető kérdés, hogy van-e rá költségkeret, hogy egy normálisabb refaktorálást kivitelezzen a fejlesztői csapat. Ha például, egy microsite-t készítünk el, ami összesen 10 óra munka, akkor nem feltétlenül érdemes plusz 2 órát eltölteni a munkával, azzal, hogy a HTML elemeket a legprecízebb behúzással illessük, mindent dokumentáljunk, és a többi.

Mi lehet nagyon nagy segítségünkre?

Még akár kicsi weboldalak esetén is sok bosszúságot okozhat számunkra az, hogy valamit, mondjuk egy változónevet megváltoztatunk valahol, és emiatt a kódunk bizonyos esetben nem fog működni, az ügyfél visszadobja a munkánkat, és nem érti, hogy ez vagy az miért nem működik az oldalon.

Emiatt komplexebb rendszerek esetén nagyon ajánlott lehet a funkcionális, és Unit Testing használata. Hosszú távon mindenképp megtérülő befektetés, ugyanis ezzel lehet folyamatosan ellenőrizni, hogy minden működik-e még.

Ezen felül, érdemes egy mindenre kiterjedő, részletes dokumentációt készíteni a projektünk minden moduljához. Milyen elemek vannak, milyen inputokat fogad el az adott modul, és milyen outputokat kell kiadnia adott esetben. Érdemes lehet egy rendszertervezőt is alkalmaznunk, ha erre lenne költségkeret, és igény.