Joel on Software   Joel, szoftverekről

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

FogBUGZ úgy indult hat évvel ezelőtt, hogy megpróbálom megtanulni az ASP-t. Kicsivel később ő lett a házon belüli hibakövető rendszerünk. Szinte naponta adtunk hozzá olyan új tulajdonságokat, amikre szükség volt, egészen addig, amíg elég jó lett ahhoz, hogy ne kelljen rajta tovább dolgozni.

Sok ismerősöm kérdezte, hogy használhatná-e a FogBUGZ-t a saját cégénél. A probléma az volt, hogy túl sok fixen belekódolt dolog volt benne, így kemény munka lett volna máshol futtatni, mint azon az egy gépen, ahol telepítve lett. Használnom kellett egy csomó SQL tárolt eljárást, ami azt jelentette, hogy SQL szerverre is szükség van a FogBUGZ futtatásához, ami drága, és kilőtte a kétfős csapatokat, akik használni akarták. És így tovább. Így aztán mondtam a barátaimnak, “ejnye, 5000 dolláros tanácsadási díjért rászánok néhány napot és kitisztítom a kódot, így használható lesz SQL helyett Access-szel is.” Általában az ismerőseim túl drágának tartották.

Miután ez párszor megtörtént, felfedeztem - ha ugyanezt a programot meg kellene vennem, három emberre fejenként 2000 dollárba kerülne, és utána derülne ki, hogy milyen. Vagy 30 emberre 200 dollárba fejenként. Szoftver, ami közel olyan mint ez. Így aztán 2000 végén Michael leült, és portolta a kódot, így működött Access-szel és SQL-lel, minden site-specifikus kódot header állományba tett, és elkezdtük árulni a dolgot. Én nem vártam tőle túl sokat.

Napjainkban, gondolom, kismillió hibakövető rendszer létezik. Minden programozó megírja a saját kis hibakövető rendszer. Miért venne bárki is meg a miénket? Egy dolgot tudok: a programozók, akik a saját céget indítanak nagyon gyakran arra a rossz következtetésre jutnak, hogy hozzájuk hasonlóan mindeki más is programozó és ugyanazt akarják, amit ők, és ezért van ez a halva született ötletük, hogy  programozási eszközöket gyártó vállalkozást indítsanak. Ez az, amiért annyi vézna cég házal forráskód-generáló ügyefogyottsággal, hibacsapdával és e-mail bénázással, hibakereső programocskával, szintakszis színezéses szerkesztő izével, ftp-ző cuccal, és ráadásul hibakövető rendszerrel. Minden ilyet csak a saját programozója szeret. Nincs kedvem ilyen csapdába esni!

Általában semmi sem úgy történik, ahogy eltervezted. A FogBUGZ népszerű. Igazán népszerű. Egy meglehetős darabot könyvelhet el magának a Fog Creek éves beszámolójában és az értékesítés volumene szilárdan emelkedik. Az emberek nem akarják abbahagyni a vásárlást.

Így megcsináltuk a 2.0-s verziót. Megpróbáltunk néhány nyilvánvalóan fontos tulajdonságot hozzá adni a rendszerhez. Amíg David dolgozott a 2.0-s verzión, mi tényleg nem gondoltunk arra, hogy megéri ezt a sok erőfeszítést, így aztán hajlamos volt a dolgokat “célszerűen” lekódolni, mintsem “elegánsan”. Bizonyos, khm., tervezési hibák ötvöződtek az eredeti kódban. Itt van például két teljes halmaza közel azonos kódoknak a fő hiba-szerkesztő oldalhoz. SQL utasítások mindenhol elszórva a HTML-ben itt is-ott is, kicsik és nagyok, mindenhol. A HTML-ünk recseg ropog, és olyan böngészőkhöz terveztük, amik egy about:blank betöltés során összeomlanak.

Jeeeee, brilliánsan működik, eddig nulla darab hibáról tudtunk. De belül a kód, hogy egy technikai kifejezést használjak, egy “nagy zűrzavar.” Új tulajdonságok hozzáadása egyszerűen kihozza az aranyered. Egy mezőnek a hozzáadása a központi hibatáblához valószínűleg 50 módosítást jelent, és még azután is fogsz találni helyeket, amiket elfelejtettél módosítani, miután megvetted az első családi rakéta autódat azokra a hétvégi kirruccanásokra a marsi víkend házadhoz.

Egy nagyobb cégnél, amit mondjuk egy expressz-csomagoló-és-szállító üzletből érkezett ügyvezető irányít, talán úgy dönt, hogy kidobja a kódot és újrakezdi.

Említettem már, hogy miért nem hiszek a teljes újraírásban? Arra tippelek, hogy már beszéltem erről.

Bárhogyan is legyen, a kód teljes újraírása helyett úgy döntöttem, hogy rászánok három hetet az életemből, és teljesen kisikálom a kódot. Subi-dubi-dú. A refactoring szellemében néhány szabályt állítottam fel ehhez a gyakorlathoz.

1. Semmilyen új tulajdonságot, még a legkisebbet sem teszek hozzá a kódhoz.
2. Minden esetben, minden verziónál tökéletesen kell, hogy működjön.
3. Minden amit csinálni akartam logikai transzformáció, -- ezek a dolgok többnyire mechanikus módosítások, amikről saját magad is rögtön meggyőződhetsz, nem fogja megváltoztatni a kód viselkedését.

