Amikor kész egy program vagy egy weboldal és a szoftver megfelelően működik, kiszolgálja az ügyfelek igényeit és a várt módon működik akkor minden rendben. De mi a helyzet a kóddal? Mi a helyzet a programozókkal akik a projekten dolgoztak? Ők mit gondolnak a szoftverről? A refaktor mikor szükséges és mikor nem?
A robosztus, átláthatatlan kódoknál az új fejlesztés nehézkes. Egy-egy kódrészletnél látszik, hogy kevesebb sorral is meg lehetne oldani a feladatot de a kódhoz hozzányúlni a sok egymástól függő részek miatt fájdalmasan nehéz lenne.
Kétféle programozói gondolkodás
Kétféle szélsőséges programozói gondolkodás létezik. Az egyik, hogy nem fontos a kód olvashatósága és azt a gondolkodást érdemes követni, hogy „ami működik ahhoz minek hozzányúlni”. A kód újraszervezése, olvashatóbbá tétele felesleges időpocsékolás, hisz ezzel újabb hibákat gyárthatunk. Az ilyen programozó eredményorientált, így tudja, hogy a kód bonyolult, nehezen olvasható de működik és ami működik az rendben van.
A másik programozói gondolkodás már már művészetként tekint a kódra és kényelmetlenül érzi magát a rosszul szervezett és nehezen olvasható kódrészekkel való munka során. Undorodik a csúnya kódtól és sokszor túlzásba is esik és mások jól struktúrált kódját is átírják, csak hogy a saját kódolási stílusukat kövessék. A működés nem is annyira érdekli, csak az, hogy szép kódot adjanak ki a kezük közül.
Mikor van szükség refaktor -ra és mikor érdemes az „ami működik ahhoz minek hozzányúlni” elvet követni?
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. A kisebb fejlesztéseknél biztosan nem tudod 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é teheted.
A szoftvered alapját képező core -t amiken aktívan dolgozol mindig érdemes javítani, refactor -álni a könnyebb kezelhetőség és átláthatóság miatt. A többi ami jól működik és hibátlan, érdemes figyelmen kívül hagyni. A core a szoftvered legfontosabb része, amin a legtöbbet fogsz dolgozni. Gyakrabban olvasod ezeket a kódrészeket, és sokkal több változtatásokat fogsz végrehajtani ezeken. Ha további funkciók hozzáadására vagy új funkciók bevezetésére van szükség, akkor azokat érdemes közvetlenül innen csatlakoztatni.
Pareto elv a kódolásban
Vilfredo Pareto olasz közgazdász alkotta meg 1906-ban a 80-20 -as szabályt ami a kódolásban is érvényes, miszerint a hibák 80% -t a kódod 20% -a okozza. Ezt érdemes mielőbb megtalálni és javítani.
Ahogy Martin Fowler elmondta Refactoring könyvében:
agy részét a kód írásával töltik. Valójában ez az idejük nagyon kis része. A programozók idejük nagy részét a kód olvasásával és a hiba keresésével töltik. Minden programozónak van olyan hibája, aminek egy vagy több napig tartott a keresése. A hiba kijavítása már gyors volt, de a megtalálása rémálom.
Martin Fowler
Minél több jól megírt kód van, annál könnyebb átlátni a kódot. Minél érthetőbb a kód, annál könnyebb vele a munka. Ha így járunk el, a következő fejlesztések már rugalmasabban, rövidebb idő alatt végezhetőek el.
