Jak jsem dělal svůj první VELKÝ web

Zhruba někdy na začátku února jsem začal dělat na projektu, o jakých jsem dřív jenom slýchával – čekalo mě kompletní překopání stránek jedné britské pojišťovácké sítě s 80 pobočkami a stovkami stránek. V pátek byly nové stránky www.coversure­.co.uk konečně spuštěny a v tomto zápisku bych se rád podělil o zkušenosti, které si odnáším.

Nejdřív něco o projektu:

• Rozsah zhruba 40 top-level stránek a pak 80 sub-webů jednotlivých poboček, každá v průměru 6 stránek (celkově cca 480 stránek poboček).
• Jsou to opravdu stránky a žádná super-funkcionalita typu webový obchod se nekoná. Online objednávky obstarává Flash, který je na zbytku webu celkem nezávislý.
• Vzhled byl daný (součástí zadání bylo, že návštěvníci nemají na oko skoro nic poznat).
• Původním záměrem bylo vylepšit HTML kód pro vyhledávače, ale když se ukázalo, že současný stav snad už ani horší být nemůže, bylo rozhodnuto celý obsah přesunout do nějakého CMS.
• Personální obsazení: projekt byl one man show
• Vyhrazená doba: 1 až 2 měsíce.

No a tady jsou v bodech mé hlavní zážitky a zkušenosti:

1. „DreamWeaver-driven development“ – tak bych nazval to, co se u nás ve firmě praktikovalo předtím. Pokud víte, že nadpis má být H1 a nikoliv obrázek, můžete se tady vydávat pomalu za SEO odborníky. Rovněž až doteď jsem považoval znalost, že fotky mají být JPEG zatímco jednoduchá grafika GIF nebo PNG, za samozřejmost, zatímco teď to považuji za skill. Chci tím říct to, že ze současného kódu stránek se nedalo použít vůbec nic. Bohužel.
2. Složitost webového vývoje. Při přechodu na CMS jsem si znovu musel uvědomit, jak je webový vývoj komplikovaný. Zde je přibližný rozsah technologií a produktů, které bylo potřeba zkrotit a donutit k poslušnosti:
   • PHP
   • MySQL
   • CMS (Drupal)
   • HTML + CSS
   • JavaScript plus nějaký framework
   • IIS na Windows 2000
   • ISAPI_rewrite
   • DokuWiki
   • regulární výrazy (málem bych zapomněl!)

   (Za pozornost stojí, že ačkoliv to jsou „jen“ obyčejné stránky, množina technologií je prakticky stejná jako u něčeho komplikovaného, třeba u e-obchodu.)

3. CMS vs. HTML. Celý projekt začal jednoznačnou ideou použít nějaký CMS. Výhody byly na snadě: vizuální konzistence díky šablonám, lepší udržovatelnost, nezávislost URL na fyzickém umístění souborů atd. atd. Všechny tyto výhody teď máme, ale přesto mám trochu nepříjemný pocit, že jsme něco podstatného ztratili – ztratili jsme jednoduchost. Z jednoduché HTTP komunikace „chci soubor xy.htm“ – „tady ho máš“ se stal komplikovaný proces, na jehož cestě stojí řada technologií a v každé z nich může být potenciálně chyba. Náš systém momentálně funguje a skutečně všechny běžné činnosti drasticky usnadňuje, ale pokud v budoucnu budeme chtít udělat nějaké zásadnější změny, už nestačí jenom koupená licence DreamWeaveru. Budou potřeba lidi s patřičnými znalostmi, bude potřeba daleko důkladnější testování atd. atd. Když se nad tím zamyslím, tohle je trochu paradox: CMS se nasazuje kvůli nižším nákladům na udržovatelnost, ale je to právě CMS, který nutně některé náklady na udržovatelnost zvýší. „Bohužel“, pro velké weby nevidím jinou cestu.
4. Drupal. Ani jednou jsem nelitoval, že jsme zvolili právě tento CMS. Nikdy se příliš nepletl do cesty a taky mě přakvapilo, jak snadno do něj šlo přidat funkcionalitu potřebnou pro rozsáhlejší web (pár dobře mířených zásahů zvýšilo jeho flexibilitu dost výrazně).

   Na druhou stranu jsem si občas říkal, že svět zatím na svůj ideální CMS čeká. Co si nalhávat – CMS je v podstatě dost primitivní záležitost, základní funkcionalita se dá napsat za pár večerů (a kupa lidí to bohužel dělá), a na to, že je v Drupalu několik let vývoje obdivuhodně velké komunity lidí, by to mohlo být lepší. Hlavní je ale jedno – Drupal svůj úkol bez problémů splnil.