Végigmentem minden forrás állományon, egyszerre mindig csak eggyen, az elejétől a végéig, végignéztem a kódot, azon gondolkozva, hogyan tudnám jobban szervezni, és nagyon egyszerű változtatásokat végeztem rajta. Itt van néhány tipikus változtatás, amit a három hét során elvégeztem.

• Minden HTML-t xhtml-re változtattam. Például a <BR> helyett <br /> lett, minden attribútumot idézőjelek közé tettem, minden egymásba ágyazott HTML tag-ot összepárosítottam, és minden oldalt ellenőriztem.
• Minden betű formázást (<FONT>) eltávolítottam, és beraktam mindet CSS stíluslapokba.
• Minden SQL utasítást és valódi program logikát kivettem a megjelenítő kódból (ezeket a marketingesek “üzleti logiká”-nak hívják). Ezek a dolgok osztályokba mentek, amiket túlságosan nem terveztem meg - Egyszerűen, ahogy felfedeztem lustán hozzáadtam a metódusokat. (Valahol valaki egy nagy polc 4x6-os kártya hegyezi a ceruzáját, hogy kinyomja a szemeimet. Mit képzelsz, hogy nem kell tervezési eljárás az osztályaidhoz?)
• Ismétlődő kódblokkokat találtam ezekből osztályokat, függvényeket és metódusokat hoztam létre az ismétlődés megszüntetésére. A nagy függvényeket kisebbekre vágtam szét.
• Minden megmaradó angol szöveget kivettem a kódból és egyetlen állományba tettem, hogy könnyebb legyen a kódot nemzetközivé tenni.
• Újraszerveztem az ASPsite-t, hogy csak egy belépési pontja legyen a több különböző állomány helyett. Ez egyszerűvé teszi azokat a dolgokat, amiket sűrűn használsz, például nagyon formás hibaüzenetet tudunk most megjeleníteni, ha rossz adatbevitel történt. Ez olyasmi, aminek könnyűnek kell lennie, ha jól végiggondolod, mit teszel, de nem tudod jól végiggondolni a tennivalókat, amíg tanulod az ASP-t.

A három hét során a kód belül egyre jobb lett. A végfelhasználók felé 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 meg tudtam volna állni, mivel minden adott pillanatban 100%-osan működő kódom volt (és minden verziót feltöltöttem a saját élő FogBUGZ szerverünkre, hogy biztos lehessek benne). És az is tény, hogy soha sem kellett erősen gondolkoznom, és megterveznem a dolgokat, mivel egyszerű logikai transzformációkat végeztem. Időnként találkoztam hátborzongató kóddarabbal. Ezek általában hibajavítások voltak, amiket az évek során elvégeztünk. Szerencsére a hibajavításokat sértetlenül meg tudtam tartani. Az esetek nagy többségében arra ébredtem rá, ha újra kezdtem volna a nulláról, ugyanazokat a hibákat elkövettem volna, és hónapokig vagy évekig észrevétlenül maradtak volna.

Alapjában véve már készen is vagyok. Ahogy terveztem három hét alatt elkészültem. Szinte minden sor megváltozott. Igen, végignéztem minden sorát a kódnak, és a legtöbbet megváltoztattam. A felépítés teljesen megváltozott. Minden hibakövető funkcionalitás teljesen elvált a HTML felhasználói felülettől.

Itt van a kódsikáló tevékenységem összes előnye:

• Sokkal kevesebb ideig tartott, mint a komplett újraírás. Tegyük fel, (a FogBUGZ-nál korábban történ fejlesztés alapján), hogy a komplett újraírás egy évig tartott volna. Ezért azt gondolom, hogy megspróroltam 49 hét munkát. Ez a 49 hét képviseli a kód tervezésében lévő tudást, amit csorbítatlanul meghagytam. Soha sem gondoltam, hogy “ó, itt szükségem van egy új sorra.” Egyszerűen csak gondolkodás nélkül kicseréltem <br />-re a <BR>-t, és mentem tovább. Nem kellett azon gondolkoznom, hogy tudom megoldani az állományok feltöltését. Az már működik. Csak egy kicsit feljavítottam.
• Nem hoztam létre új hibát. Néhány kisebben természetesen átestem. De soha nem tettem olyan dolgot, ami hibát eredményezhetett.
• Bármikor megállhattam és szállíthattam volna, ha szükséges.
• Az ütemterv előre megjósolható. Egy hét után pontosan meg tudod mondani, hogy egy óra alatt hány sor kódot tudsz tisztába tenni, és egy jó becslést tudsz adni a projekt hátralévő idejére. Próbáljátok meg inkább ezt, Mozilla folyóba-fulladt emberek.
• A kód sokkal könnyebben bővíthető új tulajdonságokkal. Valószínűleg a három hetet gyorsan visszanyerjük az első nagyobb funkció implementálása során.

Az irodalom nagy része Martin Fowler-nek tulajdonítható, annak ellenére természetesen, hogy kódtisztítás elve már évek óta jól ismert a programozó körében. Érdekes új terület a refaktoring eszközök területe, ami csak egy jól hangzó név olyan programoknak, amik ezeknek a dolgoknak egy részét automatikusan elvégzik. Messze vagyunk még attól, hogy minden jó eszközünk meglegyen, amire szükségünk van - a legtöbb programfejlesztő környezetben egy olyan egyszerű transzformációt sem tudsz elvégezni, mint a változó nevének a megváltoztatása (és minden erre történő hivatkozás automatikus megváltoztatása). De egyre jobbak, és ha tényleg valamiféle programzó francot akarsz létrehozni vagy jót akarsz tenni az open-source közösséggel, akkor az ajtó nyitva áll.