tifyty

pure Java, what else ?

Eddig és ne tovább avagy refaktor és alkoholizmus

Talán még gyerekkoromban láttam egy Columbo (főszerepben Peter Falk) filmet, amiben egy ír alkoholista (egyébként ő volt a gyilkos) rendszeresen karcolgatta a whiskey-s üveget a gyémánt gyűrűjével. Mielőtt este elkezdett inni, megkarcolta valahol, hogy addig fogja leinni az üveget, és nem tovább. Amikor már italos volt nem tudott volna megállni, de ha ott volt a kis bekarcolt vonal, akkor azért megállt.

Eddig és ne tovább

Ez jutott nemrég eszembe a refaktorálás során. Annak ellenére, hogy mindannyian tudjuk, hogy a refaktorálás és a redesign között a különbség a tíz perc, — minden ami ennél rövidebb az refaktor, ami hosszabb az redesign — mégis kísértést érzünk egy hiba kijavítása során, hogy nekiálljunk refaktorálni, és ha nem húzzuk meg előre a határt, hogy “eddig és ne tovább” akkor azt vesszük észre, hogy redesign lesz belőle.

Alapszabály, hogy a refaktoráláshoz mindenképpen szükséges előfeltétel a megfelelő lefedettségű unit teszt. Természetesen ha van elegendő unit teszt, akkor nem lesz annyi hiba. Tehát amikor support projekten vagy, és kapsz egy halom kódot, hogy javítsd a hibákat — mert bizony vannak — akkor jó az esélyed, hogy nem lesz hozzá elegendő (ha ugyan egyáltalán) unit teszt, és arra is jók az esélyeid, hogy az objektum orientáltság három programozási alapelvét (egységbezárás, öröklődés, többalakúság) messze megelőzi a programozás sokkal alapvetőbb és sokkal szélesebb körben ismert és elterjedt paradigmája a copy-pasta. (Érted a szóviccet: pasta, mert hogy spagetti kód.)

Ilyenkor nagyon nehéz megállni, hogy ne akarjál mindenképpen refaktorálni. Talán nem is lehet megállni. Talán nem is kell. Persze unit tesztet írni ilyenkor sem lehet, mert arra nincs idő, marad a manuálisan végzett funkcionális teszt. Szerencsére a dokumentáció olvasás sok időt nem visz el. (rotfl)

Na jó. Szóval belehekkelni a kódba nem szabad, mert akkor a kód minősége egyre rosszabb lesz, és ilyenkor jut el a projekt egy olyan fázisba, hogy az ismert hibák száma ugyan exponenciálisan csökken de a határérték nem a nulla. Ha pedig nem akarunk hackolni, akkor refaktorálni kell, és ilyenkor kell előre megállapítani, hogy mit fogunk refaktorálni, és mi az amihez nem nyúlunk. Mert ha ez nincs, akkor menthetetlenül kiisszuk az egész üveget, vagy ha az túl nagy, akkor addig iszunk, amíg el nem ájulunk, vagy a projekt menedzser ki nem veszi a kezünkből az üveget, és ránk nem szól, hogy most már valami revenue generating dolgot kellene csinálni. A debugging ugyanis nem bevétel generáló tevékenység. Tényleg nem. Ez ugyan egy Bill Gates-nek tulajdonított híres mondás, de van benne igazság: a hibajavítás és még inkább a refaktor direkt módon tényleg nem generál bevételt. A költségeket csökkenti, de azt sem egyszerűen. A jövőbeli költségeket csökkenti a jelenlegi költségek növelése árán. Ha a jelenlegi költségek FV-ja (future value) kisebb, mint a jövőbeni csökkenés és van is rá fedezet, és ezt a budget-et nem is tudjuk másra nagyobb eredménnyel befektetni, akkor hajrá. Ilyen egyszerű a közgazdaságtan elmélete. Aztán mondja meg valaki ezt konkrét esetben. Ez tehát nem járható út annak megállapítására, hogy mennyit refaktoráljunk egy hiba javítása során. Természetesen az elv az ez: nőjön a profit, ami a bevétel mínusz a kiadás, de ez nem alkalmas modell, amikor ott ülök az Eclipse előtt.