5. JavaScript. Tenhle projekt byl mým úplně prvním vážnějším setkáním s JavaScriptem a musím říct, že právě při jeho psaní jsem si uvědomoval, co lidi od Ruby myslí tím „programování může být zábava“. Pokud se někdy s JavaScriptem potýkáte, určitě se podívejte na knihovnu jQuery, která i mně jakožto úplnému začátečníkovi umožnila velmi rychle psát mocný, cross-browser kompatibilní kód.

   Tip: pokud hojně používáte JavaScript, otestujte svůj web na pomalém počítači. JavaScript má problém s výkonností a čeho si na rychlé vývojářšké mašině ani nevšimnete, může normální návštěvníky dost otravovat.

6. Nástroje. Na všechny důležité úlohy byly použity zdarma dostupné nástroje, jejichž kvalitou jsem byl příjemně překvapen:
   • PDT (PHP Development Tools pro vývojové prostředí Eclipse) – z mého pohledu naprosto skvělý nástroj pro PHP vývoj. V minulosti jsem jich zkoušel hodně a Zend Studio bylo tehdy v podstatě jediným opravdu komfortním vývojovým prostředím, proto mě velmi příjemně překvapilo, že PDT zvládá v podstatě to samé. Co člověk nejvíc potřebuje je (a) doplňování kódu (v podstatě shodné se Zend Studiem, takže bez výhrad), a za (b) find in files, což v Eclipse standardně je. Jediné, co mi výrazněji vadilo, je absence zalamování řádků – to je pro editování textových dokumentů dost podstatné a bohužel je tenhle feature request už hodně dlouho oddalován, takže ani v Eclipse 3.3 se řádky zalamovat nebudou.
   • Firefox. Mnohokrát jsem si uvědomil, jak je tento browser z kodérského pohledu úplně v jiné lize než IE nebo Opera, hlavně kvůli mnoha vývojářským rozšířením. Firebug je naprostá bomba a radši si nechci představovat, jak bych některé chyby hledal bez něj.
   • HeidiSQL – velmi pohodlný administrační nástroj pro MySQL (narazil jsem taky na slibně vypadající projekt TurboDbAdmin, ale ten je zatím příliš nevyspělý)
   • Nejlepší tester regulárních výrazů, jaký jsem našel, je http://www.sol­metra.com/scrip­ts/regex/ . Nemá problém s escapováním speciálních znaků a pěkně ukazuje naplněné pole $matches.
7. Done vs „done done“. Tohle je velmi zajímavé – na 90% funkčnosti jsem se byl schopen dostat pomalu za stejnou dobu jako z 90 procent na 100. Někdy v půlce února jsem si říkal, jak jsem po pouhých 14 dnech daleko, a šéfům se to samozřejmě líbilo. Naopak za posledních 14 dní jsem neudělal skoro žádný viditelný pokrok, ale bez provedených drobných úprav by se prostě web nedal vypustit do světa. V této souvislosti mě nemohla nenapadnout kapitola z výborné (zatím nevydané) knihy The Art of Agile Development, nazvaná Done Done.
8. Business vs kvalita. Tenhle bod se mi dost špatně formuluje, proto radši příklad: hned ze začátku jsem dostal zcela natvrdo rozkaz, že nesmím optimalizovat pro různé prohlížeče. „Vyber si IE 6 nebo IE 7 a stránky připrav pro něj. Na ostatní prohlížeče kašli, normální lidé hledající pojištění tyhle prohlížeče nepoužívají.“ Na otázku „a jak to víš“ přišla očekávatelná odpověď „to prostě vím“. Sice mi to nedalo a stránky se dobře zobrazují i ve Firefoxu, ale dobře to demonstruje, že někdy pro evidentní technologické nedostatky může existovat dobrý důvod, a to šéfovo rozhodnutí. Tohle je třeba důvod, proč v Opeře blbne horní menu – nemám důvod ani povolení šťourat se v tom, proč Opera počítá šířku tohoto menu jinak. Já vím, že je to neprofesionální, ale přesně to jsem myslel oním business vs. kvalita. Update: Dal jsem si 10 minut na opravení, usoudil jsem, že čisté CSS řešení tak rychle nenajdu, a nakonec jsem to fixnul pár řádky JavaScriptu. Teď může být i zbylých 0.02% návštěvníků Coversure spokojených.

   Dalším příkladem z této kategorie jsou některé CSS nečistosti, např. u vyhledávacího formuláře je k layoutu použita tabulka. Dřív bych se s tím piplal až bych to vypiplal, ale teď musel být postup jiný: obvykle jsem si dal třeba hodinu na to, abych našel CSS řešení, a když se nepovedlo, prostě jsem to vyřešil jinak.

