Dobrý den, přátelé. V očekávání zahájení kurzu , se s vámi tradičně podělí o překlad užitečného materiálu.
Software řeší stále více každodenních úkolů, přičemž je stále složitější. Jak jednou řekl Marc Andressen, pohlcuje svět.
V důsledku toho se za posledních několik let dramaticky změnil způsob, jakým jsou aplikace vyvíjeny a dodávány. Byly to posuny tektonického měřítka, které vyústily v soubor principů. Tyto principy se ukázaly jako užitečné při budování týmu, navrhování, vývoji a dodávání vaší aplikace koncovým uživatelům.
Principy lze shrnout takto: aplikace by měla být malá, webová a měla by mít architekturu zaměřenou na vývojáře. S ohledem na tyto tři principy můžete vytvořit robustní komplexní aplikaci, která může být rychle a bezpečně doručena koncovému uživateli a je snadno škálovatelná a rozšiřitelná.
Každý z navrhovaných principů má řadu aspektů, které probereme, abychom ukázali, jak každý princip přispívá ke konečnému cíli, kterým je rychlé dodání spolehlivých aplikací, které se snadno udržují a používají. Podíváme se na principy ve vztahu k jejich protikladům, abychom si ujasnili, co to znamená, řekněte: „Ujistěte se, že používáte princip malosti".
Doufáme, že vás tento článek povzbudí k používání navrhovaných principů pro vytváření moderních aplikací, které poskytnou jednotný přístup k navrhování v kontextu stále rostoucího technologického balíku.
Uplatněním těchto principů zjistíte, že využíváte nejnovější trendy ve vývoji softwaru, včetně k vývoji a dodávání aplikací, používání kontejnerů (např. ) a rámce pro orchestraci kontejnerů (např. ), používání mikroslužeb (včetně architektury mikroslužeb и pro mikroservisní aplikace.
Co je to moderní aplikace?
Moderní aplikace? Moderní zásobník? Co přesně znamená „moderní“?
Většina vývojářů má pouze obecnou představu o tom, z čeho se moderní aplikace skládá, proto je nutné tento pojem jasně definovat.
Moderní aplikace podporuje více klientů, ať už jde o uživatelské rozhraní knihovny React JavaScript, mobilní aplikaci pro Android nebo iOS nebo aplikaci, která se připojuje k jinému API. Moderní aplikace implikuje neurčitý počet klientů, pro které poskytuje data nebo služby.
Moderní aplikace poskytuje API pro přístup k požadovaným datům a službám. API by mělo být neměnné a konstantní a nemělo by být napsáno speciálně pro konkrétní požadavek od konkrétního klienta. API je dostupné přes HTTP(S) a poskytuje přístup ke všem funkcím dostupným v GUI nebo CLI.
Data musí být dostupná v běžně přijímaném interoperabilním formátu, jako je JSON. API odhaluje objekty a služby čistým, organizovaným způsobem, jako RESTful API nebo GraphQL poskytují slušné rozhraní.
Moderní aplikace jsou postaveny na moderním zásobníku a moderní zásobník je zásobník, který takové aplikace podporuje, resp. Tento zásobník umožňuje vývojáři snadno vytvořit aplikaci s rozhraním HTTP a jasnými koncovými body API. Zvolený přístup umožní vaší aplikaci snadno přijímat a odesílat data ve formátu JSON. Jinými slovy, moderní zásobník odpovídá prvkům aplikace Twelve-Factor pro .
Populární verze tohoto typu zásobníku jsou založeny na , , , , и . Architektura mikroslužeb představuje příklad moderního zásobníku implementovaného v každém ze zmíněných jazyků.
Upozorňujeme, že nepodporujeme výhradně mikroservisní přístup. Mnozí z vás pracují s monolity, které se potřebují vyvíjet, zatímco jiní se zabývají aplikacemi SOA, které se rozšiřují a vyvíjejí, aby se staly aplikacemi mikroslužeb. Další se posouvají k aplikacím bez serveru a některé implementují kombinace výše uvedeného. Principy uvedené v článku platí pro každý z těchto systémů pouze s několika malými úpravami.
Zásady
Nyní, když máme společné chápání toho, co je moderní aplikace a moderní zásobník, je čas ponořit se do architektury a principů vývoje, které vám dobře poslouží při vývoji, implementaci a údržbě moderní aplikace.
Jeden z principů zní jako „dělat malé aplikace“, nazvěme to princip malosti. Existují neuvěřitelně složité aplikace, které se skládají z mnoha pohyblivých částí. Sestavení aplikace z malých, diskrétních komponent zase usnadňuje její návrh, údržbu a práci s ní jako celkem. (Všimněte si, že jsme řekli „zjednodušuje“, nikoli „zjednodušuje“).
Druhým principem je, že můžeme zvýšit produktivitu vývojářů tím, že jim pomůžeme soustředit se na funkce, které vyvíjejí, a zároveň je během implementace zbavíme starostí s infrastrukturou a CI/CD. Takže v kostce náš přístup zaměřené na vývojáře.
Nakonec vše o vaší aplikaci musí být připojeno k síti. Za posledních 20 let jsme udělali velký krok směrem k síťové budoucnosti, protože sítě se stávají rychlejšími a aplikace složitější. Jak jsme již viděli, moderní aplikaci musí přes síť používat mnoho různých klientů. Aplikace síťového myšlení na architekturu má významné výhody, které se dobře doplňují princip malosti a koncept přístupu, orientovaný na vývojáře.
Pokud budete mít tyto zásady na paměti při návrhu a implementaci aplikace, budete mít nepopiratelnou výhodu při vývoji a dodávce svého produktu.
Podívejme se na tyto tři principy podrobněji.
Princip malosti
Pro lidský mozek je obtížné vnímat současně velké množství informací. V psychologii termín kognitivní zátěž označuje celkové množství duševního úsilí potřebného k udržení informací v paměti. Snížení kognitivní zátěže vývojářů je prioritou, protože jim to umožňuje soustředit se na řešení problému místo toho, aby si v hlavě drželi současný složitý model celé aplikace a vyvíjené funkce.
Aplikace se rozkládají z následujících důvodů:
- Snížená kognitivní zátěž vývojářů;
- Zrychlení a zjednodušení testování;
- Rychlé doručení změn v aplikaci.
Existuje několik způsobů, jak snížit kognitivní zátěž vývojářů, a zde se uplatňuje princip malosti.
Zde jsou tedy tři způsoby, jak snížit kognitivní zátěž:
- Zkraťte časový rámec, který musí vzít v úvahu při vývoji nové funkce – čím kratší časový rámec, tím nižší kognitivní zátěž.
- Snižte množství kódu, na kterém se provádí jednorázová práce – méně kódu – menší zátěž.
- Zjednodušte proces provádění postupných změn v aplikaci.
Snížení časového rámce vývoje
Vraťme se do dob, kdy metodika waterfall byl standardem pro proces vývoje a časové rámce od šesti měsíců do dvou let pro vývoj nebo aktualizaci aplikace byly běžnou praxí. Inženýři by si obvykle nejprve přečetli relevantní dokumenty, jako jsou požadavky na produkt (PRD), systémový referenční dokument (SRD), návrh architektury a začali všechny tyto věci kombinovat do jednoho kognitivního modelu, podle kterého kódovali. Vzhledem k tomu, že se požadavky a následně i architektura měnily, muselo být vynaloženo velké úsilí na informování celého týmu o aktualizacích kognitivního modelu. Takový přístup by v nejhorším případě mohl práci jednoduše paralyzovat.
Největší změnou v procesu vývoje aplikace bylo zavedení agilní metodiky. Jeden z hlavních rysů metodiky agile je iterativní vývoj. To zase vede ke snížení kognitivní zátěže inženýrů. Namísto požadavku na vývojový tým implementovat aplikaci v jednom dlouhém cyklu, agile Tento přístup vám umožňuje zaměřit se na malé množství kódu, který lze rychle otestovat a nasadit a zároveň získat zpětnou vazbu. Kognitivní zátěž aplikace se posunula z šestiměsíčního na dvouletý časový rámec s velkým množstvím specifikací pro dvoutýdenní přidání nebo změnu funkce zaměřené na rozmazanější chápání velké aplikace.
Přesunutí zaměření z masivní aplikace na specifické malé funkce, které lze dokončit během dvoutýdenního sprintu, přičemž není třeba mít na paměti více než jednu funkci před dalším sprintem, je významnou změnou. To nám umožnilo zvýšit produktivitu vývoje a zároveň snížit kognitivní zátěž, která neustále kolísala.
V metodice agile Očekává se, že konečná aplikace bude mírně upravená verze původního konceptu, takže konečný bod vývoje je nutně nejednoznačný. Pouze výsledky každého konkrétního sprintu mohou být jasné a přesné.
Malé kódové báze
Dalším krokem ke snížení kognitivní zátěže je redukce kódové základny. Moderní aplikace jsou zpravidla masivní – robustní podniková aplikace se může skládat z tisíců souborů a stovek tisíc řádků kódu. V závislosti na tom, jak jsou soubory uspořádány, mohou být zřejmé vazby a závislosti mezi kódem a soubory nebo naopak. Dokonce i samotné provádění ladění kódu může být problematické v závislosti na použitých knihovnách a na tom, jak dobře ladicí nástroje rozlišují mezi knihovnami/balíčky/moduly a uživatelským kódem.
Vytvoření funkčního mentálního modelu kódu aplikace může zabrat impozantní množství času a opět klást na vývojáře velkou kognitivní zátěž. To platí zejména pro monolitické kódové báze, kde existuje velké množství kódu, jehož interakce mezi funkčními složkami není jasně definována a oddělení objektů pozornosti je často rozmazané, protože nejsou respektovány funkční hranice.
Jedním z účinných způsobů, jak snížit kognitivní zátěž inženýrů, je přejít na architekturu mikroslužeb. V přístupu mikroslužeb se každá služba zaměřuje na jednu sadu funkcí; přičemž význam služby je obvykle definován a srozumitelný. Hranice služby jsou také jasné – nezapomeňte, že komunikace se službou probíhá přes API, takže data generovaná jednou službou lze snadno předávat jiné.
Interakce s jinými službami je obvykle omezena na několik uživatelských služeb a několik služeb poskytovatelů, které používají jednoduchá a čistá volání API, jako je použití REST. To znamená, že kognitivní zátěž inženýra je vážně snížena. Největší výzvou zůstává pochopení modelu interakce služeb a toho, jak se věci, jako jsou transakce, odehrávají v různých službách. V důsledku toho používání mikroslužeb snižuje kognitivní zátěž snížením množství kódu, definováním jasných hranic služeb a poskytováním porozumění vztahu mezi uživateli a poskytovateli.
Malé postupné změny
Poslední prvek principu malost je řízení změn. Pro vývojáře je zvláštním pokušením podívat se na kódovou základnu (dokonce možná svůj vlastní, starší kód) a říci: "To je svinstvo, musíme to všechno přepsat." Někdy je to správné rozhodnutí a někdy ne. Klade břemeno změny globálního modelu na vývojový tým, což zase vede k masivní kognitivní zátěži. Pro inženýry je lepší zaměřit se na změny, které mohou provést během sprintu, aby mohli včas, i když postupně, zavést potřebnou funkcionalitu. Finální produkt by se měl podobat tomu předem plánovanému, ale s určitými úpravami a testováním, aby vyhovoval potřebám klienta.
Při přepisování velkých částí kódu někdy není možné změnu rychle doručit, protože do hry vstupují jiné systémové závislosti. Chcete-li řídit tok změn, můžete použít skrytí funkcí. V zásadě to znamená, že funkce je ve výrobě, ale není dostupná pomocí nastavení proměnné prostředí (env-var) nebo jiného konfiguračního mechanismu. Pokud kód prošel všemi procesy kontroly kvality, může skončit ve výrobě v latentním stavu. Tato strategie však funguje pouze v případě, že je funkce nakonec povolena. V opačném případě to pouze zahltí kód a přidá kognitivní zátěž, se kterou se bude muset vývojář vypořádat, aby byl produktivní. Řízení změn a inkrementální změny samotné pomáhají udržovat kognitivní zátěž vývojářů na dostupné úrovni.
Inženýři musí překonat mnoho obtíží i s jednoduchým zavedením dodatečné funkce. Ze strany managementu by bylo rozumné snížit zbytečnou zátěž týmu, aby se mohl soustředit na klíčové funkční prvky. Existují tři věci, které můžete svému vývojovému týmu pomoci:
- Použijte metodologii
agileomezit časový rámec, ve kterém se tým musí soustředit na klíčové funkce. - Implementujte svou aplikaci jako více mikroslužeb. To omezí počet funkcí, které lze implementovat, a posílí hranice, které udržují kognitivní zátěž v práci.
- Preferujte postupné změny před velkými a nepraktickými, měňte malé kousky kódu. Pomocí skrytí funkcí implementujte změny, i když nebudou viditelné ihned po přidání.
Pokud ve své práci uplatníte zásadu malosti, bude váš tým mnohem šťastnější, lépe se soustředí na implementaci potřebných funkcí a s větší pravděpodobností rychleji zavede kvalitativní změny. To ale neznamená, že by se práce nemohla zkomplikovat, někdy naopak zavedení nové funkcionality vyžaduje úpravu několika služeb a tento proces může být v monolitické architektuře obtížnější než podobný. V každém případě výhody přístupu malosti stojí za to.
Konec prvního dílu.
Brzy zveřejníme druhou část překladu a nyní čekáme na vaše komentáře a zveme vás , který se uskuteční dnes ve 20.00.
Zdroj: www.habr.com