Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky
Sdílený vývoj webového rozhraní s použitím architektury Monorepo
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika
Poděkování
Děkuji prof. Ing. Aleně Buchalcevové, Ph.D. za cenné rady a připomínky při vedení diplomové práce. Také bych chtěl poděkovat své rodině a nejbližším za jejich podporu.
Abstrakt
Diplomová práce se svým tématem věnuje sdílenému vývoji webových rozhraní a realizací těchto řešení v agilní metodě vývoje. V teoretické části jsou identifikovány nejčetnější problémy související se sdíleným vývojem webových rozhraní, a to na úrovni architektury, návrhu, vývoje a řízení softwarového projektu. V praktické části diplomové práce je následně představen rámec pro realizaci sdíleného a souběžného vývoje webových aplikací, jenž přináší řešení identifikovaných problémů.
Klíčová slova
Design systém, Monorepo, agilní vývoj, Scrum, webový vývoj, front-end
Abstract
The diploma thesis deals with the topic of shared development of web interfaces and the implementation of these solutions in an agile method of development. The theoretical part identifies the most common problems related to shared development of web interfaces, at the level of architecture, design, development and management of software projects. The practical part of the thesis then presents a framework for the implementation of shared and concurrent development of web applications, which provides solutions to identified problems.
Keywords
Design system, Monorepo, agile development, Scrum, web development, front-end
Obsah
Úvod ... 14
Cíle práce ... 14
Cílová skupina ... 15
Použité metody ... 15
Struktura práce ... 15
Předpoklady a omezení ... 16
1 Komentovaná rešerše informačních zdrojů ... 17
1.1 Akademické práce ... 17
1.2 Knižní zdroje ... 18
1.3 Odborné články ... 18
2 Rozhraní webových aplikací a sdílení funkcionalit ... 20
2.1 Webové aplikace ... 20
2.2 Uživatelská rozhraní a jejich historický vývoj ...21
2.3 Vymezení pojmů z oblasti softwarového vývoje ... 22
2.4 Vymezení pojmu modularity v oblasti front-end vývoje ... 24
2.5 Správa softwarového projektu a kontinuální integrace ... 26
2.5.1 Repositář a správa verzí ... 26
2.5.2 Sestavení ... 27
2.5.3 Kontinuální integrace ... 27
2.6 Identifikace problémů vývojových týmů v oblasti sdíleného vývoje ... 28
2.6.1 Sdílení vyvíjených funkcionalit ... 28
2.6.2 Architektura projektu sdíleného vývoje ... 30
2.6.3 Sdílená dokumentace ... 30
2.6.4 Řízení sdíleného vývoje projektů ... 31
2.6.5 Příklad problémů sdíleného vývoje ... 31
3.2 Architektura pro sdílení funkcionalit napříč projekty ... 43
3.3 Metody sdíleného vývoje a řízení projektu ... 48
3.3.1 Metoda Atomického designu ... 48
3.3.2 Component Driven Development ... 49
3.3.3 Scrum ... 50
3.4 Technologie ... 54
3.4.1 React ... 55
3.4.2 TypeScript ... 59
3.4.3 Lintovací a formátovací nástroje ... 61
3.4.4 Nx ... 62
3.4.5 Storybook ... 64
3.4.6 Material-UI ... 65
3.4.7 Express ... 66
3.4.8 Souhrn technologií a jejich podpory principů sdílení ... 66
3.5 Souhrn výstupů teoretické části ... 67
4 Demonstrace vývoje sdílených front-end funkcionalit na ukázkovém projektu ... 69
4.1 Případová studie ... 69
4.2 Definování požadavků projektu ... 70
4.3 Postup realizace projektu ... 71
4.4 Architektura projektů v Monorepu ... 72
4.4.1 Sdílené knihovny ... 73
4.4.2 Aplikace ... 75
4.5 Použití metod vývoje a řízení projektu ... 76
4.6 Plánování vývoje funkcionalit v metodě Scrum ... 81
4.7 Postup vytvoření a konfigurace projektu ... 84
4.8 Definování design tokenů ... 85
4.9 Vývoj sdílených funkcionalit ... 87
4.9.1 Vytvoření sdílené komponenty ... 87
4.9.2 Použití principů FIRST při vývoji komponent ... 91
4.9.3 Umístění sdílené komponenty do Storybook ... 105
4.10 Demonstrování vlastností architektury Monorepo ... 109
4.10.1 Konfigurace projektů ... 109
4.10.2 Sdílení funkcionalit mezi projekty ... 110
4.10.3 Vlastnictví a závislosti projektů ... 112
4.10.4 Graf závislostí projektu ... 114
4.11 Souběžný vývoj aplikací ... 117
4.11.1 Rozšiřování funkcionality ... 119
4.11.2 Scrum of Scrums ... 120
4.11.3 Changelog ... 121
4.12 Shrnutí a zhodnocení realizace případové studie ... 122
Závěr ... 125
Použitá literatura ... 128 Přílohy ... I Příloha A: Příkazy pro vytvoření základní struktury repositáře ... I Příloha B: Naklonování repositáře, sestavení a spuštění obsažených aplikací ... III
Seznam obrázků
Obrázek 1: Příklad opakujících se prvků rozhraní napříč aplikacemi (vlastní zpracování) 25 Obrázek 2: Rozdíly v podobě rozhraní produktů společnosti Spotify v roce 2012 (Wood
2016) ... 29
Obrázek 3: Sjednocená podoba rozhraní aplikací společnosti Spotify (Pullen 2015) ... 29
Obrázek 4: Souběžný vývoj dvou produktů s překryvem funkcionalit (vlastní zpracování) ... 33
Obrázek 5: Příklad komponenty tlačítka a možných variant v design systému (Oliveri 2020) ... 36
Obrázek 6: Hodnoty barev v grafickém manuálu a jejich převedení do design tokenů (Capozzi 2021) ... 37
Obrázek 7: Sdílení vyvíjeného rozhraní napříč mezi projekty, dle podkapitoly 2.6 Příklad problémů sdíleného vývoje (vlastní zpracování) ... 40
Obrázek 8: Nejčastější důvody pro realizaci vlastního design systému, 350 respondentů (Hamilton a Researcher 2020) ... 41
Obrázek 9: Úrovně zralosti design systému (Somers 2017) ... 42
Obrázek 10: Izolované projekty architektury Multirepo a samostatné konfigurace (vlastní zpracování) ... 45
Obrázek 11: vyobrazení jednotlivých přístupů architektur repositářů (G 2019) ... 46
Obrázek 12: Úrovně komponent Atomického designu (Frost 2016) ... 49
Obrázek 13: Srovnání popularity knihoven React, Angular a Vue (npm trends 2021a) ... 59
Obrázek 14: Upozornění na chybu pomocí typové kontroly statického typování jazyka TypeScript (vlastní zpracování) ... 60
Obrázek 15: Chybová hláška typové kontroly při použití objektového typu (vlastní zpracování) ... 60
Obrázek 16: Srovnání popularity knihovny TypeScript, Flow a CoffeeScript (npm trends 2021d) ... 61
Obrázek 17: Nasazení izolované komponenty ve Storybooku (Zdroj: vlastní zpracování) . 65 Obrázek 18: Použití existujícího design systému a jeho rozšíření (vlastní zpracování) ... 66
Obrázek 19: Členění projektů a příslušných týmů (vlastní zpracování) ... 70
Obrázek 20: Architektura projektů a jejich závislostí v Monorepo (vlastní zpracování) ... 72
Obrázek 21: Dodaný návrh uživatelského rozhraní (vlastní zpracování) ... 76
Obrázek 22: Návrh prvku Karta výsledku (vlastní zpracování) ... 78
Obrázek 23: Návrh prvku List karet výsledků (vlastní zpracování) ... 78
Obrázek 24: Diagram rozpadu UI prvků na komponenty (vlastní zpracování) ... 80
Obrázek 25: Postupná kompozice atomických prvků do podoby uživatelského rozhraní (vlastní zpracování) ... 81
Obrázek 26: Ukázka úkolů, definovaných v nástroji JIRA (vlastní zpracování) ... 83
Obrázek 27:Ukázka definované barevné palety, která má být použita při vývoji aplikace (vlastní zpracování) ... 85
Obrázek 28: Ukázka chyby typové kontroly při nepoužití povinné vlastnosti komponenty (vlastní zpracování) ... 88
Obrázek 29: Návrh rozhraní komponenty MovieSearchWithResults (vlastní zpracování) 92 Obrázek 30: Dekompozice prvků rozhraní do komponent Atomické designu, pomocí metody CDD (vlastní zpracování) ... 94
Obrázek 31: Návrh rozhraní komponenty SearchField (vlastní zpracování) ... 101 Obrázek 32: Diagram rozpadu UI prvků na komponenty, rozšířený o testování (vlastní zpracování) ... 105 Obrázek 33: Ukázka vyvinuté komponenty CardItem umístěné ve Storybook (vlastní zpracování) ... 106 Obrázek 34: Dokumentace komponenty Button ve Storybook (vlastní zpracování) ... 107 Obrázek 35: Rozšiřující konfigurace projektů v Monorepo (vlastní zpracování) ... 109 Obrázek 36: Provedení operací lintovacího nástroje pouze nad dotčenými částmi repositáře (vlastní zpracování) ... 115 Obrázek 37: Graf závislostí a propagace změn v projektu (vlastní zpracování) ... 116 Obrázek 38: Porovnání délky doby sestavení, nahoře kompletní sestavení, dole izolované sestavení (vlastní zpracování) ... 117 Obrázek 39: Dokončené MVP obou souběžně vyvíjených aplikací (vlastní zpracování) ... 119 Obrázek 40: Vizualizace ceremonie Scrum of Scrums (Hall 2018) ... 121
Seznam tabulek
Tabulka 1: Definované cíle projektů v případové studii ... 71
Tabulka 2: Popis komponenty Karta výsledku ... 77
Tabulka 3: Popis komponenty List karet výsledků ... 79
Tabulka 4: Karta komponenty Vyhledávání výsledků ... 79
Tabulka 5: Dílčí úkoly, které jsou součástí funkcionality MOVIES -13, určené k vyhledávání filmů ... 82
Tabulka 6: Dílčí úkoly, které jsou nezbytné k vytvoření a konfiguraci projektů ... 83
Tabulka 7: Popis karty komponenty Vyhledávací pole ... 102
Tabulka 8: Úkoly týmu B pro první sprint ... 118
Tabulka 9: Popis rozšířené komponenty Karta výsledku ... 120
Tabulka 10: Cíle případové studie a jejich naplnění ... 122
Seznam výpisů programového kódu
Výpis 1: Ukázka kódu stavové komponenty (vlastní zpracování) ... 55
Výpis 2: Ukázka komponenty s definovanou vlastností (vlastní zpracování) ... 56
Výpis 3: Ukázka komponenty napsané formou třídy (vlastní zpracování) ... 57
Výpis 4: Vytvoření znovupoužitelné logiky prostřednictvím React Hooks (vlastní zpracování) ... 58
Výpis 5: Ukázka znovupoužití vytvořeného Hooku v jiné komponentě (vlastní zpracování) ... 58
Výpis 6: Ukázka dynamického typování jazyka JavaScript ... 59
Výpis 7: Definice pravidel pro použití znaků uvozovek a odrážek v Eslint (vlastní zpracování) ... 62
Výpis 8: Základní příkazy pro vytvoření projektů v Nx Monorepo ... 84
Výpis 9: Základní design tokeny definované v konfiguraci knihovny Material-UI (vlastní zpracování) ... 86
Výpis 10: Použití konfigurace s design tokeny v ThemeProvider (vlastní zpracování) ... 86
Výpis 11: Definice rozhraní (typu) komponenty a jeho přiřazení komponentě (vlastní zpracování) ... 88
Výpis 12: Znovupoužití definované typu v BE aplikaci, dosažené architekturou Monorepo (vlastní zpracování) ... 89
Výpis 13: Ukázka kódu komponenty CardItem (vlastní zpracování) ... 90
Výpis 14: Ukázka definice stylů pro komponentu CardItem (vlastní zpracování) ... 91
Výpis 15: Ukázka komponenty porušující principy FIRST ... 93
Výpis 16: Rozhraní (typ) komponenty SearchField (vlastní zpracování) ... 95
Výpis 17: Ukázka komponenty SearchField (vlastní zpracování) ... 96
Výpis 18: Ukázka opakovatelnosti komponenty CardItem (vlastní zpracování) ... 98
Výpis 19: ... 98
Výpis 20: Generické řešení CardList pro opakující se komponentu CardItem (vlastní zpracování) ... 98
Výpis 21: Rozšíření rozhraní komponenty CardItem o volitelnou vlastnost (vlastní zpracování) ... 99
Výpis 22: Příklad nečisté a čisté funkce (vlastní zpracování) ... 99
Výpis 23: Komponenta SearchTemplate, napsaná jako čistá funkce (vlastní zpracování) ... 100
Výpis 24: Definice skupiny jednotkových testů v Jest ... 102
Výpis 31: Upřesňující konfigurace lintovací nástroje Eslint pro aplikaci React (vlastní
zpracování) ... 110
Výpis 32: Postup v architektuře Multirepo – vytvoření symlinku a následná aktualizace knihovny při změně (vlastní zpracování) ... 111
Výpis 33: Import komponenty z externí knihovny a její použití v Multirepo ... 111
Výpis 34: Import komponenty v Monorepo (vlastní zpracování) ... 111
Výpis 35: Definice vlastnictví v Code Owners (vlastní zpracování) ... 113
Výpis 36: Definice závislostí aplikace Movies App prostřednictvím tagů (vlastní zpracování) ... 114
Výpis 37: Spuštění operace provedení jednotkových testů a sestavení dotčené aplikace (vlastní zpracování) ... 116
Výpis 38: Zaznamenávání změn projektu v changelogu (vlastní zpracování) ... 122
Seznam zkratek
DP Diplomová práce
SSOT Single source of truth - Jednotný zdroj pravdy DRY Don’t repeat yourself - „Neopakuj se“
SoC Separation of concerns - Oddělení zodpovědností
KISS Keep it short and simple - „Zachovej to krátké a jednoduché“
MVP Minimum viable product – Minimální životaschopný produkt SPA Single Page Application - Jednostránková aplikace
UI User interface – uživatelské rozhraní
FE Front-end
BE Back-end
HTML Hypertext Markup Language
CSS Cascading Style Sheets – Kaskádové styly JSON JavaScript Object Notation
REST Representational State Transfer API Application Programming Interface HTTP Hypertext Transfer Protocol
Úvod
Oblast webového vývoje zažívá v posledních letech dynamický rozvoj, jenž silně souvisí s rozvojem technologií a tím i vznikem pestré škály zařízení, umožňujících konzumaci uživatelského obsahu. Neustálým vývojem prochází technologie i knihovny jazyka JavaScript, který má aktuálně majoritní podíl na poli moderních webových aplikací.
Výraznými změnami prochází také oblast řízení softwarových projektů. Stále častěji dochází k nasazení agilních metodik vývoje, které umožňují kontinuální dodávání softwarového produktu a zkracují zpětnovazební křivku mezi vývojáři a vlastníkem produktu.
V moderních webových aplikacích také stále častěji dochází k potřebě dodržení konzistence, a to jak vůči organizaci a její identitě, tak napříč širokým portfoliem vyvíjeným aplikací.
Stále častěji dochází k souběžnému vývoji aplikací, které jsou z důvodu široké podpory zařízení, vyvíjeny často pro různé platformy, za pomocí odlišných nástrojů a technologií.
Takovéto aplikace pak zpravidla sdílí návrh uživatelského rozhraní a způsob implementace dílčích funkcionalit.
Konzistence softwarového vývoje aplikací je možné dosáhnout za pomocí široké škály nástrojů a postupů. Konzistentní softwarový vývoj zaručuje shodu jak na úrovni návrhu uživatelského rozhraní, tak i v případě samotné implementace funkcionalit a s tím souvisejícím sdílením aplikačního kódu napříč projekty. Postupy, jež jsou opakovatelné a které je možné opětovně využít i v dalších vyvíjených produktech, pak lze označit za sdílené. V diplomové práci jsou představeny nejčastější problémy související s paralelním vývojem webových aplikací a součinností softwarových týmů.
Cíle práce
Hlavním cílem práce je tvorba rámce pro realizaci sdíleného a souběžného vývoje webového rozhraní, jenž je postaven na principech opakovatelnosti, znovupoužitelnosti a konzistence napříč projekty, a to při použití agilní metodiky vývoje, jenž je přizpůsobena specifickým potřebám projektu webového rozhraní, které je sdíleného mezi jednotlivými vývojovými týmy. V úvodu práce jsou identifikovány základní problémy v oblasti sdílení vyvíjených funkcionalit napříč projekty, a to na úrovních vývoje, softwarové architektury a řízení softwarového projektu. V praktické části je pak na základě získaných poznatků vytvořen rámec pro tvorbu sdílených webových aplikací a vytvořeny šablony softwarového projektu.
Hlavní cíl je práce je rozložen do následujících dílčích cílů:
DC1 Identifikace problémů a nedostatků v oblasti sdílení vývoj webových rozhraní DC2 Výběr a popis metod vhodných pro oblast sdíleného vývoje
DC3 Výběr a popis technologického řešení architektury, umožňujícího sdílení vyvinutých funkcionalit projektu
DC4 Tvorba rámce pro realizaci a dokumentaci projektu s využitím zvolených metod vývoje sdíleného webového rozhraní a řízení projektu
DC5 Realizace projektu s využitím vytvořeného rámce a technologiemi odpovídajícím charakteru sdíleného projektu
DC6 Praktické demonstrování výhod vytvořeného rámce a ověření definovaných vlastností
Cílová skupina
Cílovou skupinou diplomové práce jsou především jednotlivci a softwarové týmy, řešící problém rostoucí funkcionality vyvíjené webové aplikace, u které dochází k potřebě sdílení daných funkcionalit mezi týmy a pro které se stává užití běžných technologií a postupů neflexibilním. Současně je práce přínosná pro všechny čtenáře, zajímající se o moderní postupy v oblasti vývoje webových rozhraní a specifik s tím se pojících. Diplomová práce přináší rámec pro řešení nejčastějších problémů, se kterými se tým, popřípadě více týmů potýkají v případě souběžného vývoje aplikací.
Použité metody
K informovaní o aktuálním stavu v oblasti vývoje webových rozhraní a oblasti webových technologií jsou jako informační zdroje užity odborné práce a studie. Pro vývoj sdíleného systému prvků uživatelského rozhraní, označované pojmem design systém, je užita kombinace metod Atomického designu a Component Driven Development. Atomický design je metoda určená pro návrh a vývoj znovupoužitelných systémů komponent, nazývaného design systém. Component Driven Development je metoda specificky zaměřená na postupy při vývoji webových rozhraní, založená na principu komponent. Samotná implementace design systému v prostředí je pak řízena prostřednictvím agilní metody vývoje Scrum, přizpůsobené jednak charakteru projektu sdíleného mezi týmy a také specifickým potřebám technologií, které umožňují sdílení vyvíjených funkcionalit.
Struktura práce
rámec je realizován v agilní metodě vývoje Scrum, která je přizpůsobena potřebám daného projektu. V případové studie je provedena aplikace rámce pro sdílení funkcionalit v reálném projektu a následně jsou demonstrovány výhody pojící se s užitím daného rámce a současně je provedeno porovnání s projektem, využívajícím konvenční způsoby vývoje a agilního vývoje.
Předpoklady a omezení
Práce předpokládá základní znalosti a zkušenosti s vývojem jednostránkových webových aplikací. Ke studiu oblasti vývoje webových aplikací a s tím souvisejících technologií a knihoven jazyka JavaScript je vhodné využít některou z odborných prací, jež jsou uvedeny v kapitole komentovaná rešerše (kapitola 2). Diplomová práce omezuje analyzovanou a popisovanou oblast sdílení vyvíjených funkcionalit specificky pro oblast vývoje webových rozhraní, označovaném také jako front-end vývoj. Cílem práce je vytvoření rámce pro oblast vývoje front-end a tématem práce již není vývoj na straně serveru, jenž je označován pojmem back-end. Práce se také svým tématem nezaměřuje na realizaci řízení škálovatelného vývoje aplikací, ve smyslu zvyšování rozsahu zdrojů projektu při realizaci vývoje. Předpokládaným výstupem práce je rámec umožňující sdílení funkcionalit mezi agilními týmy a v omezeném rozsahu, odpovídající spíše charakteru menších projektů, pro které je určena zmiňovaná metoda Scrum. K řízení vývoje rozsáhlých a komplexních řešení jsou určeny škálovatelné agilní metody, mezi které se řadí například Less, SAFe. Uvedené metody nejsou tématem této práce.
1 Komentovaná rešerše informačních zdrojů
K nalezení odborných prací a knih, zaměřujících se na oblast vývoje webových rozhraní a obecnějšího vývoje webových aplikací je využit volně dostupný vyhledávač odborných článků Google Scholar a vyhledávač vysokoškolských kvalifikačních prací Theses. Odborné knihy související s tématem realizované diplomové práce pak jsou nalezeny za pomocí vyhledávače Google Books. Při vyhledávání příslušných prací byly využity následující výrazy:
• Webové aplikace
• Uživatelská rozhraní
• Design systém
• Agilní vývoj
• Monorepo
1.1 Akademické práce
Josef Draslar ve své diplomové práci Architektura moderních jednostránkových webových React aplikací (Draslar 2018), představuje oblast moderního vývoje webových aplikací.
V práci je navržena architektura webové aplikace v knihovně React, není zde ovšem brán zřetel na sdílení funkcionalit vyvíjených aplikací ani na metody řízení sdílených softwarových projektů. Vzhledem k rapidnímu vývoji oblasti webového vývoje, tato práce již také nezachycuje problematiku architektury webových aplikací příliš aktuálně.
Jakub Kašpar ve své práci Návrh zlepšení uživatelského prožitku systému InSIS VŠE dle metodiky Google Ventures Design Sprint (Kašpar 2019), popisuje pojem design systém a v práci je představena metoda pro návrh uživatelského rozhraní Design Sprint, které je v této práci užita pro fázi návrhu webové aplikace. Práce se soustřeďuje na návrh uživatelského rozhraní v agilním prostředí a představuje metodu návrhu Atomického
Michael Hubený ve své práci Škálování agilního vývoje (Hubený 2018) přináší mnoho užitečných poznatků z oblasti škálování metod agilního vývoje a organizace týmové práce mezi vícero projekty, popřípadě produkty. Práce se ovšem soustřeďuje především na oblast řízení projektů, nikoliv na dílčí oblasti návrhu a vývoje a nezaměřuje se na oblast vývoje webových rozhraní a technologií s tím spojených.
1.2 Knižní zdroje
Ve zdrojích české literatury prakticky neexistují odborné práce, zaobírající se primárně tématem sdílení funkcionalit a souběžného front-end vývoje ani architektury a technologií se s tímto pojící. V zahraniční literatuře se tomuto tématu přibližuje kniha Frontend Architecture for Design Systems: A Modern Blueprint for Scalable and Sustainable Websites, autora Micah Godbolta (Godbolt 2016). Kniha byla ovšem napsána v roce 2016, vzhledem k rapidnímu vývoji na poli webových technologií posledních let tak kniha již nezachycuje danou problematiku příliš akurátně a některé části realizace softwarového projektu jsou zde popsány poněkud dogmaticky, se zaměřením na konkrétní technologické řešení a specifika projektu. Z knihy tak je čerpáno především na teoretické úrovni a z kapitol popisujících technologicky agnostická řešení, která lze aplikovat na libovolný projekt webové aplikace.
Jedním ze zásadních knižních zdrojů pro realizaci diplomové práce je kniha Atomic Design by Brad Frost (Frost 2016). V knize je popsána metodika Atomického designu, využívaná pro návrh a následný vývoj rozhraní webových aplikací. Metoda v sobě zahrnuje principy znovupoužitelnosti a opakovatelnosti prvků a také určuje systém jejich vzájemné hierarchie.
Tato metoda je jedním z hlavních zdrojů při tvorbě rámce diplomové práce a je zakomponována v realizaci praktické části diplomové práce.
1.3 Odborné články
The Issue of Monorepo and Polyrepo In Large Enterprises (Brousse 2019) je odborným článkem, popisujícím architektury repositáře, která jsou určeny ke sdílení vyvíjených funkcionalit napříč projekty. Článek se pak konkrétně zaměřuje na oblast sdílení funkcionalit velkých společností, při kterém dochází ke sdílení mezi stovkami až tisíci samostatných softwarových projektů. Ve článku není popsáno technické řešení uvedeného problému sdílení a tématem se spíš zaměřuje na kulturu a mezitýmovou komunikaci při sdíleném vývoji funkcionalit projektů. Článek se také nezaměřuje na oblast webového vývoje, který je tématem této diplomové práce. Vzhledem k specifickému zaměření článku na problematiku velkých společností a jejich firemní kultury při sdíleném vývoji, není téma tohoto odborného článku pro realizaci diplomové práce příliš přínosné.
Z provedených rešerší informačních zdrojů vyplývá, že v českých ani zahraničních literárních zdrojích se nenachází žádná práce komplexněji se zaobírající oblastí sdílení funkcionalit mezi projekty webových aplikací ani tématem volby technologií, umožňující tento postup sdílení. Všechny zde komentované práce se zaobírají fází návrhu, ve smyslu návrhu rozhraní a jeho příslušných prvků, které je možné snadno znovupoužívat a kombinovat, případně se jedná o práce zaměřené pouze na doporučení technologií určených k realizaci vývoje webových aplikací. Absence literatury zaměřující se oblast sdíleného vývoje funkcionalit webových aplikací je tak hlavní motivací pro realizaci této diplomové práce.
2 Rozhraní webových aplikací a sdílení funkcionalit
V úvodu této kapitoly jsou nastíněna oblast webových aplikací a jejich vlastností, které jsou vhodné pro realizaci sdíleného vývoje uživatelského rozhraní. V této podkapitole je také popsán historický vývoj oblasti webových aplikací a postupně rostoucí význam realizace sdílených webových rozhraní. V kapitole jsou také vymezeny základní principy z oblasti sdíleného softwarového vývoje, které je možné aplikovat v libovolném vývoji, jejich dodržení se ovšem stává obzvláště důležitým v případě vývoje sdílených funkcionalit.
Vzhledem k tomu, že sdílení vyvíjených funkcionalit se dotýká i architektonické úrovně softwarových projektů, je nezbytné v této kapitole vymezit i pojmy týkající se správy projektu a jeho nasazení. V závěru kapitoly jsou identifikovány a popsány nejčastější problémy, pojící se s oblastí sdíleného vývoje.
2.1 Webové aplikace
Webová aplikace je aplikačním software, jenž je umístěn na vzdáleném serveru a je k němu přistupováno skrze webové rozhraní za pomocí sítě Internet (Rouse 2019). V kontextu webových technologií je nezbytné rozlišit dva zdánlivě podobné pojmy, webová aplikace a webová stránka. Pod pojmem webová stránka si lze typicky představit statický obsah, jenž je konzumován uživatelem, s tímto obsahem již ovšem nelze dále uživatelsky interagovat. Webová aplikace na druhou stranu ve své implementaci obsahuje aplikační logiku, která pokročilou uživatelskou interakci umožňuje. Rozdílem webové aplikace oproti webové stránce je tak možnost uživatelské interakce.
Webová aplikace se zpravidla skládá z klientské části, nazývané front-end a serverové části, označované back-end. V diplomové práci jsou dále tyto části také označovány zkratkami FE a BE. Klientem, zobrazujícím uživatelské rozhraní a umožňujícím uživatelskou interakci s webovou aplikací, pak je webový prohlížeč. Vývoj back-end části probíhá v široké škále programovacích jazyků, příkladem mohou být jazyky Java, Python, Ruby, PHP. Logika front-endu webové aplikace se pak váže pouze na jeden programovací jazyk, a to JavaScript.
Oblast webových aplikací se stává stále populárnější především z důvodu kompatibility napříč širokou škálou zařízení. Nativní aplikace se vážou vždy na konkrétní hardware platformu a jsou často vyvíjeny za pomocí technologií a programovacích jazyků specifických pouze pro danou platformu. Aplikace pro systém Windows jsou například vyvíjeny v programovacím jazyku C++, aplikace pro mobilní zařízení společnosti Apple využívají jazyka Swift, Android aplikace jsou vyvíjeny v jazyce Java. Webové aplikace naopak přinášejí možnost jejich spuštění na všech platformách, které disponují moderním webovým prohlížečem.
Ve článku Why Businesses Are Migrating to Web Applications? (Nehra 2019) jsou uvedeny některé z důvodů, proč společnosti a organizace stále častěji preferují vývoj webových aplikací před vývojem aplikací nativních. Prvním z důvodů je již zmiňovaná kompatibilita, webovou aplikaci lze použít na libovolném zařízení a nezávisle operačním systému.
Současně platí, že souběžný vývoj několika nativních aplikací, je mnohem nákladnější než vývoj aplikace jediné, která je spustitelná na široké škále koncových zařízeních (Nehra 2019). Kromě vlastnosti kompatibility je vývoj webové aplikace výhodnější také z důvodu snadných úprav a rozšiřování funkcionalit. Při vydání nové verze nativní aplikace musí zpravidla dojít ke stažení této nové verze a následně její instalaci, která přepíše původně používanou verzi aplikace. V případě webové aplikace dochází ovšem k distribuci samotné aplikace z produkčního serveru. V případě provedení změn v aplikaci jsou dané změny nasazeny na produkční server a následně automaticky distribuovány na konečná zařízení uživatelů neboli klienty (Nehra 2019). Takovýto přístup distribuce nové verze aplikace mezi všechny konečná zařízení je mnohem přímočařejší, a to jak z pohledu vývojáře, tak i uživatele.
Oblíbeným tématem posledních let jsou pak jednostránkové aplikace (SPA – Single Page Application). Historicky se ve webových aplikacích nacházela převažující část aplikační logiky v serverové části aplikace, s příchodem výkonných koncových zařízení, zobrazujících pokročilá, uživatelská rozhraní však docházelo k postupné přesunu aplikační logiky z BE na FE část aplikace. V jednostránkových aplikacích tak byla značná část aplikační logiky přesunuta do klientské části aplikace a komplexita serverové části aplikace se současně omezila na minimum. Právě na oblast vývoje klientské části jednostránkových aplikací a volbu technologií a volbu řešení, umožňujícího sdílení vyvinutých FE funkcionalit mezi souběžně vyvíjenými aplikacemi se zaměřuje tato diplomová práce.
2.2 Uživatelská rozhraní a jejich historický vývoj
V devadesátých létech 20. století docházelo k poměrně výraznému rozvoji a dostupnosti internetu. V té době také docházelo ke vzniku širokého množství webových stránek, pro které je typické určité uživatelské rozhraní (Murphy 2019). Zpravidla pak docházelo k tvorbě webů s nevzhledným a nekonzistentním rozhraním, tvořené weby nedodržovaly žádné zásady uspořádání prvků a pro svou dobu se tak spíše o objevování možností na poli uživatelského prožitku a sdíleného vývoje. Návrh a vývoj webové aplikace byl tehdy navíc
na klientské části aplikací. Začala tak vznikat potřeba jisté agregace a unifikace funkcionalit do celků, které by bylo možné použít napříč aplikací a uživatelským rozhraním.
Tyto celky navíc měly zaručit konzistentní chování a jednotný uživatelský prožitek napříč širokou škálou podporovaných zařízení. Vývoj uživatelských rozhraní, která byla izolována a vázána na konkrétní nativní aplikaci, vedl z hlediska uživatelského prožitku ke vzniku vzájemných nekonzistencí mezi vyvíjenými aplikacemi (Wood 2016). Komplexita těchto výzev se stala klíčovou při tvorbě moderních webových aplikacích, ve kterých mimo architektonický návrh bylo třeba navíc brát v potaz i konzistenci funkcionalit a uživatelský prožitek.
V oblasti sdíleného návrhu a vývoje rozhraní webových aplikací byl v tomto ohledu revolučním rok 2016, kdy Brad Frost vytvořil metodu návrhu rozhraní Atomický design.
Tato metoda přinesla nový pohled na postup realizace rozhraní, kdy z menších, atomických komponent jsou skládány komplexní celky v podobě šablon či stránek webu (Frost 2016).
Prvky vyvíjených rozhraní navrhovaných a vyvíjených v této metodě byly znovupoužitelné a konzistentní napříč celým uživatelským rozhraním. Metoda se záhy stala velice populární v komunitách designérů i vývojářů a je používána řadou vývojářských týmů (Fanguy 2018).
Oblast vývoje rozhraní webových aplikací je aktuálně mnohem důležitější než dříve.
V dnešní vysoce konkurenční oblasti softwarového vývoje, dochází více než kdy dříve k potřebě takového vývoje, jenž je efektivní, rychlý a dodržující vysokou úroveň kvality. Stále častěji také dochází k souběžnému vývoji několika aplikací, jakožto samostatných softwarových produktů jedné společnosti. Webové aplikace svým charakterem kompatibility napříč širokou škálou koncových zařízení tyto potřeby do značné míry podporují. Nezbytnou součástí takto vyvíjených aplikací je tak zaručení jednotnosti uživatelského prožitku a současně i dosažení kvalitního, konzistentního vývoje daných aplikací.
2.3 Vymezení pojmů z oblasti softwarového vývoje
Tématem diplomové práce je výběr technologií a postupů, umožňujících princip znovu použitelnosti vyvíjených prvků uživatelského rozhraní, při dosažení konzistence napříč projekty. Tyto vlastnosti lze klasifikovat dle principů používaných v oblasti softwarového vývoje. Zmiňované principy jsou vymezeny a popsány v následujícím textu.
Modularita
Prvním a v oblasti softwarového vývoje zřejmě nejdéle existujícím pojmem z oblasti sdílení softwarového kódu a funkcionalit je modularita. Modularita je jedním z klíčových principů softwarového vývoje již od roku 1960. Pod tímto pojmem je rozuměn proces rozdělení programu jako celku do dílčích funkcionalit programu, nazývaných moduly (Laplante 2007). Modul je následně vyvíjen jako izolovaný, znovupoužitelný prvek, který je možné využít v široké škále aplikací (Techopedia 2021). Využití principu modularity poskytuje řadu výhod, od zmiňované znovupoužitelnosti řešení, zredukování redundantního kódu, až po snížení množství opakujících se prvků kódu. Jednotlivé charakteristiky modularity je
možné dále rozdělit do takzvaných postupů a principů tvorby aplikačního kódu, které jsou uvedeny v následujícím textu.
Princip SoC
Oddělení zodpovědnosti (Separation of Concerns, SoC), je princip rozdělení softwarového kódu a funkcionalit do modulů, jejichž funkcionalita nemá žádný vzájemný překryv, případně je jejich překryv minimální. Takto rozdělené celky zahrnují jen ty funkcionality, které logicky souvisí s účelem a zaměřením daného modulu, a naopak v sobě neobsahují funkcionality, které se již nacházejí v jiných modulech (Laplante 2007).
V oblasti FE vývoje je zřejmě nejznámějším případem SoC rozdělení vývoje rozhraní webové aplikace mezi jazyky HTML, CSS a JavaScript. Tyto jazyky se vzájemně doplňují, jazyk HTML je určen k definování obsahu webové stránky, CSS definuje a modifikuje prezentační styly a pomocí jazyka JavaScript je definována aplikační logika a také je jím řízena uživatelské interakce s rozhraním. Dalším známým případem SoC může být třívrstvá architektura aplikace, ve které jsou jednotlivé části aplikace rozdělené do prezentační, aplikační a datové vrstvy. SoC je také možné vztáhnout specificky na oblast vyvíjených funkcionalit, které mají v rámci dodržení principu SoC jednoznačně definované, unikátní vlastnosti. Pojem SoC tak lze vnímat jednak z úrovně architektonické, ale také v podobě rozdělení funkcionalit a kusů kódu do menších, nezávislých celků s konkrétní odpovědností.
Princip KISS
Princip KISS (Keep it short and simple - „Zachovej to krátké a jednoduché“) je termín vyvozený z oblasti aeronautiky a návrhů konstrukce letadel. Za vznikem tohoto principu stála tvorba jednoduchých a odolných letadel, které je možné v případě poruchy snadno opravit (Krzysztof 2019). Tato myšlenka byla adaptována řadou dalších odvětí, mezi které se řadí i softwarové inženýrství. Komplexní, dlouhé funkce, psané takzvaným způsobem
„Špagetového kódu“1, jsou pro vývojáře těžko srozumitelné, a ještě hůře upravitelné a přizpůsobitelné. Myšlenka KISS tedy spočívá v co nejjednodušším návrhu řešení, kterému je snadné porozumět, lze jej jednoduše spravovat, testovat i dále modifikovat.
Princip DRY
Princip DRY (Don’t repeat yourself – „Neopakuj se“) spočívá v tvorbě menších kusů kódu,
Princip SSoT
Při vývoji funkcionalit v souladu s výše uvedenými principy je zaručena konzistence, opakovatelnost a znovupoužitelnost vyvinutého řešení i jejich celková robustnost, jelikož takto vyvinuté funkcionality je možné použít v široké škále možných případů užití. Současně ovšem musí být definován určitý postup, prostřednictvím něhož je tým o vlastnostech vyvíjených a sdílených funkcionalit informován. V případě, že jednotliví členi týmu nejsou informováni o vlastnostech sdílených funkcionalit, nelze očekávat ani korektní užití takto vyvinutých funkcionalit, v souladu s výše uvedenými principy.
Nezbytnou součástí sdíleného softwarového projektu je tak vytvoření Jednotného zdroje pravdy (SSoT – Single Source of Truth), což znamená, že vyvinutá funkcionalita je jednotně vnímána a používána napříč celým vývojovým týmem, popřípadě týmy (Treder 2019).
Princip SSoT je umožněn prostřednictvím zevrubného dokumentování vyvíjených a sdílených funkcionalit. Součástí každého sdíleného vývoje by tak měla být určité forma dokumentace, jednoznačně definující vlastnosti funkcionalit a postupů pro jejich použití.
Prostřednictvím dokumentace jsou vývojáři průběžně informováni o stavu sdíleného projektu, čímž jsou i podpořeny všechny výše zmíněné principy.
2.4 Vymezení pojmu modularity v oblasti front-end vývoje
V každém uživatelském rozhraní se typicky vyskytují opakující se prvky. Na tyto prvky lze nahlížet dvěma způsoby, a to jednak jako na prvky čistě vizuální, obsahující určité, opakující se designové vzory a jako na prvky funkční, které v sobě zahrnují logiku, která je řízená vstupem uživatele. Vizuálními prvky mohou být například tlačítka, textové vstupy, tabulky nebo formuláře. U těchto prvků je zpravidla nezbytné dodržet vizuální konzistenci v rámci jedné, případně více souvisejících aplikací, zastřešených a vyvíjených jednou společností.
Veškerá takto vyvíjená rozhraní aplikací jsou totiž součástí pomyslného ekosystému, jenž v uživatelích vytváří očekávání ve smyslu rozložení prvků rozhraní a následné interakce s těmito prvky. Funkční pohled na vyvíjené prvky rozhraní pak v sobě zahrnuje zmiňovanou interakci, koncoví uživatelé mají zpravidla předem vytvořená očekávání o průběhu uživatelské interakce, například, že do textového vstupu je možné zadávat hodnoty až po kliknutí na daný vstup nebo, že stisknutím klávesového tlačítka enter je provedeno odeslání formulářových dat na server.
Tyto dva pohledy, vizuální a funkční, pak lze přiblížit prostřednictvím příkladu aplikací, které jsou vyvíjeny společností Google. Tyto aplikace jsou součástí jednoho ekosystému a mají společné, opakující se prvky. Například v záhlaví aplikace se vždy nachází tlačítko, takzvané „hamburger menu“2, dále se zde nachází textový vstup pro vyhledávání a v pravé části záhlaví jsou umístěny odkazy na uživatelský profil a uživatelské akce. Všechny tyto prvky pak mají uživatelem dopředu očekávanou funkcionalitu, po kliknutí na zmiňované tlačítko je otevřeno postranní menu, po zadání hodnoty do textového vstupu a stisknutí
2 Hamburger menu je označení používané v oblasti uživatelských rozhraní, pod kterým se rozumí tlačítko pro zobrazení skrytého navigačního menu aplikace (Jecas.cz 2015)
tlačítka enter je provedeno vyhledávání a kliknutím na ikonu profilu se zobrazí seznam akcí, které souvisí s profilem přihlášeného uživatelem.
Obrázek 1: Příklad opakujících se prvků rozhraní napříč aplikacemi (vlastní zpracování) U takto sdílených prvků pak je nezbytné zaručit výše uvedené principy modularity, tedy princip znovu použitelnosti (DRY), jednoduchosti (KISS), zaměřenosti (SoC) a konzistence (SSoT) napříč aplikacemi. V oblasti front-end vývoje jsou tyto identifikované, opakující se prvky rozhraní označované termínem komponenta.
Komponenty
Komponenty jsou moderním principem ve smyslu návrhu a vývoje rozhraní softwarových aplikací. S využitím komponent lze dosáhnout modularity, prostřednictvím principu kompozice prvků rozhraní. V kontextu vývoje front-end aplikací pak je komponenta označení pro nezávislý prvek uživatelského rozhraní, obsahující své definované vlastnosti, které determinují vizuální prezentaci a příslušnou funkcionalitu dané komponenty (Saring 2020). Příkladem takové komponenty může být tlačítko. Komponenta tlačítko má definované vlastnosti, například o jaký typ tlačítka se jedná a jaké má mít tlačítko popisek.
Každé tlačítko má také stanovenou sadu stylů, může se jednat například o tlačítko primární, sekundární stylem nebo stylem. Na základě volby konkrétní vlastnosti typ tlačítka je tento styl následně zvolen. Současně platí, že po kliknutí na tlačítko je provedena vždy určitá akce, tlačítko tedy v sobě obsahuje funkcionalitu.
O komponentě tlačítko lze říct, že se jedná o opakující se prvek v rozhraní, nepochybně je použita v různých částech aplikace, například jako tlačítko pro potvrzení přihlášení, tlačítko pro vyhledávání, případně tlačítko pro resetování formulářových dat. Tlačítko je tedy nepochybně kandidát pro vývoj s principem DRY, tak aby bylo možné přepoužití
dokumentace by měly být základní informace o komponentě, kterými jsou stavy komponenty, její vlastnosti a definice příslušných funkcionalit. Tímto způsobem dokumentování komponent je dodržen princip SSoT.
Kompozice
Atomické, opakující se prvky uživatelského rozhraní jsou následně skládány do větších celků. Popisované tlačítko může být například součástí větší komponenty formulář, která v sobě mimo prvek tlačítka obsahuje i textový vstup. Komponenta formulář může být dále součástí šablony vyhledání záznamů, která obsahuje logiku pro získávání vyhledávaných dat z back-endu. Šablonu vyhledávání lze dále použít napříč širokou škálou webových stránek, obdobně jako v příkladu na obrázku 1. Tento přirozený postup skládání dílčích komponent do složitějších celků, je nazýván kompozicí. Výhodu kompozice pak je dodržený principu DRY, protože existující dílčí prvky, mezi které se řadí například tlačítko je možné opětovně použít i v dalších, komplexnějších komponentách. Při kompozici komponenty je třeba mít stále na paměti uvedené principy jednoduchosti, znovupoužitelnosti a konzistence, jelikož i komplexnější komponenty se mohou v uživatelském rozhraní opakovat a jejich použití musí být pro vývojáře srozumitelné.
2.5 Správa softwarového projektu a kontinuální integrace
Valná část softwarových projektů se nachází v prostředí, u kterého vzniká potřeba sdílení vyvíjených funkcionalit mezi vývojáři, případně i mezi celými vývojovými týmy. Nezbytnou součástí této práce je vymezení pojmů z oblasti sdílení a správy softwarového kódu a s tím souvisejícím postupem kontinuální integrace a sestavení vyvíjené softwarové aplikace a následného nasazení. V první části této kapitoly je vymezen pojem repositáře a správy verzí, druhá část se pak zaměřuje na oblast sestavení a nasazení vyvíjené aplikace.
2.5.1Repositář a správa verzí
Při participaci členů týmů na softwarovém projektu vzniká potřeba sdíleného virtuálního prostoru pro ukládání souborů. K tomu účelu jsou využívány repositáře. Repositář je místo, ve kterém jsou ukládány verzované soubory. Slovo verzované v tomto případě značí, že v repositáři se nachází mimo aktuální verze souborů i jejich předchozí verze. Díky tomu lze sledovat průběh vývoje a případně potřeby využít dřívějšího kódu, který by byl bez použití repositáře ztracen (Christensson 2021).
Verzování souborů v repositáři je realizováno dvěma odlišnými postupy. Tím prvním je centralizované verzování. V centralizovaném verzování se předpokládá existence centralizovaného systému správy verzí, ve kterém jsou uchovávány veškeré verzované soubory. Vývojáři pak využívají klientského nástroje, který k takto centralizovaně uloženým souborům vzdáleně přistupuje. Mezi známé představitele tohoto řešení se řadí systémy zprávy verzí CVS a Subversion.
Druhou variantou řešení pak jsou distribuované systémy správy verzí. V případě distribuovaného systému je využíváno principu zrcadlení, ve kterým klient nestahuje aktuální verzi souborů repositáře, ale k určitému okamžiku zrcadlí celý repositář (Git 2021).
Dochází tak ke vzniku klonů získaných ze serveru, které obsahují veškeré informace původní kopie. Toto je značnou výhodou zejména z hlediska zajištění existence dat, v případě selhání centralizovaného systému může dojít ke ztrátě dat. Distribuovaný systém správy verzí ovšem udržuje zrcadlené verze na klientských zařízeních a díky tomu tak je zajištěna existence repositáře i v případě selhání repositáře na serveru. Nejznámějším představitelem distribuovaného systému správy verzí je Git.
2.5.2Sestavení
Sestavení (build) je proces, při kterém je provedeno převedení čitelného, zdrojového kódu na kód zpracovávaný strojem. K tomuto procesu dochází z důvodu efektivnějšího zpracování takto zpracovaného kódu počítačem (Rani 2019). V popisované oblasti jazyka JavaScript, který je používán pro vývoj webových uživatelských rozhraní, je možné kompletní proces sestavení rozdělit do následujících činností.
1. Překlad 2. Sdružení 3. Minifikace 4. Zabalení
Při překladu dochází k převodu kódu jazyka JavaScript, případně jeho nadstavby do podoby, která je čitelná a kompatibilní s širokou škálou prohlížečů a prostředí.
K překladu jazyka JavaScript se zpravidla užívá nástroj Babel. Navazující fází je pak sdružení, při kterém jsou jednotlivé fragmenty kódu nacházející se v různých souborech projektu, sloučeny do jediného souboru, který je pak čtený koncovým zařízením. V části minifikace je provedeno zmenšení velikosti souborů. Toho je dosaženo například odstraněním redundantních částí kódu, nepotřebných dat, komentářů a bílých znaků.
V poslední části, zabalení, je sestavený kód včetně příslušných souborů zkompletován a uložen do cílového umístění (Akintayo 2020).
2.5.3Kontinuální integrace
2.6 Identifikace problémů vývojových týmů v oblasti sdíleného vývoje
V podkapitole 2.3 Vymezení pojmů oblasti sdílených funkcionalit jsou popsány principy modulárního vývoje a určena specifika pro oblast vývoje webových rozhraní. Uvedený koncept komponent přináší možnost opakovatelnosti a konzistence vyvíjených front-end funkcionalit. Problém sdíleného vývoje má ovšem několik rovin, samotnému vývoji sdílených funkcionalit předchází fáze návrhu softwarové architektury, umožňující realizaci sdílení těchto funkcionalit. Etapě vývoje také vždy předchází určité plánování daného vývoje a výběr metody, která umožňuje efektivní řízení projektu sdíleného charakteru.
2.6.1 Sdílení vyvíjených funkcionalit
S příchodem agilního vývoje aplikací souvisí potřeba průběžného přizpůsobování designu a implementace funkcionalit napříč projektem, které často nejsou dopředu zcela definovány a fáze návrhu a vývoje tak spolu úzce souvisejí. S narůstajícím počtem prvků v aplikaci roste i komplexita samotné správy a údržby návrhu. Tým softwarového projektu potřebuje společný komunikační jazyk, který umožňuje všem participujícím stranám snadné a jednotné porozumění vyvíjeného řešení. Obdobně vzniká potřeba společné komunikace mezi vývojovým týmem a zástupcem zadavatelem projektu, jenž průběžně uděluje zpětnou vazbu k realizaci softwarového projektu. Se vznikem dalších, vyvozených aplikací jedné platformy, navíc přichází potřeba dodržení principu konzistence i napříč aplikacemi.
Z hlediska samotného vývoje se pak jedná o dodržení principů DRY a SoC, tedy snahy o minimalizaci množství duplicitních částí kódů a také snahy o zaměřenost vyvíjených funkcionalit. Vytvářené fragmenty kódů by měly být znovupoužitelné, modulární a současně by o nich měli být průběžně informováni všichni členi vývojového týmu. Nedodržení těchto zásad má za následek vznik opakujících se kusů kódu, zvýšení četnosti chyb a také vznik nekonzistencí ve stylu psaní a strukturování kódu.
Jedním z nejznámějších realizátorů řešení sdíleného vývoje rozhraní použitého napříč aplikacemi je od společnost Spotify. Aplikace Spotify je jednou z předních služeb pro poslech hudby, dostupné v modelu na vyžádání. Se svými 286 miliony uživatelů v roce 2020 se jedná o vůbec nejpoužívanější aplikaci této oblasti (Iqbal 2018). Služba je momentálně dostupná pro širokou škálu zařízení a je vyvíjena v mnoha variantách, od webové aplikace, po iOS a Android nativní aplikace. V článku Design Doesn’t Scale je pak popsán proces souběžného návrhu a vývoje aplikací Spotify v roce 2012 (Wood 2016). Stanley Wood v článku zmiňuje postupně vznikající rozdíly v návrhu a vývoje uživatelských rozhraní dílčích aplikací, které se napříč dedikovanými týmy začaly poměrně výrazně lišit a nepůsobily tak vůbec jako produkty zastřešené společnou platformou a společností.
Obrázek 2: Rozdíly v podobě rozhraní produktů společnosti Spotify v roce 2012 (Wood 2016) Ve společnosti proto došlo k rozhodnutí vytvořit sdílený systém návrhu a vývoje rozhraní, který slouží jako SSoT pro všechny softwarové týmy a současně zaručuje dodržení vizuální i funkční konzistence napříč širokým spektrem vyvíjených aplikací. Tento systém obsahuje elementární informace o rozhraní, jedná se například o používané palety barev, používané sady ikonek, až po jednotlivé části aplikace, u kterých je detailněji popsána funkcionalita těchto dílčích částí, tak i jejich vizuální stránka.
produktu. Společným řešením zmiňovaných společností bylo vytvoření jednotného zdroje informací pro dedikované týmy, které dává společný základ při vývoji produktů a které umožňuje jednoduchou správu změn a distribuci informací napříč celým podnikem.
2.6.2Architektura projektu sdíleného vývoje
Problém sdílení mezi projekty se obdobně dotýká architektury projektového repositáře.
V případě realizace samostatného softwarového projektu, případně produktu, není toto zpravidla problémem. Projekt má vlastní konfiguraci3, prochází jednoduchých procesem sestavení a komplexita architektury je tak minimální. V oblasti softwarového vývoje ovšem stále častěji dochází k souběžnému vývoji několika produktů, u kterých vzniká potřeba dodržení konzistence, a to jak z hlediska konfigurace projektů, tak i sestavovacích nástrojů.
U takto souběžně realizovaných projektů postupem času dochází ke vzniku rozdílů mezi využívanými konfiguracemi projektů a také mezi verzemi externích knihoven. Současně dochází ke vzniku komplexních CI struktur, z důvodu současného vzájemně návazného sestavování několika projektů. Projekty vlivem použití rozdílných konfigurací a knihoven a opakováním existujících řešení, přicházejí o princip SSoT a DRY, a následně tak u nich dochází k nekonzistencím v implementaci funkcionalit a v psaní kódu.
Známým řešitelem výše uvedeného problému v praxi je společnost Google, která se z uvedených důvodů rozhodla využít architekturu Monorepo, ve které je v rámci jediného repositáře obsaženo současně více softwarových projektů. V repositáři společnosti Google se již v roce 2015 nacházelo přes 2 miliardy řádků kódu a 85 terabajtů dat, jedná se tak o jeden z největších repositářů na světě (Metz 2015). Architekturu Monorepo využívají i další velké technologické společnosti, mezi které se řadí například Microsoft, Facebook a Airbnb. Pro takovou architekturu je pak typické, že se v jednom repositáři nachází více projektů současně, zpravidla se jedná o několik softwarových produktů dané platformy, které sdílejí například společnou funkcionalitu a prvky uživatelského rozhraní.
V architektuře Monorepo dochází k umístění několika projektů do jednoho společného repositáře za účelem snadného sdílení vyvinutých funkcionalit. Monorepo je poměrně populárním tématem posledních let, které přináší značné výhody při sdílení funkcionalit, avšak z důvodů jistých kompromisů vůči stále běžnější architektuře Multirepo, a někdy také z důvodu nepochopení jejích principů, má i řadu svých odpůrců. Samotné principy a využití architektury Monorepo, vymezené v oblasti webového vývoje a identifikace problémů souvisejících s využitím jednotlivých architektur repositáře jsou podrobněji popsány v samostatné kapitole.
2.6.3 Sdílená dokumentace
Členové týmu by měli být průběžně informováni o zásadních změnách v aplikaci. Agilní vývoj se ve svém principu příliš nesoustřeďuje na dokumentaci projektu, samotné dokumentování projektu je v mnohých případech vnímáno spíše jako nezbytné zlo
3 Pod pojmem konfigurace je rozuměno nastavení základních vlastností technologií, které jsou použity při vývoji aplikace
a činnost, která jde do určité míry proti principům agilních metodik, tedy častého a včasného dodávání inkrementů produktu. Konkrétně se jedná o jeden z pilířů agilního manifesta, „Fungující software před vyčerpávající dokumentací“ (Fowler a Highsmith 2001). Některé klíčové části softwarového projektu, kterými jsou například konfigurace, případně části kódu, jenž jsou sdíleny napříč projekty a často využívány, by nicméně zdokumentovány být měly. Jistá míra dokumentace podstatně zlehčuje práci s existujícím kódem a v případě opakovaného použití funkcionality zaručuje již zmiňovaný SSoT princip.
Současně je společným jazykem mezi všemi členy týmu, kteří jsou formou dokumentace informováni o průběžných změnách v projektu a dokumentace se tak stává jakousi organizační pamětí. Dokumentace tak tímto opět naplňuje zmiňovaný princip SSoT.
Otázka potřeby dokumentace kódu je v následujících kapitolách podrobněji analyzována v kontextu využití agilní metodiky vývoje a v prostředí sdíleného kódu.
2.6.4 Řízení sdíleného vývoje projektů
Rostoucí množství souběžně vyvíjených, softwarových produktů klade vyšší nároky i na samotné řízení a plánování celého projektu. Diplomová práce se v tomto ohledu specificky zaměřuje na oblast agilních metod vývoje. Pro agilní metody vývoje je typické průběžné a pravidelné dodávání funkčního produktu, při komunikaci mezi členy na denní bázi (Fowler a Highsmith 2001). V rostoucím softwarovém projektu, popřípadě při souběžném vývoji více souvisejících softwarových projektů, se toto velmi často stává netriviálním problémem. Dochází k souběžnému řízení vícero týmů a projektů, současně mohou mít projekty vzájemný překryv ve vyvíjených funkcionalitách a jednotlivé týmy musí tyto změny průběžně komunikovat. Komunikaci je v případě sdílení funkcionalit napříč projekty potřeba rozšířit na mezitýmovou, při které se musí jednotlivé vývojové týmy průběžně informovat o proběhlých změnách v implementovaných funkcionalitách.
V takovémto případě vyvstává otázka, jakým způsobem lze dané týmy řídit a plánovat a rozdělovat vykonávanou práci. Je nezbytné zvolit vyhovující agilní metodu a současně využívat takové nástroje, jenž danou metodu podporují. Aspekt úrovně řízení ve sdíleném, agilně řízeném vývoji je podrobněji popsán v následujících kapitolách.
2.6.5Příklad problémů sdíleného vývoje
V následujícím textu je v širším měřítku uvedena problematika architektury webové aplikace v oblasti sdílení vyvíjených funkcionalit. V příkladu se jedná o softwarový projekt,
Požadavkem ze strany společnosti je dodržení konzistence návrhu rozhraní mezi oběma aplikacemi a současně nastavení shodné architektury aplikací napříč projekty.
Tyto požadavky jsou splněny a vzniká druhý projekt, jenž má vlastní repositář a konfiguraci, vycházející z konfigurace projektu původního. Do nové aplikace bylo převzato původní stylování aplikace4 a také byly zkopírovány implementované části projektu, které měly být použity i v projektu novém. S postupujícím vývojem aplikací ovšem začaly vznikat rozdíly mezi projekty, každý z týmů řešil obdobné úkoly svým vlastním postupem a s nově příchozími členy se začaly dále prohlubovat rozdíly ve stylu psaného kódu. Konfigurace obou projektů narůstaly a současně tím se zvyšovaly i nároky na jejich průběžnou správu a synchronizaci, v rámci snahy o dodržení vzájemné konzistence projektů. Každý z projektů využívá vlastního systému pro správu balíčků5, tyto správy balíčků pak také nejsou v průběhu vývoje vzájemně synchronizovány. Postupem času se tak začínají lišit verze používaných externích knihoven, což má za následek rozdílné chování a implementaci určitých částí kódu obou aplikací. Pro členy nově vzniklého týmu je současně náročné porozumění aplikační logiky již realizovaných částí aplikace, z důvodu absence jakékoliv formy dokumentace a popisu funkcionalit.
U obou projektů neexistuje žádná společná báze sdílených funkcionalit, která by byla zdokumentovaná a jednotlivé členy tak informovala o existenci takto vyvinutých funkcionalit. Oba projekty navíc jsou navíc realizovány v naprosté izolaci, bez možnosti sdílení a znovupoužití vyvinutých funkcionalit, například prvků rozhraní. Vlivem toho dochází ke vzniku duplicitního kódu napříč projekty, který se postupně stává nekonzistentním, neřízeným a jen těžko spravovatelným.
4 Stylování je označení pro definici podoby uživatelského rozhraní (Christensson 2006)
5 Správa balíčků je v kontextu zde popisované oblasti systémem pro instalaci a správu závislostí externích knihoven, uceleně označovaných pojmem balíček (Wanoyike 2020)
Obrázek 4: Souběžný vývoj dvou produktů s překryvem funkcionalit (vlastní zpracování) Z uvedeného příkladu je zřejmé, že napříč projektem vzniká mnoho nekonzistencí a redundancí, především pak co se týče konfigurace projektů a vyvíjených funkcionalit.
Z diagramu výše je také patrné, že mezi projekty je potenciál k překryvu funkcionalit, které týmy implementují, avšak už nedochází k jejich sdílení a každý tým takto implementuje totožná řešení svým vlastním způsobem. Oddělené, autonomní repositáře projektů tento přístup navíc neumožňují, obě aplikace jsou nezávislé a neexistuje způsob, jak logiku těchto aplikací jednoduše propojit. Tímto týmy přicházejí o možnost jednoduchého způsobu znovupoužívání již existujících částí kódu a porušují tím tak princip DRY a současně dochází k již uvedeným rozdílům ve stylu psaného kódu. Vyvstává tak otázka, zda neexistuje taková architektura repositáře, jež by umožnila jak sdílení částí projektů, u kterých by tak byla dodržena konzistence a znovupoužitelnost a současně, zda je mezi projekty možné dokumentovat takto sdíleně vyvíjené funkcionality. Možná řešení těchto problémů z oblasti sdílené architektury projektu webové aplikace jsou již nastíněna v předcházejícím textu, podrobnější analýza a návrh takovéto architektury je pak provedena v následující kapitole.
3 Sdílený vývoj front-end funkcionalit
V oblasti softwarového vývoje dochází k neustálému zvyšování rychlosti vývoje a doručení funkčního produktu. Se zaváděním agilních metodik vývoje nadále dochází i ke zkracování zpětnovazební smyčky v rámci softwarového týmu. Doručení vyvíjeného software na trh se dle výzkumu společnosti QSM Asociates zkracuje s použitím agilních metodik až o 37%
(Ballou 2008). Před samotnou fází implementace se také stále častěji užívá fáze prototypování, jenž zkracuje zpětnovazebnou smyčku mezi realizátorem projektu a jeho zadavatelem. Prototyp aplikace dává prostor společnému porozumění problému a poskytuje možnost udělení okamžité zpětné vazby, bez potřeby zdlouhavého vývoje funkcionality, jehož výstup je vlivem prodloužení fáze vývoje řešením méně agilním a často s velmi nejistým výsledkem.
V předcházejí kapitole je identifikován modulární vývoj jako řešení pro realizaci sdílených funkcionalit napříč projekty. Jak již bylo popsáno, běžným problémem webového vývoje je také to, že se v aplikaci nachází opakující se prvky uživatelského rozhraní, které by často mohly být zobecněny a předešlo by se tak opakující se implementaci již existující funkcionality. Tato opakovatelnost by se tak pro dosažení co nejvyšší efektivity, měla promítnout i do fáze vývoje aplikace.
Společným jmenovatelem uvedených příkladů je potřeba vzniku snadného způsobu sdílení vyvíjených funkcionalit aplikace, umožňujícího zkrácení zpětnovazební smyčky fáze vývoje.
Vývojáři by se současně měli snažit využít již existujících znalostí a řešení, jež jsou srozumitelně vyvinuta a řádně zdokumentována. Řešení tohoto problému pro oblasti vývoje webových rozhraní je tvorba ucelené sady sdílených komponent vyvíjeného rozhraní, označené pojmem design systém.
3.1 Design systém
Design systém (design system) je jednotný zdroj pravdy, obsahující všechny prvky, které umožňují softwarovému týmu návrh a vývoj uživatelského rozhraní (Hacq 2020). Princip SSoT neboli jednotného zdroje pravdy je definován již v úvodu práce, v kontextu design systému pak se pod tímto pojmem konkrétně skýtá způsob popisu struktury vyvíjeného rozhraní, v němž jsou veškeré prvky podrobně a jednoznačně definovány a současně jsou jednotně vnímány mezi všemi participujícími členy týmu. Nezbytnou součástí takového řešení je pak podrobná dokumentace komponent v design systému. Ta se stává společným jazykem napříč týmem softwarového projektu, do něhož mohou patřit například designéři uživatelského rozhraní, vývojáři, testeři softwarového projektu, případně vlastník produktu.
Samotný pojem design systém lze vnímat ve dvou úrovních. Tou první je návrh sady vizuálních prvků, které vychází z definovaného grafického manuálu, a který obsahuje návrh a popis základních vizuálních prvků vyvíjeného rozhraní. Z těchto prvků je následně vyvozen systém modulárních komponent, pro který je typické detailní popsání vlastností
obsažených komponent a jejich užití v aplikace, a to formou dokumentace. Do dokumentace komponent patří definování vizuální stránky a popsání dílčích vlastností a stavů komponenty. Další úrovní design systému je pak samotná implementace těchto komponent, které jsou agregovány v podobě softwarové knihovny a jsou pro vývojáře SSoT při vývoji aplikací.
3.1.1Návrh design systému
V úrovni návrhu je pojem design systém vnímán z pohledu samotného návrhu prvků uživatelského rozhraní. Design systém je vizuálním jazykem, který slouží ke společnému vnímání a porozumění vyvíjenému rozhraní, popisuje jeho prvky a definuje požadavky na vzhled i funkčnost dílčích částí navrhovaného uživatelského rozhraní. Základ design systému je nastaven v grafickém manuálu, který vyvozuje základní firemní styl. Grafický manuál popisuje barevné palety, typografie, ikony a designové vzory a uvádí příklady praktického užití grafických prvků (Fanguy 2019).
Další fází návrhu pak je vytvoření katalogu vizuálních komponent, nazývaném pattern library (Fanguy 2019). Pod pojmem komponenta rozumíme vizuální prvek, který má přesně definovaný design a k němu příslušící funkcionalitu. Zpravidla se jedná o definování vlastností a stavů komponenty, implikujících jejich vizuální stránku. Pro komponentu pak je typická její robustnost a modularita, díky kterým je možné danou komponentu použít napříč celým vyvíjeným rozhraním. Vzhledem k principu znovupoužitelnosti by daná komponenta měla být dostatečně flexibilní, odpovídající definované škále požadavků a případů užití. Modulárnost pak značí, že komponenta je typizovanou částí systému, ve které vykonává danou funkci.
Praktickým příkladem jednoduché komponenty může být již dříve uvažované tlačítko.
Tlačítko je jednou ze základních součástí většiny uživatelských rozhraní, umožňující vykonat uživateli aplikace jistou akci. Pro komponentu tlačítka je typické, že se nachází v jistém výchozím stavu a po stisknutí provede činnost a následně se dostává do nového stavu. Pro tyto stavy pak je typická určitá vizuální indikace, jenž dává uživateli informaci o změně daného stavu. Všechny tyto informace jsou typicky součástí design systému a jsou v něm zdokumentovány.
