Jak z té šílené změti frameworků a knihoven vybrat tu správnou technologii při tvorbě aplikací? Vyhraje klientovo zbožné přání, selský rozum nebo naše hrdost?
V tomto článku se pokusím rozebrat momentální technologickou situaci při tvorbě webových aplikací. V dnešním světě kompjůtrů máme velkou výhodu v možnosti vyvíjet webové aplikace nezávisle na backendu/databázi/API modulech, a tudíž se v tomto článku budeme soustředit zejména na frontend.
Na trhu s frameworky, knihovnami a různými buildícími nástroji je přehršel nových produktů, což vede programátory k neustálé změně či úplnému resetu svých dev stacků, a já se ptám: "Je to vlastně dobře?". Těžká otázka. Kvalitní vývojář by měl jít samozřejmě s dobou a neustále prahnout po nových technologiích, ale jak to uhlídat, třeba když vás je v týmu víc nebo když klient nechce platit další hodiny za testování nové technologie? Pokud jste si sem přišli pro jasnou odpověď, tak vás zklamu. Ale nahlédneme společně pod pokličku naší gastronomické šmakulády.
Spousta programátorů (včetně mě samozřejmě) se snaží učit a používat stále nové technologie a okamžitě je začlenit do vývoje. Je však správné používat vaše oblíbené řešení na aplikace, pro které se nehodí, jen proto, abyste se mohli ukájet nad vlastním neuvěřitelně moderním výtvorem? Je velmi obtížné rozhodnout, jaké řešení navrhneme pro truhláře Hoblíka z Dolních Pilinovic a jaké např. pro bankovní systém robustního korporátního kolosu. Analýza požadavků klienta je tedy základní kámen každé aplikace, a pokud se neudělá kvalitně, mnohdy může dojít k tomu, že aplikace nebude pracovat podle klientových přání nebo (špatně) vybraná technologie nebude schopná plně využít potenciál webu, který je v dnešní době obrovský (např. různé browsery, SEO atd.).
U nás se dělají webové appky jak na běžícím páse a naneštěstí (nebo naštěstí) čím víc klientů, tím rozdílnější nápady, požadavky, možnosti realizace. Taková situace nám samozřejmě neumožňuje soustředit všechnu sílu na konzumaci tisíce různých nástrojů a vývoj jednoho jedinečného a neporazitelného dev stacku. Snažíme se poctivě chytat všechny možnosti a rozdělovat podle pole působnosti. Abych byl konkrétnější, tak stejně jako Squirtle a další jeho vodní kámoši dokáží uhasit jakýkoliv požár, tak stejně pro nás například Middleman dokáže hrdě vygenerovat sadu statických stránek s podporou jazykových mutací během pár minut. Takže sbírejte, ukládejte a zbytečně neodsuzujte zdánlivě již nepoužitelné pomocníky. Nikdy nevíte, kdy se vám budou hodit!
Když se do toho ponoříme hlouběji, rozdělme si naši pajplajnu do pár základních místností, přes které se appka vydává na svou životní pouť.
Analýza požadavků
Podrobně zpracujeme všechna přání klienta, prozkoumáme wireframy či předpřipravený design a důkladně projdeme všechny funkční i nefunkční požadavky. Velmi důležitá je zejména kompatibilita webových prohlížečů, SEO, či obfuskace kódu.
Výběr konkrétní technologie / konkrétního dev stacku
Po analýze bychom měli znát všechny okolnosti, tudíž jsme připraveni sáhnout do kouzelného měšce s námi otestovanými a připravenými nástroji a vybrat konkrétní balíček. Tuto část doporučuji konzultovat s ostatními kolegy, jelikož špatné rozhodnutí by mohlo mít fatální následky.
Konkrétně u nás máme připraveno několik větších sad nástrojů jako základ pro různé typy aplikací, na kterých později konkrétní aplikaci stavíme:
- Statické stránky
- Statické stránky s podporou jazykových mutací či obsahu nějakých dynamický prvků či SEO optimalizací
- Dynamické stránky s rychlou komunikací s API rozhraním
- Neveřejné administrační firemní systémy
Samotná realizace
Implementace je jediná část, kde si můžeme dovolit používat různé novější nástroje pro menší části. Například máme vybraný základ postavený na React&Reduxu, a když potřebuju na nějaké stránce vizualizovat statistická data v podobě grafů a náhodou vyjde třeba skvělá knihovna D3.js, nic mi nebrání vyzkoušet ji a začlenit do vybraného základu. (Později, pokud se osvědčí a projde schválením ostatních kolegů, může se stát součástí daného základu.)
Buildící nástroje a techniky
Můžeme mít aplikaci, která obsahuje jednu jedinou statickou stránku či robustní aplikaci obsahující komunikaci s API, spoustu dynamických prvků, grafů a spoustu dalších složitých prvků. Avšak každá aplikace musí projít build procesem, který minimálně aplikaci sestaví, optimalizuje velikost kódu (minifikace) a zamezí nežádoucímu odcizení kódu (obfuskace). Dále dokáže například překládat kód z různých programátorovi přijatelnějších jazyků do jazyka, se kterým umí následně pracovat browser (transpilace). Dnes už používáme pouze webpack, který nám umožňuje velikou škálu různých operací nad naším kódem. Více o tom, jak webpack používáme, se dočtete tady.
Testování aplikace
Testování je další místnost, kam se appka musí podívat, než se vydá do světa. Může se jednat o prohlídku a schválení výsledného produktu designérem, zkontrolování výsledků jednotkových testů kolegou či podrobný průchod předem připravených test casů.
Velmi doporučuji i průběžné hodnocení výsledků braných z chování uživatelů aplikace. Mezi naše nástroje patří analýza návštěvnosti z dat Google Analytics a zkoumání chování podle tepelných map a video záznamů z HotJAR.
Nasazení aplikace
Podle použité technologie či typu serveru, kde aplikace poběží, se liší i způsob nasazení aplikace. Jak v Ackee nasazujeme weby, se dozvíte v tomto článku.
Závěrem bych chtěl jen poradit. Dbejte na přání klienta, zohledněte své zkušenosti, používejte moderní technologie, ale nepřehánějte to! Jinak to dopadne jako nový web nejmenované zelené vzdušné banky.
