Persze, arra általában nincs idő, hogy újra megírjuk a szoftvert, tapasztalatom szerint pragmatikusan érdemes hozzáállni a folyamathoz. Én ezek mentén az elvek mentén próbálok dönteni/haladni:

1) Milyen változás hozná a legnagyobb hatást a szoftverben? (Elsősorban a delivery speed szempontjából, mert a refaktorálás ugyebár azt jelenti, hogy nem változtatom meg a szoftver megfigyelhető működését.)
2) Hogyan tudom ezt eladni/el tudom-e ezt adni a többi résztvevőnek? (Product ownernek/megrendelőnek, csapattársaimnak, managementnek stb.)
3) Hogyan tudom ezt lépésről lépésre végrehajtani? (Azon túl, hogy irtó kockázatos a bigbang típusú refaktorálás (napokig/hetekig túrom a kódot, aztán a végén kipottyan a refaktorált kód), nem is lehet azt könnyen eladni, hogy 1 hónapig csak reszelünk, és addig nincs is szállítás.)

Ahhoz, hogy egyáltalán képesek legyünk refaktorálásra akár nagyobb léptékekben is jó tesztekre van szükség.

A “jó” számomra a következőket jelenti (végletekig szigorúan értelmezve):

1. elég gyors: hogy ne kelljen órákat várni, hogy megtudjam, a változtatásaim helyesek-e, (különben nem fogjuk megvárni minden egyes változtatás után a tesztek lefutását, és így több commitra eggyüttesen futnak le majd a tesztek. Ha eltörik a build, nehezen tudjuk meghatározni, hogy milyen változás okozta a hibát, és kinek a felelőssége a javítás. Fennáll a veszélye, hogy nem fog érdekelni, mit mutatnak a tesztek.)
2. stabil: instabil tesztek állandó ellenőrzése sok energiát visz el, egy idő után már senkinek nem lesz kedve megnézni, miért szállnak el a tesztek,
3. lehessen bennük bízni: mindenki tudja, hogy pontosan mit várhatunk a tesztektől (minden fejlesztő, tesztelő/PO/PM) – a csapaton belül (és akár kívül is) minden irányból meglegyen a bizalom a szoftverben,
4. karbantartható: ha nehezen karbantarthatóak a tesztek, akkor nem tudom a kódomat refaktorálni/továbbfejleszteni, mert a tesztek megakadályozzák azt (a rossz tesztkód a produkciós kód és a tesztkód refaktorálhatóságának rovására is megy),
5. könnyen megérhető: ha nem érthető meg a tesztem, akkor fennáll a veszélye annak, hogy ha eltörik, akkor nem akarja azt senki sem megérteni és megjavítani (ld. @Ignore).

7 év eltelt a post megírása óta. Most úgy gondolom, a jó (clean) kód ismérve, hogy jó tesztek vannak-e hozzá.

SOLID
Code at Wrong Level of Abstraction
Structure over Convention
KISS
YAGNI ha ez is van a táblában

Egyébként maga Uncle Bob is elmondja, hogy nem az lesz, hogy megvilágosodsz, ha elolvastad a könyvet, és máris jó kódot fogsz írni elsőre, sőt, ő maga is bemutatja a könyvben, hogy hogyan írt meg először valamit, és refaktorálta át 3-4 lépésben. Ez egy nagyon kemény, és fájdalmas tanulási folyamat.

Én azon rögögök, amikor egyesek jönnek, és elkezdik magyarázni az elolvasása után, hogy igen, ezekkel egyet értek, de a paraméteradás résszel nem. De hát ott van szépen érvekkel és példákkal. Hozd te is az érvedet, de csak azért, mert ezt a részét nem értetted meg, ne mondd azt, hogy hülyeség. Igen, 3 hét intenzív tanulás után, mert rengeteg
könyvet és videót tettem magamévá, nekiülltem, hogy na most akkor, és lefagytam. Egy autoloader osztályt már 3 napja írtam, mire elkészült 50 sor lett az egész osztály mindenestül.

Ha érdekel, akkor nagyon sokat kell olvasni és gyakorolni, ezt nem lehet megúszni. Ha nem értetted meg a könyvből, keress más fórumokat, és kérdezz ott, előbb utóbb rutinszerű lesz ezeknek az elveknek a betartása.

A múltkor valaki azzal jött, hogy ok, de a setter-eket én meghagyom, nekem az úgy kényelmes. Rendben kisbarátom, csak akkor arra kérlek, ne nevezd magad profi programozónak.

$Car->setEngine(Enginge $Engine);

Komolyan? Láttunk már olyat az életben, hogy valaki menet közben motort cserélt? :))

A jelenlegi kód, amit saját magamtól örököltem, katasztrófális. Mindenhol statikus metódosuk, amik más statikus metódusokat hívnak meg, na ez a végeláthatatlan, és így lesz 20-30 fájl nyitva egyszerre. Szép csendben elkezdtem refaktorálni, sokszor 3 perc amíg kiszervezek egy blokkot onnan, ahova nem való, és átteszem egy metódusba, vagy másik oszályba, adok magamnak rá időt, mondjuk 10 percet, hogy jó névvel lássam el, megfelelő könyvtárba, domain alá tegyem, és kész, tiszta száraz érzés, tudni fogom mit csinál, ha tesztem is van rá mégjobb, rájöttem, hogy kinyírtam vele 3 duplikációt, azokról a helyekről is ezt hívom majd, és mostantól megbízom benne, nem kell mindig végigmenni rajta, megnyitogatni, Jelölöm a könyvtárakat egy perfix-szel, ahol már az új módszereket használom, és szép lassan minden nap fejlődik és tisztább lesz a kódom, míg egyszer majd teljesen az.

Nem kellett a nulláról újrakezdeni, pici átalakítás az autoloaderen, és kb. 1 óra munkával elkerültem, hogy amikor két hét múlva elő kelljen vennem, 2 órákat töltsek el azzal, amig kidebugolom, hogy akkor ezt most itt hogy? Ja, most ez az eset van, akkor erre megyek, aha, de ez spéic eset, basszus, hol tartottam? Na akkor elölről… stb..
Na meg persze a későbbi ilyen 1-2 kidobott órák, amikor haladhattam volna, de nem tudtam, nem voltam hajlandó rászánni 10 percet most, hogy tisztábban hagyjam ott a kódot, mint ahogy akkor találtam, mikor hozzá kellett nyúlnom.

Tapasztalatom szerint a következők nagy hatással vannak arra, hogy feleslegesen növeljék a dokumentáció méretét:

1. A fejlesztő egyéni motivációja. Motiválatlan fejlesztő azt akarja, hogy “tollba mondják”, mit kell csinálni. Motivált fejlesztő maga találja ki és maga jár utána, hogy mit és hogyan kell csinálni. (Ugyanaz a személy különböző környezetekben más és más motivációs szinten dolgozhat.)

2. Diszfunkcionális projektszervezet, bizalom hiánya.
a) Bizonyos szerepkörökben dolgozó emberek, hogy igazolják munkájukat, felesleges dokumentumokat gyártanak (tipikus betegsége a BA-knak és tesztelőknek).
b) Szereplők, akik nem bíznak egymásban, dokumentumokban rögzítik az elvárásokat egymással szemben. (Megrendelő-szállító cég, BA-fejlesztő, tesztelő-fejlesztő stb.).

3. Értelmetlen szoftverfunkciók, rossz döntések, amik növelik a komplexitást. Példák:
a) ha a megrendelő egy nagyvállalat/állami cég, hajlamos feleslegesen duzzasztani a szkópot, hogy a belső politikai viszonyoknak eleget tegyenek.
b) fejlesztő cég felesleges funkciókat fejleszt (lenyűgözze a megrendelőt/felhasználókat, azonban a funkciókat a kutya se használja majd, “ezt majd úgyis meg kell csinálni 1 hónap múlva”, “legyen általános” stb.)
c) rossz architektúra, rossz csapatfelosztás, rossz folyamatok.