Refaktorálás, mit, mikor?
A szinte mindig szoros fejlesztési időket tekintve jogosan merül fel a kérdés, hogy a kód refaktorálása nem igényel-e plusz erőforrásokat, és nem veszélyezteti-e a projekt határidejét?
Azt gondolom, hogy rutinos fejlesztők esetében a refaktorálás nem okozhatja a fejlesztés idejének átlépését, vagyis a fejlesztés maga nem fog többe kerülni miatta.
Ugyanakkor a refactoring szemléletének, és módszereinek elsajátítása időbe telik, és gyakorlást igényel. Rutint szerezni viszont jobbára csak éles fejlesztés során tudunk.
Ha gyakorlott, refaktorálásban jártas fejlesztőkkel dolgozunk együtt, akkor az elkészült kódbázisra épülő további fejlesztések költségének csökkenése várható.
Ez mind a kód minőségének javulásában, mind pedig a hibák számának csökkenésében jelentkezik.
Ha jó a kódunk, kevesebb tesztelésre van szükség, kevesebb feladat hárul a projektet vezetőre.
Mivel így kevesebb erőforrásra van szükség egy adott projekt megvalósításához, összességében hatékonyabb működés valósítható meg.
A "felszabaduló" időben egyéb (belső) projektek is megvalósíthatóak.
Ráadásul a csökkenő költségek piacképesebb árakat is magukkal hoznak.
Új kód, régi kód
Az új fejlesztések során keletkező kódbázisnál nem kérdés: refaktorálni kell.
Régi kódra épülő fejlesztések során azt szoktam javasolni, hogy csak az érintett, régi kódbázist, és természetesen az újat refaktoráljuk.
Ne akarjuk a teljes forrást refaktorálni, mert maga a folyamat is sokáig tarthat, ráadásul a teljes alkalmazást így újra le kellene tesztelni, ami biztos nem fér bele a fejlesztési költségbe.
Régi kód esetén javaslom, hogy a refaktorálást könnyen tesztelhető, egyszerű funkcióknál kezdjük.
(Ha egy módosított kód tesztelése nehézkes - pl. más rendszerektől való függése miatt -, akkor a teljes átalakítás is sokkal több időt vesz igénybe.)
Régi, elavult kód refaktorálása
A folyamatos fejlesztésű rendszerekkel kapcsolatos refaktorálás mindenképpen behozza az árát, még ha hosszú időbe is telik a teljes rendszer átdolgozása.
Az egyes - relatíve kisebb - fejlesztéseknél biztosan nem tudjuk a teljes rendszert refaktorálni, de lépésenként, egy-egy részfunkció átdolgozásával végül az egész alkalmazást áttekinthetővé tehetünk.
Ha így járunk el, a következő fejlesztések már rugalmasabban, rövidebb idő alatt végezhetőek el.
Az idén május 21-22-én tartják Szeged talán legnagyobb tömegeket vonzó rendezvényét, a Szeged Napjához kapcsolódó Hídivásárt.