Programování webových stránek

V návaznosti na text s jehož obsahem souhlasím, ale jeho umístění již zřejmě nedohledám, jsem se rozhodl napsat jeho volné doplnění. Text se týkal postupu tvorby webových stránek, a v podstatě navazoval na mnoho jiných doporučení Jana Řezáče, autora knihy Web ostrý jako břitva. Tento článek je více o technologiích a vlastně se dá aplikovat na libovolný programátorský projekt.

Názorové zařazení autora

Než se pustím do samotného textu o programování webu, rád bych upřesnil svou pozici v názorovém proudu. Knihu Web ostrý jako břitva vlastním. Přečetl jsem ji takřka na jediné nadechnutí. Když jsem ji četl, s některými kapitolami jsem absolutně souhlasil a říkal si, přesně, na to jsem přišel také. U jiných kapitol jsem si říkal, že by mě nenapadlo že to tak je, ale vlastně jsem si to jen neuvědomil. Snad jediná věc, se kterou obecně nesouhlasím je cena. Ano je moc fajn, že Jan Řezáč v podstatě nevědomky zavedl pojem luxus do tvorby webu. Protože upřímně řečeno, spolupracovat s Janem Řezáčem je pro spoustu majitelů stránek luxus.

Na druhou stranu, souhlasím, že tvorba webových stránek je komplexní zdlouhavý proces, na jehož konci může být i zjištění, že vlastně žádné webové stránky nejsou potřeba.

Technologie na začátku nebo na konci procesu

Teoreticky je naprosto jedno, jaká technologie je zvolená k tvorbě stránek. Ve skutečnosti to ale není tak úplně pravda. V některých případech existují různá omezení, jenž technologie přímo či nepřímo diktují. Zde jsou:

• Technologie, používaná klientem. Může se stát, že z nějakého důvodu, často proto, že šikovný prodejce vymámil peníze z nezkušených, používá klient nějaké technologie, na které je třeba se napojit. Jedním takovým příkladem může být interní systém, do nějž je zapotřebí zapojit právě webové stránky. A ne vždy lze tento systém obejít dávkovým zpracováním.

• Webové stránky poběží na serveru, který má z nějakých absolutně hloupých důvodů technické limity z pravěku. Například hostingová firma neumí provozovat některé technologie, nebo zná jen některé verze technologií atd. Kompetentnost takové firmy může i nemusí být zjevná. Obecně bude ale hosting PHP stránek jinak ohodnocený, než hosting C#, Javy, nebo nějakého C++ modulu.

• A konečně se může stát, že technologie je omezená použitím, například koncovým zařízením. Pokud 90% stávajících i budoucích zákazníků používá IE verze 6.x tak se tomu výsledek prostě musí přizpůsobit.

Mezi vysloveně technologické omezení však patří ale také to finanční. Cena C# programátora je jiná než Python programátora, a ta je jiná než PHP programátora. A druhým aspektem je také to, jaké kvality dosahuje průměrný C# programátor, jaké Python a jaké PHP programátor. Některé weby se sice jednou napíší a konec, jiné je ale třeba neustále vylepšovat, udržovat a opravovat. A cena za kvalitního programátora může být výrazný argument pro volbu technologie. K ceně je také nutné připočítat případné dovybavení programátora. Zvolená technologie může vyžadovat nákup specifických vývojářských licencí.

Obecně se dá asi říci, že technologie by neměla vnášet do projektu limity. Tedy sice je vhodné pracovat s technologií rozšířenou, udržovanou a takovou, s níž mají programátoři hodně zkušeností, to ale neznamená, že je primární volbou.

Teď se to možná mnohým nebude líbit, ale PostgreSQL opravdu není vše-spásná. Na některé projekty se prostě hodí DB s referenční integritou, na některé je lepší NoSQL přístup. Některé vyžadují PostgreSQL, na některé stačí bohatě MySQL a jiné pokud vůbec nějakou DB potřebují, stačí jim SQLite. Technologie by se tedy měla vybírat až podle logiky aplikace, tedy webových stránek. Tedy, technologii určuje aplikace a její chování, nikoli obráceně!

Důležitá je specifikace

