R01.qxd
4/2/2009
12:50 PM
Page 1
1 Újratervezés
Újratervezés. Mi is ez? Miért csináljuk? Röviden az újratervezés a kódbázis fokozatos tökéletesítése kis változtatások végrehajtásával, amelyek nem módosítják a program viselkedését, mindezt általában valamilyen automatizált eszköz segítségével végezve. Az újratervezés célja az, hogy eltávolítsuk a kódból az évek során összegyûlt kuszaságot, ezzel elérve, hogy könnyebb legyen karbantartani, könnyebb legyen a hibakeresés és könnyebben tudjuk új képességekkel bõvíteni. Technikailag ez nem azt jelenti, hogy az újratervezéssel kijavítunk valamilyen hibát, vagy új lehetõséggel bõvítjük a kódot. Persze a gyakorlatban az újratervezés során én magam is mindig találok valami kijavítandó dolgot és rendszerint találok bõvítései lehetõségeket is. Az újratervezés során gyakran elõfordul, hogy az addig bonyolult problémák átalakulnak, átláthatóvá sõt egyszerûvé válnak. A kód tökéletesítésének elsõ lépése az újraszervezés. Ha olyan a személyiségünk, hogy egy új projekt, vagy munka elõtt rendet rakunk az asztalunkon vagy az irodában, akkor most is ezt fogjuk tenni. Az újratervezés segít abban, hogy a régi dolgok ne álljanak az újak útjába. Nem arról van szó, hogy mindent tiszta lappal kezdünk, hanem inkább arról, hogy olyan tiszta, rendezett munkakörnyezetet kapunk, ahol minden kéznél van, amire szükségünk van, ahonnan egyszerûbben léphetünk tovább. Az újratervezés gondolata az objektum-orientált fejlesztéssel foglalkozók közösségében merült fel úgy 1990 táján (William F. Opdyke és Ralph E. Johnson, „Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems,„ Proceedings of the Symposium on Object-Oriented Programming Emphasizing Practical Applications [SOOPPA], September 1990, ACM), elõtte valószínûleg csak szûk körben alkalmazták. A fogalmat aztán Martin Fowler hozta a köztudatba 1999ben, az Újratervezés címû könyvével (Refactoring, Addison-Wesley, 1999; magyar fordítás: Kiskapu Kiadó, 2006).
R01.qxd
4/2/2009
2
12:50 PM
Page 2
Refactoring HTML
Azóta számos IDE és más eszköz, például az Eclipse, IntelliJ IDEA és C# Refactory rendelkezik újratervezési katalógussal, illetve több nyelvhez (Java, C#) vannak megfelelõ eszközök, sõt készült néhány teljesen új céleszköz is. Ugyanakkor nem csak az objektum-orientált kódra és az objektum-orientált nyelvekre jellemzõ, hogy néha összekuszálódnak és újra kell tervezni õket. Bármely korábban fejlesztett és folyamatosan karbantartott összetett rendszernek hasznára válhat az újratervezés. Ennek alapvetõen két oka van. 1. A rendszerrel és a problémákkal kapcsolatban szerzett új ismeretek menet közben gyakran olyan részleteket tesznek láthatóvá, amelyeket a fejlesztés kezdetén nem vettek észre. Senki sem tud tökéleteset alkotni elsõre. Mûködés közben egy ideig figyelnünk kell a rendszert ahhoz, hogy bizonyos típusú hibákat és problémákat észrevehessünk. 2. Az idõk folyamán a funkciók szaporodnak és ehhez új kódokat kell írni. Ha az eredeti rendszer tökéletesen oldotta meg a problémát, az új funkciókhoz írt új kódok nem fognak tökéletesen illeszkedni a régi kódhoz. Egyszer csak elérünk egy olyan pontra, ahol a régi kódot már nem tudjuk új funkciókkal bõvíteni. Ha végül ott találjuk magunkat egy olyan rendszerrel, amit már nem lehet tovább fejleszteni, akkor két választási lehetõségünk marad. Kihajíthatjuk az egészet és nekiláthatunk egy új rendszer építésének az alapoktól kezdve, vagy aládúcolhatjuk a meglévõ alapokat. A gyakorlatban általában nincs elég idõnk, vagy nincs elég pénz arra, hogy egy már mûködõ rendszert egy teljesen újra cseréljünk le. Sokkal költséghatékonyabb megoldás a meglévõ rendszert megtámogatni a további munka elõtt. A legjobb, ha ezeket az aládúcolási munkákat fokozatosan hajtjuk végre, egy idõben csak egyet, nem pedig amolyan durr-bele módon. Léteznek olyan bonyolult rendszerek is jókora kóddal, amelyek nem objektum-orientáltak, sõt lehet, hogy a szó klasszikus értelmében nem is nevezhetõk programnak, mert nem valamilyen megszokott programozási nyelven készültek. Scott Ambler és Pramod Sadalage például a Refactoring Databases (Addison-Wesley, 2006) címû könyvben bemutatta, hogyan kell újratervezni nagy alkalmazásokat kiszolgáló SQL adatbázisokat. Habár a nagy hálózati alkalmazások mögött gyakran relációs adatbázisok mûködnek, ezek a rendszerek egy webhelyen keresztül érhetõk el. A vékonykliensek Firefox vagy Internet Explorer böngészõvel szállított grafikus felhasználói felületei (GUI) lassan leváltják a vastag klienseket még az olyan üzleti alkalmazásoknál is, mint amilyen például a bérszámfejtés. A Sun és a Google merész fejlesztõi még ennél is tovább mentek: olyan klasszikus alkalmazásokat cserélnek le HTML, CSS és JavaScript alapú webalkalmazásokra mint a szövegszerkesztõ és a táblázatkezelõ. Végül a Webnek és a mindenütt megtalálható webböngészõknek köszönhetõen új típusú, azelõtt nem létezõ alkalmazások születtek meg, amilyen az eBay, Netflix, PayPal, Google Reader és Google Maps.
R01.qxd
4/2/2009
12:50 PM
Page 3
1. fejezet • Újratervezés A HTML az, ami lehetõvé tette ezeknek az alkalmazások a létrejöttét, gyorsabbá is tette a fejlesztésüket, de nem tette sem könnyûvé, sem egyszerûbbé magát a munkát. És persze egyáltalán nem tette kevésbé összetetté magukat az alkalmazásokat. Az ilyen típusú alkalmazásoknak azóta már a második, harmadik vagy negyedik generációja fut. Ahogy minden más, kellõképp bonyolult és kellõen régóta létezõ alkalmazás, ezek a web-alkalmazások is megtelnek végül rossz minõségû, selejtes kóddal . Az új részek nem épülnek bele megfelelõen a régiekbe. A rendszerek lelassulnak, mert a szerkezetük már túl ormótlan. Biztonsági rések támadnak a régi és az új részek között, melyeken aztán a hackerek ki-be járnak. Ismétlem, eljön a választás ideje, amikor vagy kidobjuk a régi rendszert és kezdjük elölrõl, vagy megerõsítjük az alapokat. Persze valójában nincs is igazán választási lehetõségünk. A mai rohanó világban senki nem fog várni egy teljesen új rendszer kiépítésére. Az egyetlen reális választás az újratervezés.
Miért tervezzük újra? Honnan tudhatjuk, hogy itt van az újratervezés ideje? Van-e a rossz kódnak valami illata, ami megcsapja az orrunkat? Viszonylag kevés ilyen van, de azok aztán „illatoznak” rendesen, így könnyen kiszimatolhatóak.
Szimat: Olvashatatlan a kód A legszembetûnõbb jelenség az, amikor a Forráskód Nézetre váltva úgy tûnik, mintha az egész görögül lenne írva (persze ez csak akkor rossz jel, ha nem görög nyelven dolgozunk). A tapasztalatok szerint a legtöbb programozó tud csúnya kódot írni. A csúnya kód borzalmasan néz ki. Melyiket látnánk szívesebben, az 1.1 Listát vagy az 1.2 Listát? Nem hiszem, hogy el kellene árulnom a helyes megfejtést arra a kérdésre, hogy melyik is a rondább, vagy hogy melyiket lenne egyszerûbb karbantartani. 1.1 Lista
1.2 Lista
Látható, hogy az 1.2 Listában nem csak egyszerûen újraformáztam a kódot. Meg is változtattam. Például a táblából div és lista lett és eltüntettem néhány kötõjelet is. Mindamellett az 1.2 Lista most már közelebb áll a tartalomhoz, mint az 1.1 Listában látható változat. Az 1.2 Listánál alkalmazhatnánk egy külsõ CSS stíluslapot is a formázásokhoz, amit az 1.1 Listából eltávolítottam. Késõbb látni fogjuk, hogy ez a lapok újratervezésének és a dokumentumok megtisztításának egyik legfõbb technikája. Megszabadultam a TARGET="_blank" attribútumtól is, ami a linkeket új ablakokban vagy füleken nyitja meg. Ez általában nem felel meg a felhasználók ízlésének és csak ritkán bizonyul jó ötletnek. Szükség esetén hagyjuk, hogy a felhasználó a vissza gombot vagy az elõzménylistát használja, egyébként pedig minden linket nyissunk meg ugyanabban az ablakban. Ha a felhasználó új ablakban szeretné megnyitni a linket, azt egyszerûen megteheti a menübõl is. Legyen az õ kezében a választási lehetõség. Gyakran a tisztogatási folyamat nem áll másból , mint hogy eltávolítjuk azokat a részeket, amelyeknek eredetileg nem is kellett volna ott lenniük.
R01.qxd
4/2/2009
12:50 PM
Page 5
1. fejezet • Újratervezés Sorhosszúság Az 1.2 Lista azért még nem teljesen ideális. Kicsit kényszeresen a nyomtatott oldal margói közé erõltettem a kódot. Egy valódi forráskód esetében egy sorba valamivel többet raknék be. Túlzásokba azért nem szoktam esni. Soronként 80 vagy annál több karakter már nehezen olvasható és önmagában is enyhe „kód-illatot” áraszt.
Egy apró kivételt azért tehetünk a tartalomkezelõ rendszerekbõl (CMS) generált kódokkal. Ebben az esetben a Forrás Nézetben nem a tényleges forráskódot láthatjuk. Ez inkább egy lefordított gépi formátum. Ilyenkor a CMS bemenete az, aminek ebben az esetben megfelelõen kell kinéznie amellett, hogy olvasható is. Ugyanakkor még mindig szerencsének számít, ha egy CMS vagy szerkesztõeszköz jól formázott, tiszta kódot generálnak. Meglepõen sokszor fogjuk azt tapasztalni, hogy az ilyen eszközök által készített kód csak afféle kiindulási alap, nem maga a végtermék. Adhatunk a kódhoz stíluslapokat, szkripteket vagy egyéb dolgokat, ha az eszköz végzett vele. Mivel ilyen esetekben a nyers kóddal dolgozunk, sokkal egyszerûbb lesz a dolgunk, ha az tiszta és világos.
Szimat: A vezérigazgató nem tudja kitölteni az utazási költség utalványát A Web használhatósága sokat fejlõdött az elmúlt pár évben, de közel sem annyit, amenynyit lehetett vagy kellett volna. A legjobb webhelyek kivételével gyakorlatilag az összesre igaz, hogy hasznára válna, ha inkább az olvasókra fókuszálna, nem pedig a fejlesztõkre és a tervezõkre. Pár apró, a használhatóságra irányuló változtatás – mint például a betûméret növelése (vagy a méret meghatározásának elhagyása) vagy néhány új mezõ felvétele egyegy ûrlapra – óriási mértékben képes megnövelni a termelékenységet. Ez kiváltképp fontos az intranetes alkalmazások esetében illetve minden olyan helyen, amely a fogyasztókkal áll közvetlen kapcsolatban.
Szimat: Lassú az oldalak összeállítása Ha bármely nagyobb böngészõnek fél másodpercnél tovább tart megjeleníteni egy oldalt, gondban vagyunk. Ez az egyetlen olyan tünet, amit egy kissé nehéz megítélni, mert sok oldal a hálózati késés vagy a túlterhelt adatbázisok és HTTP szerverek miatt lassú. Ez persze mind probléma, de olyanok, amelyeken a HTML változtatásával nem tudunk semmit javítani. Ugyanakkor ha egy weblap anyaga a helyi fájlrendszerünkben van, és a böngészõnek így is fél másodpercnél tovább tart a renderelése, garantáltan újratervezésre van szükség, hogy csökkentsük ezt az idõtartamot.
Szimat: Az oldalak a különbözõ böngészõkben másképp jelennek meg Az oldalaknak nem muszáj minden böngészõben ugyanúgy kinézniük. Ugyanakkor az összes tartalom és funkcionalitás elérhetõ kell legyen mindenki számára, aki valamelyik elterjedt böngészõt használja. Ha egy oldal olvashatatlan vagy használhatatlan a Safari, Ope-
5
R01.qxd
4/2/2009
6
12:50 PM
Page 6
Refactoring HTML
ra, Internet Explorer vagy Firefox böngészõkben, ott problémák vannak. Ilyen például az, amikor azt látjuk, hogy az oldal teljes képernyõ széles oldalsávval indul, és úgy követi a tartalompanel. Vagy ha az oldalsáv a tartalom alatt jelenik meg, ahelyett, hogy fölötte lenne. Ilyenkor az oldal általában tökéletesen néz ki a fejlesztõ böngészõjében, ám õ nem törõdött azzal, hogy az általunk használttal is leellenõrizze. A megoldás egyszerû: minden esetben vizsgáljuk meg weblapjainkat a fõbb böngészõkkel. Ha bármikor azt a szöveget látjuk, hogy „A megtekintéshez az Internet Explorert javasoljuk”, kezdhetünk szimatolni és felkészülni az újratervezésre. Ha bármi olyasmit látunk, mint az 1.1 ábrán, annak penetráns „kód szaga” van, amit bizony az összes olvasónk is érezni fog.
1.1 ábra A Wal-Mart kizárja a nem IE-t használókat
Az Internet Explorer jelenleg valamivel kevesebb, mint a piac 80%-át tudhatja magáénak, de ez az arány rohamosan csökken. Az sem lehetetlen, hogy ez egy jócskán túlbecsült érték, mivel a legtöbb webes keresõrobot (web spider) és web-bot tévesen IE-ként azonosítja magát, eképpen aránytalanul növelve a találatok számát. A Mac OS X-et és Linuxot futtató felhasználóknak esélyük sincs rá, hogy Internet Explorert használjanak. Vége azoknak az idõknek, amikor elegendõ volt csupán egyetlen böngészõhöz megtervezni egy webhelyet. Ennek a jelenségkörnek egy variánsa az is, amikor meghatározunk egy adott képernyõméretet – például „Az oldal megtekintése 1024x768-as felbontásban javasolt. A képernyõ felbontásának megváltoztatásához használja a ...”. A jól megtervezett weblapoknak nincs szükségük külön böngészõre vagy képernyõméretre.
R01.qxd
4/2/2009
12:50 PM
Page 7
1. fejezet • Újratervezés
Szimat: Az oldalak eléréséhez veszélyes vagy nem szabványos technológiák szükségesek Sok hely használ sütiket (cookies), JavaScriptet, Flash-t, PDF-et, Javat vagy más, nem HTML technológiát. Habár mindnek megvan a maga helye, a Weben túlzásba viszik a használatukat. Ezek a technológiák közel sem annyira hasznosak vagy megbízhatóak, mint ahogy azt a legtöbb webtervezõ gondolja. Sûrûn olvashatjuk a biztonsági felhívásokban, hogy a felhasználók ebben és ebben a böngészõben tiltsák le a használatukat, hogy elkerüljék az aktuális heti támadást. Sokukat nem támogatja a Google és más keresõk sem. Ebbõl kifolyólag meg kell bizonyosodnunk arról, hogy a webhelyünk akkor is mûködõképes marad, ha ezek a technológiák nem állnak rendelkezésre. Az ilyen esetekben szerencsére elég határozottan illatozik a kód, könnyû kiszimatolni. A legkisebb jelzés is arra utal, hogy problémára bukkantunk: Süti használata szükséges Sajnáljuk, de a weblap megtekintéséhez el kell fogadnia a sütiket. A továbblépéshez engedélyezze a sütiket Internet böngészõjében. A sütiket a weblapnak az ön igényeihez igazításához használjuk, egy jobb, személyre szóló szolgáltatás biztosításához, valamint egyes beállítások megjegyzéséhez, hogy legközelebb önnek ne kelljen újra megadni ezeket.
Ez nemcsak a felhasználók számára bosszantó. Az oldalakat a Google is alapból kizárja, tehát a keresõmotoroknál elég rossz helyezést érnek el. Némiképp zavarba ejtõ módon a következõ példa egy olyan oldalról származik, amely a HTML megtisztításáról beszél: Megjegyzés: A Tartalomjegyzék dinamikusan generálódik. Kérjük engedélyezze a JavaScriptet a megtekintéshez.
A dinamikus tartalomhoz legmegfelelõbb a szerveroldali sablon használata, de a kliensnek továbbra is statikus HTML-t küldünk. És íme egy oldal, ahol az összes tünet együtt megtalálható: Ez az oldal az Internet Explorer, Netscape Navigator (NEM Netscape 6) és Opera böngészõk legújabb verzióihoz készült, JavaScript-et, sütiket, Flash-t és felugró ablakokat használ.
Ha még a képernyõméretet is kikötötték volna, akkor lenne csak abszolút tökéletes! Ez az oldal egy újabb dologgal bõvíti a listát. Teljesen megfeledkeztem a felugró ablakokról. Tekintettel a felugró ablakok manapság túlburjánzó használatára, valamint az ezeket blokkoló alkalmazások elterjedtségére elmondhatjuk, hogy egy szabályszerûen elkészített webhely nem alapulhat rájuk. Persze vannak dolgok, amiket csak JavaScripttel vagy egyéb nem HTML technológiával tudunk elvégezni. Nos én nem akarok senkit lebeszélni egy következõ Google Maps vagy YouTube megalkotásáról, ha tényleg ahhoz lenne kedve. Csak
7
R01.qxd
4/2/2009
8
12:50 PM
Page 8
Refactoring HTML
azt akarom mondani, hogy próbáljuk a minimumra szorítani a különleges trükkök használatát, és törekedjünk inkább arra, hogy mindent meg tudjunk oldani a Java/JavaScript/Flash és hasonló technológiák nélkül. Ez a Fickr üzenet már sokkal kevésbé elszomorító: A Flickr összes lehetõségének eléréséhez engedélyezheti böngészõjében a Javascript használatát és telepítheti a Macromedia Flash Player legújabb verzióját.
A legfontosabb különbség ezen az oldalon az volt, hogy annak ellenére is meg tudtam nézni a tartalom engem érdeklõ részét, hogy le volt tiltva a JavaScript és a Flash. Ugyan nem láttam mindent és nem értem el minden funkciót, de nem voltam kirekesztve. Ez egyaránt sokkal barátságosabb a felhasználók és a keresõmotorok – például a Google – számára is. Mint webfejlesztõ, esetleg vethetnék egy második pillantást is az oldalra, hogy lássam, nem lehetne-e eltávolítani néhány további, a klienssel kapcsolatos megkötést is. De hát ez úgysem az én feladatom.
Szimat: Cégünk honlapja egyszer csak közli: „Pwned by Elite Doodz” A webhely arculatának átírása (deface) olyan figyelmeztetõ jel, ami igen hamar felkelti mindenki figyelmét. Több oka is lehet annak, ha ilyesmi történik, de messze a legelterjedtebb a rosszul megtervezett ûrlapfeldolgozó szkriptek ellen intézett kódbefecskendezésen alapuló támadás. Õszintén mondom, ha csak annyi történik, hogy defészelik a webhelyünket, szerencsések vagyunk és köszönetet mondhatunk a támadónak, hogy otthagyta üzenetét. Súlyosabb támadás esetén titkos adatokat lophatnak el tõlünk, vagy fontos információkat törölhetnek a rendszerbõl.
Szimat: A Google elõször a 17. oldalon említi webhelyünket A webhelyek újratervezésének egyik legfontosabb indítéka az úgynevezett keresõmotor optimalizáció. A keresõmotorok mindenekelõtt a szöveget értékelik, csak azután a képeket, az elõbb felbukkanó szöveg pedig fontosabb számukra, mint az utána következõ. A táblázatokon alapuló formátumokat nem értik meg, és nem sokat törõdnek a sütikkel vagy a JavaScripttel sem. Ugyanakkor nagyon szeretik az egyedi címeket és ha lehet, még inkább a meta címkéket (meta tag-eket).
Szimat: A látogatók e-mailt küldenek, hogy a webhelyünk nem mûködik Ez az egyik legjobb módja annak, hogy felfigyeljünk a problémákra. Például legutóbb a következõ levelet kaptam egyik olvasómtól: A Tejeskávé weblapon a "További olvasnivalók" rész "A következõ nagy nyelv?" és "HopStop tesztelése" hivatkozásai nem mûködnek. Üdvözlettel Kent
R01.qxd
4/2/2009
12:50 PM
Page 9
1. fejezet • Újratervezés Ez igencsak meglepett, mert a Kent által reklamált rész egy másik weboldalról származó Atom hírforrás XSLT-vel automatikusan generált transzformációja. Megvizsgáltam a hírforrást és rendben találtam. Mindamellett Kentnek is igaza volt, a link tényleg nem mûködött. Alaposabban utánajárva a dolognak végül is egy hibára bukkantam az XSLT stíluslapon. Egy olyan elemet olvasott be, amely rendszerint, de nem mindig ugyanaz volt, mint a link, és nem azt az elemet, ami valóban a link volt. Öt perccel késõbb az oldal újra mûködött. A látogatók 99 százaléka persze hiba esetén egyszerûen továbblép és soha nem fogja közölni velünk, hogy a weboldalunk nem mûködik. A maradék 1% viszont aranyat ér. Törõdjünk velük, hallgassuk meg, mit mondanak. Ne nehezítsük meg a dolgukat, tegyünk meg mindent, hogy könnyen elérjenek bennünket. Minden webhelynek, sõt akár minden weblapnak kell egy felelõs személy, akivel probléma esetén kapcsolatba lehet lépni. A reagálásokat vegyük komolyan és cselekedjünk hamar. A látogatók sok egyéb levelet is küldhetnek, amelyek nem kapcsolódnak közvetlenül a webhelyhez: rendelés lemondása, szállítási idõpontok, kapcsolatok kérése, politikai nézeteltérés, és ezer más dolog. Képesnek kell lennünk megkülönböztetni a technikai problémákat a nem technikai jellegûektõl, hogy a megfelelõ irányba továbbíthassuk. Vannak oldalak, amelyek online ûrlapon kérik a felhasználót, hogy írja le a problémát. Ez eléggé megbízhatatlan, mivel a felhasználók rendszerint nem a fejlesztõ szemével nézik a weboldalt, másképp gondolkodnak. Ha például egy megrendelõ a szállítási cím nevû ûrlapon nem tudja kötõjelesen begépelni kilencjegyû irányítószámát, akkor mi magunk hiába azonosítjuk az efféle dolgokat valamiféle mûszaki hibaként (mellesleg valószínûleg helyesen), a megrendelõ esetleg azt fogja hinni, hogy ez egy szállítási probléma, és a kérdését a cég egy olyan részlegének teszi fel, ahol nem is értik majd, hogy mirõl beszél, és persze fogalmuk nem lesz, hogy mihez kezdjenek vele. Szükségünk lehet egy olyan személyre, vagy csapatra, aki megvizsgálja a levelek tartalmát és eldönti, hogy a szervezetben ki az az illetékes, aki válaszolni tud rájuk. Ez egy olyan kulcsfontosságú feladat, amit soha nem szabad kiadni olcsón dolgozó külsõsnek. Bármit is teszünk, ezeket a hibajelentéseket soha ne dobjuk abba a fekete lyukba, amit ügyfélszolgálatnak hívnak. Gyõzõdjünk meg arról, hogy a hibaelhárítást elvégezni tudó emberek közvetlenül a webhely felhasználóitól kapják meg a visszajelzéseket, és érdemben foglalkozzanak is ezekkel. Túl sok webhely használ e-mailt, kapcsolati ûrlapokat és tûzfalfejlesztõket arra, hogy megakadályozza a felhasználókat a kapcsolatfelvételben. Ne essünk ebbe a csapdába. A webhelyek üzemeltetõi sok-sok pénzért alkalmaznak minõségbiztosítással foglalkozó csapatokat (Quality Assurance; QA ). Ha az emberek önként megteszik ezt értünk, legyünk hálásak érte és használjuk ki a lehetõséget.
9