9. Dokumentace. Osobně považuji dokumentaci za podobně důležitou vlastnost, jako je samotná funkčnost systému, takže jsem se hned na začátku musel porozhlédnout po nějakém dokumentačním nástroji. Volba padla DokuWiki, a přesto že má toto řešení k ideálu dost daleko, považuji Wiki za jednu z nejlepších dokumentačních možností.
10. Ne vždy to byla zábava. Speciálně jsem si užíval okamžiky customizace Drupalu a JavaScriptového vývoje, ale jak se projekt posouval kupředu, přicházely na řadu nudnější a nudnější práce – bylo potřeba přemigrovat veškerý obsah (a že ho bylo!), bylo potřeba přesunout celý systém z localhostu do testovacího prostředí na sever (už poněkolikáté v životě jsem instaloval PHP a i tentokrát mě to zle potrápilo), bylo potřeba doladit kupu drobných detailů a tak. Abych byl upřímný, ke konci už jsem se docela těšil, až to budu mít z krku.
11. Release byl horor drama. Věděl jsem to od začátku – musí přijít okamžik, kdy staré stránky zhasnou a nahradí je nové. Taky jsem si uvědomoval, že ten krok s sebou nese docela hodně rizik. Když se to tak vezme, v podstatě se nejednalo o jeden projekt, ale o projekty tři: (1) Připravit a customizovat CMS, (2) Vytvořit HTML+CSS šablony a (3) Přemigrovat obsah. Každá z těhle fází s sebou nese rizika pro release: první může způsobit kompletní nefunkčnost webu, druhá může negativně ovlivnit vzhled generovaných stránek a třetí může způsobit nevoli poboček, pokud bude nějaká chyba v obsahu. Posledních zhruba 14 dní jsem byl proto právem nervózní a testoval jsem, co se dalo. Přesto nebyl release bezproblémový.

    První nápor support telefonátů přišel hned po spuštění, kdy se ozvala řada poboček s požadavky na změnu tohohle nebo támhletoho. S tím jsme ale tak nějak počítali, horší bylo, že kompletně přestalo fungovat napojení Flashe na naši databázi. Tehdy jsem si prožil určitě nejtěžších pár hodin ve své krátké kariéře a už jsme byli jen krůček od návratu ke starým stránkám, což by bylo slušné fiasko. Pak se naštěstí podařilo opravit chybu v konfiguračním souboru ISAPI_rewrite a všechno zas začalo fungovat.

    Až večer mě Hanka upozornila, že ten den byl pátek 13. Kdybych to věděl dřív, do ničeho bych se nepouštěl :)

12. Obtížnost ladění. Jen tak pro zajímavost, zde je stupnice toho, co se jak obtížně ladí. První jde nejsnáze, poslední nejhůře:
    1. čistý PHP kód – pohoda, dobrá podpora v nástrojích
    2. JavaScript – docela pohoda, když člověk používá Firebug
    3. kód Drupalu – to už jde ztuha; viděl jsem sice postupy, jak Drupal debugovat v PDT, ale většinou mi přišlo jednodušší se uchýlit k příkazu ‚print‘
    4. regulární výrazy – ty jsou asi ze zcela jiné galaxie. Absolutní chuťovka je odhadovat, co asi udělá HTTP request, když se prožene pravidly v httpd.ini nebo .htaccess souboru.

Slovo závěrem: Jsem vděčný, že jsem si mohl takhle rozsáhlý web zkusit. V jiných firmách bych možná na projektu podobného rozsahu dělal v týmu, což by mě svým způsobem ochudilo o náhled do projektu v jeho komplexnosti. Výsledek je skoro přesně takový, jak jsem si ho představoval, takže spokojenost, a dokonce ani plánovaná doba se moc neprotáhla: celé se to zvládlo skoro přesně za 2 měsíce. No a teď už se můžu těšit na další projekt, který bude tentokrát ve Flashi – myslím, že tam to bude taky velmi zajímavé.