Jak vypadá moderní webová aplikace

Pojďme se podívat, jak může vypadat taková moderní webová aplikace. "Webová" proto, že běží v internetovém prohlížeči. Může se jednat jak o aplikaci, která je dostupná jen pro danou firmu a není dostupná pro zákazníky a stejně tak se může jednat o aplikaci, která je určená pro zákazníky a je dostupné z internetu. Výhodou webových aplikací je, že  aplikace běží v internetovém prohlížeči (což je dnes ve většině případů Google Chrome nebo Microsoft Edge), není potřeba instalace na lokálním počítači a aplikace je plně multiplatformní (to znamená, že bude fungovat v prohlížeči na operačním systému Microsoft Windows a stejně dobře bude fungovat i v prohlížeči na MacOS nebo ne Linuxu). 

Takováto webová aplikace má dnes obvykle část zvanou front-end a část zvanou back-end. Front-end se zabývá prezentační vrstvou a logikou spojenou s prezentací dat. Back-end data zpracovává a ukládá. Front-end a back-end spolu komunikují pomocí API (Application Programming Interface). Existují různé způsoby jak takové propojení mezi front-endem a back-endem vytvořit, ale dnes bude zřejmě nejčastější REST API. To je rozhraní, které využívá HTTP protokol (stejný protokol jaký používá web) a většinou formát JSON (JavaScript Object Notation). Výhodou formátu JSON je, že je snadno čitelný i pro člověka, což se hodí při testování.

Front-end se většinou programuje v JavaScriptu, často používanými frameworky jsou React, Angular a Vue.js. Front-end se dá vyvíjet i v jazyce Python nebo v  C# (framework Blazer).

Pro vývoj back-end části lze použít také JavaScript (framework Node.js), velmi často se používá  C#, Java. PHP,  nebo Python. Back-end obvykle ukládá data do databáze, přičemž rozlišujeme dva základní typy databází - SQL a NoSQL. Příkladem SQL databáze je Microsoft SQL server nebo Oracle database. SQL databáze (označované také jako relační databáze) pracují s databázovými tabulkami. Uložení dat v tabulkách předpokládá dobře strukturovaná data. NoSQL databáze používají jinou strukturu dat než tabulky a jsou mimořádně vhodné pro zpracování nestrukturovaných, rychle se měnících dat.

Zatím tedy máme popsány tyto části - front-end, back-end a databázi pro uložení dat. V praxi to může být ještě složitější, protože naše aplikace může podporovat nějaký složitější proces a potřebuje nějakou logiku, jak realizovat jednotlivé kroky procesu, jak procházet mezi jednotlivými obrazovkami. To by mohlo být řízeno back-endem nebo by to mohl určovat front-end, ale vhodnější je použít nějaký procesní engine. Příkladem takového procesního engine je třeba produkt Camunda. Procesní engine umožní relativně snadno vytvářet a upravovat implementované procesy, umí je zobrazit ve formě BPMN diagramu. 

V některých případech může aplikace obsahovat složitou business logiku, která může být hard-coded, ale je vhodnější použít decision engine (tyto systémy se označují také jako business rule management system). Decision engine umí na základě vstupu vrátit výstup, například pokud mu aplikace pošle moje osobní údaje, systém vrátí kolik mě bude stát moje životní pojištění. Tento systém má nakonfigurováno jak se jednotlivé vstupné parametry (věk, váha, místo pobytu, zaměstnání, ...) promítnou do výstupu. Také tento systém umožní provést úpravu a změnit způsob výpočtu aniž by bylo třeba složitě upravovat programový kód.

Čím začít při vývoji software?

Business zadavatel má představu, co by měl nový systém dělat a chce ho mít co nejdříve. Ale jak začít? Co třeba začít kreslit obrazovky? Stačí angažovat digitálního specialistu nebo customer journey experta a někoho, kdo ovládá UX tool v kterém lze kreslit obrazovky (setkal jsem se na projektech s Figmou a Axure, ale existuje spousta různých nástrojů). Výsledkem je nakreslená obrazovka, nebo v některých případech prototyp v kterém lze aplikaci procházet. Obrazovky, případně prototyp lze ukázat uživateli a na základě zpětné vazby od uživatele ho snadno upravit. Pak už stačí aplikaci "jen" naprogramovat... 

Vytváření obrazovek jako první krok, přináší následující rizika:

• Soustředění se spíše na design než na funkcionalitu. Návrh už často vypadá téměř jako finální aplikace a proto svádí k tomu ho "doladit" do nejmenšího detailu. V úvodní fázi je získat zásadní informace co by měl daný systém dělat. Informace, zda má být tlačítko vlevo nebo vpravo a zda má mít zelenou nebo modrou barvu není v úvodu projektu příliš důležitá. 
• Chybějící znalost datového modelu. Obrazovku často vytváří někdo, kdo má o datovém modelu jen základní informace. To často vede k tomu, že návrh modelu neodpovídá a nelze ho použít.
• Přidávání zbytečné funkcionality. Přidat další funkcionalitu dokreslením na obrazovku je velmi jednoduché a rychlé. Svádí to k přidávání funkcionality, která se "může hodit" nebo "vypadá dobře".
• Ignorování alternativních scénářů. Obrazovky se kreslí pro jednoduchý průchod aplikací, když se vše povede. Scénáře, kdy se zákazník nemůže přihlásit, smlouva neexistuje atd. se neřeší. Ale zákazník je bude chtít řešit a to buď přímo v systému, nebo se bude kontaktovat podporu a musí existovat způsob, jak mu poskytnout pomoc. 
• Ignorování následné analýzy. Máme detailně nakreslenou obrazovku. Na obrazovce je formulář s daty a pod formulářem je tlačítko Uložit. Vývojář zpracuje událost kliknutí na tlačítko Uložit tak, že uloží všechna data z formuláře a analýzu projde je tak zběžně a nemusí si všimnout, že chování popisované při uložení může být podstatně bohatší než jen prosté uložení všech dat. 

Osobně jsem se setkal s projektem portálu pro zákazníky, kde první aktivitou na projektu bylo nakreslení jednotlivých obrazovek. Vstup zákazníka na portál začal registrací. Zákazník měl zadat jméno, příjmení  a své mobilní telefonní číslo. Pokud se mobilní telefonní číslo shoduje s telefonním číslem uvedeným na smlouvě, odešle se zákazníkovi v SMS jednorázový kód, který použije při prvním přihlášení. Bylo to jednoduché a graficky velmi pěkně provedené. Mělo to několik problémů:

• Firma vůbec neměla mobilní telefonní čísla většiny zákazníků v databázi.
• Situace, kdy zákazník má uvedené telefonní číslo, ale už ho nemůže použít (z různých důvodů - např. bylo to číslo používané v minulém zaměstnání atd.) nebyla nijak řešená.
• Stejně tak nebyla řešená ani situace, kdy zákazník nedostal z nějakého důvodu SMS zprávu s kódem.

Začít s kreslením obrazovek je podle mého názoru ve většině případů špatně. Samozřejmě existují výjimky, kdy to smysl dává - takovou výjimkou je velmi složité uživatelské rozhraní, kde jeho nakreslení pomůže k pochopení o co se jedná. Ale u většiny "standardních" systémů je dobré kreslení obrazovek odložit a začít něčím jiným. Mám na mysli sběr uživatelských požadavků a tvorbu případů užití (use case) u funkčních požadavků.

Specifikace požadavku

Dnes jsem narazil na případ nedostatečné specifikace požadavku. O co šlo? V aplikaci je možné vybrat dokumenty a stiskem ikonky s  tiskárnou je hromadně vytisknout. Tisk probíhá tak, že se dokumenty k tisku vygenerují do PDF a výsledný soubor se pošle na tiskárnu.

Co  všechno by měl analytik ověřit?

• Jaké dokumenty je možné vybrat k tisku? Lze vybrat jakýkoliv dokument, nebo lze vybírat jen dokumenty s určitými atributy (třeba dokumenty určené pro zákazníka, dokumenty typu smlouva atd.)?
• Jaké dokumenty se vytisknou (tj. vygenerují do výsledného PDF)? Všechny, nebo dokumenty s určitými atributy?
• Může hromadný tisk provádět kdokoliv, nebo jen vybraní uživatelé s určitými právy?
• Existují nějaké varianty tisku dokumentů - např. uživateli, který má omezená práva se vytisknou jen některé dokumenty, případně se vytisknou v některých případech dokumenty s anonymizovanými údaji?
• Jaká jsou pravidla pro vytváření PDF souboru pro hromadný tisk? Každý dokument bude jen v jedná kopii, nebo se mají některé dokumenty tisknout opakovaně (typicky smlouva, jejíž kopie se tiskne pro každou smluvní stranu)? Jak se mají dokumenty při tisku  řadit?  
• Má se při hromadném tisku vytisknou kromě samotných dokumentů ještě něco dalšího? Třeba přehled, jaké dokumenty se tisknou a v kolika kopiích?
• Má se při tisku do dokumentů něco přidávat? Třeba datum a čas, kdy byl vygenerován PDF soubor k tisku, jméno uživatele, který tisk zadal atd.?

Přidávání funkcionality

Dnes bych chtěl vyprávět příběh o tom, co může nastat, pokud vývojář přidá funkcionalitu. Mám na mysli funkcionalitu, která sice v analýze nebyla, ale dává smysl.

Konkrétně šlo o komponentu zobrazující seznam dokumentů. V analýze bylo popsáno, že na obrazovce bude tlačítko přidat novou verzi. Tlačítko přidat novou verzi se bude zobrazovat u dokumentů ve stavu X. Když uživatel přidá novou verzi, změní se stav dokumentu z X na Y. Kromě toho může uživatel přidávat další dokumenty a to tlačítkem přidat dokument. Přidaný dokument bude ve stavu Z.

Vývojáře napadlo, že když už má tlačítko pro přidání nové verze, mohlo by se zobrazovat u všech dokumentů. Bude to koneckonců hezčí. Takže ve výsledku měl i dokument ve stavu Z tlačítko přidat novou verzi. Vypadalo to lépe, v rámci dané komponenty to ničemu nevadilo. Tlačítko fungovalo naprosto stejně u dokumentu ve stavu Z jako u dokumentu ve stavu X. A to včetně toho, že došlo ke změně stavu na stav Y. Takže byl vytvořen nový přechod ze stavu Z do stavu Y s kterým nikdo nepočítal a nikdo se ani nezamyslel, co se stane pokud tahle situace nastane.

V dalším kroku procesu na jiné obrazovce se bude pracovat s dokumenty ve stavu X a Y. Oproti dokumentům Z mají mít dokumenty ve stavu X vyplněné nějaké další atributy se kterými se na této obrazovce počítá. Dokumenty ve stavu Y mají mít vyplněné stejné atributy jako dokumenty ve stavu X, protože vznikají z dokumentů ve stavu X nahráním nové verze. Tuhle obrazovku vyvíjí jiný vývojář a zatím je tam záhadná chyba, zpracování některých dokumentů ve stavu Y stále končí chybou...