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.

Humli Miklós

Szerző Humli Miklós

Régóta dolgozom együtt kis-, közép- és nagyvállalalatokkal az arculattól a nyomtatott anyagokon keresztül az online megjelenésig. Az elmúlt évtizedekben UI, UX designerként, webfejlesztőként és mobil fejlesztőként használt keretrendszerek, szoftverek és technológiák alkalmazása során értettem meg, hogy hatékonyan működni csakis úgy lehet, hogyha megtalájuk a feladathoz a legmegfelelőbb eszközt.

További bejegyzések: Humli Miklós