No de hát akkor mit lehet mondani? Mennyit refaktoráljak? Azt már tisztáztuk, hogy érdemes előre elhatározni, hogy mennyit fogok refaktorálni, de arról még nem beszéltünk, hogy az a gyémánt karc az üvegben egy centivel a jelenlegi szint alatt legyen, kettővel, vagy akár az üveg fenekén. Őszintén: nem tudom. Ha ilyesminek nekiállok függ attól, hogy mekkora az időnyomás. Mennyire gázos/gazos a kód. Milyen programom van este. Van-e más feladatom, amivel szívesebben foglalkozom. Tovább is enyém lesz-e a kód még hosszú évekig, én felelek-e majd érte, vagy valaki más? Sokáig fogják sokan használni az alkalmazást vagy csak kevesen, és nem a menedzsmentből 🙂

Minden kód amit leírok vállalható kell, hogy legyen. Ha új kódot írok akkor is, de ha hibát javítok, akkor is. Azt az elvet szoktam követni, hogy azt a részt, ami a javított kód képernyőnyi közelében van azt refaktorálom. Persze, ha egy rövid kis metódusról van szó, és mellé van hányva egy képernyőnyi távolságban két teljesen irrelated másik metódus, azért azokhoz nem nyúlok. Átírok egy feltételt az IF utasításban, és olyankor átírom a következő blokkot is, meg az else utáni részt is ha az nem volt vállalható.

Copy-pasta kódnál kiemelem, és készítek egy új metódust, osztályt stb, de csak a hiba javításánál hívom az új kódot, a többi helyen csak kap egy TODO kommentet. Ahogy a Perl mondja: it ain’t broke, don’t mend. Nincs rá idő.

Valahogy úgy érzem magam, mint egy lebombázott városban. Kevesen lakunk ott. Kijavítjuk a közműveket, és eltakarítjuk a romok egy részét ott ahol élünk. A többi marad rom. Nem tölthetjük azzal az időnket, hogy az egészet újra építjük. Élni kell.

és, hogy ezzel nem vagyok egyedül

Ezeket a cikkeket megjelenés előtt át szoktam küldeni néhány kollégának. Nem mindegyiket, de ezt például igen. Egyikük ezt írta vissza:

Én egyedül élek a romok alatt és vannak kitaposott ösvényeim….

10 responses to “Eddig és ne tovább avagy refaktor és alkoholizmus

  1. Botond december 12, 2012 11:57 de.

    A kódok javítása sokszor olyan, mint mikor egy süllyedő hajón még festik a korlátokat..

  2. kozka december 12, 2012 12:23 du.

    Alapszabaly, hogy a hullat 6 darabra kell vagni

  3. Gábor Garami (@hron84) december 12, 2012 4:05 du.

    “it aren’t broken, don’t mend”
    Yuyy, erre meg bennem is felhorgadt a grammar nazi, pedig en mar buktam meg angol allasinterjun.
    Szoval, az vagy it isn’t broken, vagy it ain’t broken. Az are ugyanis (az E/2 -t leszamitva) tobbes szamu letige. De az ain’t szerintem nem ez lesz, marad az isn’t.

  4. Gábor Garami (@hron84) december 12, 2012 4:10 du.

    Egyebkent nem tudom, mi a jo valasz. En fejlesztes kozben vagyok igy, amikor talalok egy bugot, akkor is, ha az epp nem az aktualisan fejlesztett feature-hez tartozik, kijavitom. Aztan szivok a commitnal.

  5. tamasrev december 13, 2012 10:10 du.

    Van az a könyv, hogy “working effectively with legacy code” http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Sokan ajánlották, ezért előbb-utóbb biztosan el fogom olvasni. Kiváncsi vagyok, hogy az mit mond majd ugyanerről.

  6. tvik december 14, 2012 3:58 du.

    Jóposzt. Elég vékony a határ a még kifizetődő refaktorolás és a kód értelmetlen buzulása között. Ráadásul elég nehéz mérni, hogy mennyire fog megtérülni a befektetett munka, azt viszont nagyon is könnyű mérni, hogy mennyi idő megy el vele. Valamennyi refaktor viszont kell, mert különben elburjánzik a spagetti. Érzésre is lehet csinálni, de azon is gondolkodtam, hogy Sonar-on nézek majd valami mérőszámot és ha abból azt látom hogy a kód overall minősége romlik, akkor többet allokálok refaktorra. Egyébként nálam ez általában a fejlesztési idő 20%-a.

  7. b3ha december 20, 2012 9:05 du.

    Én már annak is örülnék, ha a cégeknél külön időt allokálnának a folyamatos refaktorálásra. Mondjuk előbb az egység tesztek bevezetésével kéne kezdeni…

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: