Joel a szoftverről szoftvermenedzsment egyszerűen

Joel lapja

Gerilla magyar fordítások

Hivatalos fordítások

Sika-mika

Írta: Joel Spolsky (2002. január 23.)
Fordította: Plesz Gábor
Lektorálta: Nagy Balázs, Verók István (2003. január 3.)
Az eredeti cikk, az eredeti fordítás

Az az egyik ok, ami a teljes kód újraírására csábít, hogy a napi használat esetenként nagyon túlnövi az eredeti terveket. Talán csak prototípusnak indult az egész, esettanulmánynak vagy ujjgyakorlatnak, esetleg hogy a cégalapítást követő kilenc hónapon belül tőzsdére kerüljünk, vagy csak egyszeri demónak készült. Mára viszont egy nagy zűrzavarrá nőtte ki magát, aminek működését a hold állása is befolyásolja, bővíteni lehetetlen, mindenki haja az égnek áll tőle, a régi programozók inkább felmondanak, mint hogy ezen kelljen dolgozniuk, a helyükre kerülő újak számára pedig az egész kódnak se füle, se farka. Ezért inkább meggyőzik a vezetőket, hogy mivel az egész úgyis teljesen befuccsolt, kezdjék újra. Ezalatt a Microsoft kis gömböce szőröstül-bőröstül el is nyeli az egész piaci szegmensüket. Ma arról mesélek, milyen más kiutat választhatnának.

Egyik termékünket, a FogBUGZ-t hat évvel ezelőtt gyakorlásként kezdem el írni, hogy beletanuljak az ASP programozásba. Kicsivel később ez lett a házon belüli hibakövető rendszerünk. Szinte naponta bővült új, hasznosnál hasznosabb funkciókkal, amíg meg nem ütött egy elég jó szintet, amikor már nem kellett rajta tovább szöszmötölni.

Több ismerősöm kérdezte, hogy használhatná-e a FogBUGZ-t a saját cégénél. A gond csak az volt, hogy túl sok bedrótozott dolog miatt a fejlesztő gépen kívül máshova telepíteni igen kemény munka lett volna. Egy csomó SQL Server tárolt eljárást használtam akkoriban, a FogBUGZ futtatásához tehát SQL Server-re is szükség volt. Ez túl drága és túlzás lett volna a néhány fős reménybeli felhasználóknál. És így tovább. Így aztán azt mondtam mindenkinek, hogy „hát, $5000 tanácsadói díjért már rá tudnék szánni néhány napot a kód letisztítására, hogy SQL Server helyett Access-szel is használható legyen”. Ezt persze mindannyian túl drágának tartották.

Miután ez párszor megtörtént, rájöttem: ha ugyanezt a programot mondjuk három embernek el tudnám adni fejenként $2000-ért, már megérné. Vagy harminc embernek $200-ért. A szoftver jól adja magát az ilyesmihez. Így hát 2000 végén Michael leült portolni a kódot, hogy mind Access-szel, mind SQL Server-rel működjön, az összes telepítésfüggő dolgot fejlécfájlba tette, és elkezdtük árulni. Igazából nem vártam az egésztől túl sokat.

Elvégre, gondoltam, napjainkban kismillió hibakövető rendszer létezik. Minden programozó megírta már a saját kis hibakövető rendszerét. Miért venné meg bárki a miénket? Egy dologban azonban biztos voltam: saját céget indító programozók gyakran jutnak arra a hibás következtetésre, hogy hozzájuk hasonlóan mindenki más is programozó, és az elvárásaik is hasonlók, így programozási segédeszközöket kezdenek el árulni. Ezért lehet Dunát rekeszteni forráskód-generáló, hibafogó, levelező, hibakereső marhasággal, szintaxis-színező szövegszerkesztő izével, ftp-ző bigyóval, és hmm, hibakövető csomaggal házaló ványadt céggel. Csupa olyan dolog, amit csak egy programozó szeretne, a nagyközönséget nem érdeklik. Én nem akartam ebbe a csapdába esni!

Persze, semmi sem úgy történik, a

Sika-mika

Így elkészítettük a 2.0-s verziót. Megpróbáltunk néhány nyilvánvalóan fontos funkciót hozzáadni a rendszerhez. Míg David a 2.0-s verzión dolgozott, egyáltalán nem voltunk biztosak benne, hogy megéri-e ezt a sok erőfeszítést, így ő aztán hajlamos volt a dolgokat inkább „célszerűen”, mintsem „elegánsan” megoldani. Voltak bizonyos, nos tervezési hibák, amik tovább rontották a levegõt. A fő hibabeviteli oldalt megjelenítő kód két, szinte teljesen azonos példányban szerepelt. SQL utasítások voltak elszórva a HTML-ben ide-oda, elöl, hátul, mellbe. A recsegő-ropogó HTML is azokat az ősrégi, hibákkal lyuggatott böngészőket idézte, amik egy about:blank betöltésétől összeomlottak.

Kívülről nézve remekül működött, és attól kezdve máig nulla ismert hibánál tartunk. Ám belülről a kód – szakkifejezéssel élve – egy „nagy mákostészta” volt. Új funkció hozzáadásakor néha inkább egy púpot kívántam volna a hátamra. A központi hibatáblába egy mezőt felvenni legalább ötven módosítást jelentett, és még akkor is maradnának ügyesen eldugott javítandó helyek, mikor már rég megvan a marsbéli nyaralásra szánt családi űrautó is.

Egy kevésbé hozzáértő cég (főleg ha a helyzete mondjuk egy expressz csomagküldő szolgálattól átcsábított vezetővel súlyosbított) ilyenkor dönthet úgy, hogy kidobja a kódot, és újrakezdi.

Említettem már, hogy nem hiszek a teljes újraírásban? Mintha már felhoztam volna egyszer-másszor.

Bárhogy is, az újraírás helyett úgy döntöttem, hogy megér három hetet az életemből a kód teljes kisikálása. Sika-mika. A refaktorálás (kódtisztítás) szellemében a következőkhöz tartottam magam:

1. Semmilyen új funkció nem – még a legapróbb sem – kerülhet be.
2. A programnak mindig, minden feltöltéskor tökéletesen kell működnie.
3. Csak triviális átalakításokat végeztem – mechanikusan is végezhető, magától értetődő módosításokat, amik nem változtatják meg a kód viselkedését.

Egyenként végigmentem minden forrásfájlon, elejétől a végéig átnéztem a kódot, közben a világosabb szerkezeten törtem a fejem, és egyszerű változtatásokat tettem. A három hét során főleg a következő tipikus esetek fordultak elő:

• Minden HTML-t xhtml-é változtattam. Például minden <BR>-t <br />-re cseréltem, minden attribútumértéket idézőjelbe tettem, a beágyazott tag-eket összepárosítottam, és minden oldal szintaxisát ellenőriztem.
• Minden formázást (pl. <FONT> tag-ek, stb.) átraktam CSS stíluslapokba.
• Minden SQL utasítást kivettem a megjelenítő kódból, alkalmasint a programlogikából (amit a marketingesek „üzleti logikának” szeretnek hívni). Ezeket az anyagokat osztályokba rendeztem, amiket nem különösebben terveztem meg – a metódusokat alkalomszerűen hozzáadtam (egy nagy csomag 4x6-os kártya birtokosa valahol a ceruzáját hegyezve várja, hogy kiszúrja vele a szememet – mit képzelsz, hogy nem tervezed meg az osztályokat?).
• A megtalált ismétlődő programblokkokat osztályokba, függvényekbe, vagy metódusokba szerveztem, hogy minden csak egy helyen szerepeljen. A hosszú függvényeket rövidekre vágtam szét.
• A kódban megmaradt angol szövegeket egyetlen fájlba különítettem el, hogy könnyebben lehessen nemzetközivé tenni.
• Újraszerveztem az ASP-oldalakat, így csak egy belépési pont lett a több különböző fájl helyett. Ez a korábbi nehézkes dolgokat nagyban megkönnyíti, például az űrlapok hibaüzenetei már közvetlenül a hibás adatok mellett jelennek meg. Egy jól tervezett szoftvertől az ilyesmi joggal elvárható, de akkoriban még az ASP programozás tanulása kötött le, az ilyen finomságok kevéssé számítottak.

A három hét során a kód belülről egyre jobb és jobb lett. A végfelhasználók szemszögéből nem sok változás történt. Néhány betűtípus a CSS-nek köszönhetően egy kicsit szebb lett. Bármikor abba tudtam volna hagyni, mivel minden adott pillanatban 100%-osan működő kódom volt (és minden verziót feltöltöttem a belső FogBUGZ kiszolgálónkra, hogy biztos lehessek ebben). Sosem kellett túl sokat gondolkozni vagy megtervezni a dolgokat, mert csak egyszerű, triviális átalakításokat végeztem. Időnként találkoztam furcsa gyöngyszemekkel. Ezek általában az évek során hozzáadott hibajavítások voltak. Szerencsére e javításokat változatlanul hagyhattam. Mi több, rájöttem, hogy nulláról mindent újraírva ugyanazokat a hibákat ejtettem volna, amik megint évekig észrevétlenek maradtak volna.

Alapjában véve elkészültem. Ahogy terveztem, három hét kellett hozzá. Szinte minden kódsor megváltozott. Igen, végignéztem minden kódsort, és a legtöbbjét megváltoztattam. A struktúra már egészen más. A hibakövető funkcionalitás teljesen elvált a HTML felhasználói felülettől.

A kódtisztításom előnyei:

• Sokkal kevesebb ideig tartott, mint a teljes újraírás. Tegyük fel (alapul véve azt, hogy mennyi ideig tartott eljutnunk idáig a FogBUGZ-zal), hogy a teljes újraírás egy évig tartott volna. Nos, eszerint nyertem 49 munkahetet. Az a 49 hét képviseli a kód tervezésében rejlő, csorbítatlanul átmentett tudást. Sosem kellett azon gondolkodnom, hogy „ó, itt szükség van még egy sorra”. Csak gondolkodás nélkül a <BR>-t kellett kicserélni <br/>-é, és mentem tovább. Nem kellett a fájlokat több MIME-részben feltöltő kódot megírnom. Az már eleve működött. Csak egy kicsit feljavítottam.
• Nem ejtettem új hibát. Néhány apró persze átcsúszhatott. Ám nem tettem olyan dolgot, ami hibát eredményezhetett.
• Szükség esetén bármikor abbahagyhattam és szállíthattam volna.
• Az ütemterv teljesen megjósolható volt. Az egy óra alatt tisztába tett kódsorok száma egy ilyen hét után pontosan kiszámolható, a projekt hátralévő ideje pedig elég jól felbecsülhető. Ez mintha nem lett volna a Mozillába fulladt csapat erőssége.
• A kód már sokkal jobban bővíthető új tulajdonságokkal. Valószínűleg a három hetet az első nagyobb funkció implementálásakor visszanyerjük.

A refaktorálás irodalma jobbára Martin Fowlernek tulajdonítható, bár a kódtisztítás elveit a programozók természetesen évek óta ismerik. Érdekes terület a refaktoráló segédeszközök köre, ami csupán egy hangzatos név az ilyen feladatokat automatikusan elvégző programokra. Még persze közel sincs minden jól használható eszköz a kezünkben – a legtöbb programfejlesztői környezet még olyan egyszerű átalakítást sem tud, mint pl. egy változó nevének megváltoztatása (és minden hivatkozás automatikus cseréje). Ám egyre jobbak lesznek, és ha amolyan ványadt céget akarsz indítani, ami programfejlesztői kütyükkel házal, vagy hasznosan kívánsz hozzájárulni a nyílt forrás ügyéhez, az ajtó nyitva áll.