I kdyby jste považovali Kanban nebo Scrum za sprostá slova, buzzwords atd, zapomeňte na to, že specifikace je daná. I kdyby nakrásně existovaly perfektní uživatelské testy, odzkoušené prototypy, až čas ukáže, zda jsou prototypy opravdu pohodlné k práci. Až reálné každodenní užívání nějaké aplikace přinese hodnotnou zpětnou vazbu. A to je čas na změnu. Programátor se tedy nesmí opřít o absolutně pevnou specifikaci. Resp. případná změna kódu musí být možná za rozumně vynaložené úsilí. Toto platí ve všech částech vývoje. Je proto třeba aplikaci psát tak, aby ji bylo možné rozumně rozšířit, nebo některé části vyměnit. Nikoli ale tak, aby byla aplikace rovnou připravená na něco, co nikdy nepřijde. Je to o vyváženosti.

A právě pro to, je důležité, aby byl programátor přímo účasten rozhodnutí, kterým směrem se vydat. Právě proto, je důležité, aby programátor znal kompletní kontext každé jednotlivé funkčnosti. Bude totiž připraven. Mimo jiné právě proto doporučuji, aby se každý programátor účastnil uživatelských testů. Jednak ho to naučí akceptovat jiný názor, ale hlavně bude připraven na další rozvoj směrem k uživateli.

Docela zajímavý je i způsob vytváření prototypu / specifikace. Na jednu stranu, by měl být designér (ano tak se jim říkalo i dřív, aplikační designér) odstíněn od technických omezení, na druhou stranu, právě když je známá technologie, může jít návrhu tzv. naproti. Je to o tom, že někdy je třeba obětovat mnoho peněz, za relativně málo muziky, jindy ale může být za málo peněz, muziky opravdu hodně. Sice to může pokřivit priority ve vývoji a odvádět pozornost, ale pokud se to dělá opatrně, může to vystřelit aplikaci o několik řádů nahoru.

Dejte vývojářům dostatek času na kvalitní práci

Snad nejčastější boj, je bohužel boj o čas. A technicky zdatnější designér, koordinátor, zadavatel může být velký problém pokud nepozná kvalitní práci programátora. Kvalitní práce je navíc měřitelná. Pozor, nejedná se o měření kvality programátora, ale jeho práce, resp. dobře stráveném čase.

• Kód, který je napsaný je čitelný. To může posoudit libovolný zkušený programátor, nebo ideálně nějaký externí člověk, který se přímo na vývoji nepodílel.

• To že je kód čitelný, znamená že neobsahuje zbytečně dlouhé funkce a opakovatelný kód. Kód který má smysl aby byl oddělený, by měl být oddělený v samostatné metodě / funkci / proceduře.

• Kód je vyváženě komentovaný. Komentáře, u jednoduchých a zřejmých operací jsou zbytečné. Ale zejména u složitých operací je důležité, aby komentář pomohl jakémukoliv následovníkovi. Je také velmi vhodné komentovat nějaké rozhodnutí. Není třeba popisovat lehký algoritmus, ale pokud není zřejmé, proč zrovna dělíme a ne odčítáme, je třeba to napsat do komentáře.

• Kód by měl být vyvážený. Není třeba hned od začátku stavět univerzální objekty a funkce. Ale výhledově by nemělo být obtížné upravit aplikaci bez zásadního přepsání.

• Hacky nemají v kódu co dělat. Čím déle v kódu hack zůstane, tím obtížněji se pak odstraní a tím složitější budou následující úpravy.

• Testy patří mezi základní vybavení kódu, stejně jako komentáře. A stejně jako by měl být vyvážený kód, měli by být i vyvážené testy. A testy by v normálu měli programátorovi trvat stejnou dobu, jako psaní kódu.

• K projektu existuje dokumentace. Tedy někde na konkrétním očekávaném místě je popsán způsob jak aplikaci zprovoznit a co je k jejímu zprovoznění potřeba.

• Způsob zprovoznění má být čistý a automatický.

• Pokud je kódem knihovna, je programátor zodpovědný za její dokumentaci. Ta by měla být generovaná z kódu, a měla by být dostačující a vždy aktuální.

Jeden ze způsobů jak otestovat dobře fungující vývoj, je zapojit nováčka do procesu. Nováček by měl nejprve číst dokumentaci, následně by měl být schopný pustit testy a nakonec aplikaci nainstalovat bez toho, aby měl vedle sebe celý den jednoho ze stávajících vývojářů. Toto je velmi důležitý krok. To že je něco obvyklé pro daný programovací jazyk, nebo systém, neznamená, že všichni kdo se podílejí na vývoji toto musí nutně ke své práci znát. To platí zejména, pokud je projekt tvořen vývojáři různého zaměření. Někdo může být DB specialista, někdo front-endář, někdo backendář. Ti všichni mohou pracovat na jednom projektu, jedné aplikaci, ale nemusí nutně znát běžné postupy toho druhého.