Ahoj, přátelé. Před zahájením kurzu , tradičně s vámi sdílíme překlad užitečného materiálu.
Software stále více řeší každodenní úkoly a zároveň se stává složitějším. Jak jednou řekl Marc Andreessen, pohlcuje svět.
V důsledku toho se v posledních několika letech přístupy k vývoji a dodávce aplikací vážně změnily. Bylo to tektonické posunutí, které vedlo k rozvoji řady principů. Tyto principy se ukázaly jako užitečné při formování týmu, návrhu, vývoji a dodávce vaší aplikace koncovým uživatelům.
Principy lze shrnout následovně: aplikace by měla být malá, síťová a mít architekturu zaměřenou na vývojáře. Na těchto třech principech můžete vytvořit spolehlivou, komplexní aplikaci, která může být rychle a bezpečně dodána koncovému uživateli a snadno škálována a rozšiřována.
Každý z uvedených principů má řadu aspektů, které prodiskutujeme, abychom ukázali, jak každý princip přispívá k dosažení konečného cíle, jímž je rychlé dodání spolehlivých aplikací, které jsou snadné na údržbu a používání. Budeme zkoumat principy ve srovnání s jejich protiklady, abychom objasnili, co znamená, dejme tomu, „Ujistěte se, že používáte princip malosti».
Doufáme, že vás tento článek povzbudí k použití doporučených principů pro budování moderních aplikací, které zajistí jednotný přístup k návrhu v kontextu nepřetržitě rostoucího technologického stacku.
Aplikací těchto principů zjistíte, že sledujete nejnovější trendy ve vývoji softwaru, včetně přístupu k vývoji a dodávce aplikací, používání kontejnerů (například ) a frameworků pro orchestraci kontejnerů (například ), používání mikroservisů (včetně Mikroservisní architektury a pro mikroservisní aplikace.
Co je moderní aplikace?
Moderní aplikace? Moderní stack? Co přesně znamená „moderní“?
Většina vývojářů má jen obecnou představu o tom, z čeho se skládá moderní aplikace, a proto je nutné poskytnout jasné vymezení tohoto pojmu.
Moderní aplikace podporuje několik klientů, ať už je to uživatelské rozhraní na knihovně JavaScript React, mobilní aplikace pro Android nebo iOS, nebo aplikace, která se připojuje k jinému prostřednictvím API. Moderní aplikace předpokládá existenci neurčitého počtu 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 stálé, nikoli napsané konkrétně pro specifický požadavek z konkrétního klienta. API je dostupné přes HTTP(S) a zajišťuje přístup ke všem funkcím, které jsou dostupné v GUI nebo CLI.
Data by měla být dostupná ve standardním, kompatibilním formátu, jako je JSON. API poskytuje objekty a služby v srozumitelné, organizované podobě, například RESTful API nebo GraphQL poskytují přehledné rozhraní.
Moderní aplikace jsou postaveny na moderním stacku, a moderní stack je ten stack, který takové aplikace podporuje. Tento stack umožňuje vývojáři snadno vytvářet aplikaci s HTTP rozhraním a jasnými koncovými body API. Zvolený přístup umožní vaší aplikaci snadno přijímat a posílat data ve formátu JSON. Jinými slovy, moderní stack odpovídá prvkům Dvanácti faktorové aplikace. .
Populární verze tohoto typu stacku jsou založeny na , , , , a . Mikroslužbová architektura z představuje příklad moderního stacku realizovaného v každém z uvedených jazyků.
Všimněte si, že nepropagujeme výhradně mikroslužbový přístup. Mnozí z vás pracují s monolity, které se musí rozvíjet, zatímco jiní se zabývají SOA aplikacemi, které se rozšiřují a vyvíjejí, aby se staly mikroslužbovými aplikacemi. Někteří se orientují na implementaci bezserverových (serverless) aplikací a někteří zavádějí kombinace výše zmíněného. Principy uvedené v článku jsou aplikovatelné na každý z těchto systémů s několika drobnými úpravami.
Principy
Nyní, když jsme dosáhli společného porozumění, co vlastně moderní aplikace a moderní tech stack obnášejí, je čas ponořit se do zásad architektury a vývoje, které vám pomohou v navrhování, implementaci a údržbě moderní aplikace.
Jedna z těchto zásad zní: „vytvářejte malé aplikace“, pojďme ji jednoduše nazvat principem malosti. Existují neuvěřitelně složité aplikace, které se skládají z velkého množství pohyblivých komponentů. Na druhou stranu stavba aplikace z malých diskrétních komponentů usnadňuje její návrh, údržbu a celkovou práci s ní. (Všimněte si, že jsme řekli „usnadňuje“, nikoli „činí jednoduchou“).
Druhá zásada spočívá v tom, ž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 osvobodíme od starostí o infrastrukturu a CI/CD během implementace. Takže, zkráceně řečeno, náš přístup je zaměřen na vývojáře.
Nakonec by vše, co se týká vaší aplikace, mělo být připojeno k síti. Během posledních 20 let jsme se výrazně posunuli směrem k síťové budoucnosti, jelikož sítě se staly rychlejšími a aplikace složitějšími. Jak jsme již zjistili, moderní aplikace by měly být používány přes síť mnoha různými klienty. Aplikace myšlení o síti v architektuře přináší značné výhody, které se dobře sbíhají s principem malosti a konceptem přístupu, zaměřeného na vývojáře.
Pokud budete během vývoje a implementace aplikace mít na paměti uvedené zásady, budete mít nepopiratelné výhody v rozvoji a dodání vašeho produktu.
Podívejme se nyní podrobněji na tyto tři zásady.
Princip malosti
Lidskému mozku se obtížně vnímá velké množství informací najednou. 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 na vývojáře je prioritou, protože v takovém případě se mohou soustředit na řešení problémů, místo aby museli ve své mysli udržovat aktuální složitý model celé aplikace a vyvíjených funkcí.
Aplikace se dekonstruktují z následujících důvodů:
- Snížení kognitivní zátěže pro vývojáře;
- Zrychlení a zjednodušení testování;
- Rychlé dodání změn v aplikaci.
Existuje několik způsobů, jak snížit kognitivní zátěž pro vývojáře, a právě sem vstupuje princip malé velikosti.
Takže tři způsoby, jak snížit kognitivní zátěž:
- Zkrátit časové rámce, na které musí brát ohled při vývoji nové funkce – čím kratší časový rámec, tím nižší kognitivní zátěž.
- Snížit množství kódu, se kterým je třeba pracovat najednou – méně kódu = méně zátěže.
- Zjednodušit proces provádění inkrementálních změn v aplikaci.
Snížení časových rámců vývoje
Vraťme se do doby, kdy byla metodologie waterfall standardem v procesu vývoje a časové rámce od šesti měsíců do dvou let pro vývoj nebo aktualizaci aplikace byly běžnou praxí. Obvykle inženýři nejprve přečetli příslušné dokumenty, jako jsou požadavky na produkt (PRD), systémový referenční dokument (SRD), plán architektury a začali tyto věci spojovat do jedné kognitivní modelu, podle které psali kód. Jak se požadavky a tudíž architektura měnily, bylo třeba vynaložit velké úsilí na informování celého týmu o aktualizacích kognitivního modelu. Tento přístup v nejhorším případě mohl práci doslova paralyzovat.
Největší změnou v procesu vývoje aplikací bylo zavedení metodologie agile. Jednou z hlavních charakteristik metodologie agile je iterativní vývoj. To pro změnu vede ke snížení kognitivní zátěže pro inženýry. Místo toho, aby tým vývojářů musel realizovat aplikaci během jednoho dlouhého cyklu, agile přístup umožňuje soustředit se na malé objemy kódu, které lze rychle otestovat a nasadit, přičemž se získá i zpětná vazba. Kognitivní zátěž aplikace se posunula z časového rámce od šesti měsíců do dvou let s ohledem na obrovské množství specifikací na dvoutýdenní přidání nebo změny funkce, zaměřené na ještě rozmazanější porozumění velké aplikaci.
Posun zaměření z masivních aplikací na konkrétní malé funkce, které lze dokončit během dvoutýdenního sprintu, přičemž se díváme dopředu maximálně na jednu funkci z následujícího sprintu, je značná změna. To přispělo k zvýšení produktivity vývoje, přičemž se snížila kognitivní zátěž, která neustále kolísala.
V metodologii agile se předpokládá, že konečná aplikace bude poněkud pozměněnou verzí původní koncepce, a proto je konečný bod vývoje nezbytně nejasný. Jasné a přesné mohou být pouze výsledky každého konkrétního sprintu.
Malé kódové báze
Dalším krokem ke snížení kognitivní zátěže je zmenšení kódové báze. Obecně platí, že moderní aplikace jsou masivní – spolehlivá firemní aplikace může obsahovat tisíce souborů a stovky tisíc řádků kódu. V závislosti na organizaci souborů mohou být vazby a závislosti kódu a souborů zřejmé, nebo naopak. I ladění samotného provádění kódu může způsobovat problémy v závislosti na použitých knihovnách a na tom, jak dobře ladicí nástroje oddělují knihovny/pakety/moduly a uživatelský kód.
Vytvoření funkční mentální modelu kódu aplikace může zabrat značné množství času a opět klade na vývojáře vysokou kognitivní zátěž. To je obzvlášť charakteristické pro monolitní kódové základy, kde je velké množství kódu, jehož interakce mezi jednotlivými funkčními komponentami není jasně definována, a rozdělení předmětů pozornosti je často rozmazané, protože funkční hranice nejsou dodržovány.
Jedním z efektivních způsobů, jak snížit kognitivní zátěž na inženýry, je přechod na mikroslužby. V přístupu k mikroslužbám se každý servis zaměřuje na jeden soubor funkcí; smysl služby je obvykle definován a srozumitelný. Hranice služby jsou také jasné – pamatujte, že komunikace se službou probíhá pomocí API, takže data generovaná jednou službou mohou být snadno předána do jiné.
Interakce s jinými službami je obvykle omezena na několik uživatelských služeb a několik služeb poskytovatele, které využívají jednoduché a přehledné API volání, například pomocí REST. To znamená, že kognitivní zátěž na inženýra se výrazně snižuje. Nejtěžším úkolem zůstává pochopení modelu interakce služeb a toho, jak například transakce probíhají mezi více službami. Výsledkem je, že používání mikroservisů snižuje kognitivní zátěž, zmenšuje množství kódu, vytyčuje jasné hranice služby a zajišťuje pochopení vztahů mezi uživateli a poskytovateli.
Malé inkrementální změny
Poslední prvek principu maličkosti – je to řízení změn. Zvláštním pokušením pro vývojáře je podívat se na kódovou základnu (dokonce možná na svůj vlastní, starší kód) a prohlásit: „To je hrozné, všechno to musíme přepsat.“ Někdy je to správné rozhodnutí, jindy ne. Tím se na vývojářský tým naloží břemeno globální změny modelu, což zase vede k rozsáhlé kognitivní zátěži. Je lepší, aby se inženýři soustředili na změny, které mohou provést během sprintu, aby poté včas nasadili potřebnou funkčnost, i když postupně. Konečný produkt by měl připomínat předem naplánovaný, ale s některými úpravami a testováním, aby vyhovoval potřebám klienta.
Při přepisování velkých částí kódu se někdy rychle realizovat dodání změn zdá nemožné, protože zde vstupují do hry jiné závislosti systému. Pro řízení toku změn lze použít skrývání funkcí (feature hiding). V podstatě to znamená, že funkce je v produkci, ale není přístupná pomocí nastavení proměnných prostředí (env-var) nebo jiného mechanismu konfigurace. Pokud kód prošel všemi procesy kontroly kvality, může se ocitnout v produkci ve skrytém stavu. Tato strategie však funguje pouze v případě, že funkce bude nakonec povolena. V opačném případě bude pouze zaneřáďovat kód a přidá kognitivní zátěž, kterou bude muset vývojář zvládnout pro produktivní práci. Řízení změn a inkrementální změny samy o sobě pomáhají udržovat kognitivní zátěž vývojářů na dostupné úrovni.
Inženýři se musí vyrovnávat s mnoha komplikacemi, i při jednoduchém zavádění nových funkcionalit. Z pohledu managementu by bylo rozumné snížit nadbytečné zatížení týmu, aby se mohl soustředit na klíčové prvky funkcionality. Existují tři věci, které můžete udělat, abyste pomohli svému týmu vývojářů:
- Používat metodologii
agile, aby se omezil časový rámec, ve kterém se tým musí soustředit na klíčové funkce. - Implementovat svou aplikaci jako několik mikroslužeb. To omezí počet zaváděných funkcí a posílí hranice, které udržují kognitivní zátěž během práce.
- Preferujte inkrementální změny před velkými a objemnými, měňte malé části kódu. Používejte skrývání funkcí, abyste realizovali změny, i když nebudou viditelné hned po přidání.
Pokud ve své práci zohledníte princip malosti, váš tým se stane mnohem šťastnějším, lépe se zaměří na realizaci potřebných funkcí a s větší pravděpodobností rychleji zavede kvalitní změny. To ale neznamená, že práce nemůže být složitější; někdy naopak může implementace nových funkcí vyžadovat modifikaci několika služeb, a tento proces může být složitější než v monolitické architektuře. V každém případě stály výhody přístupu malosti za to.
Konec první části.
Brzy zveřejníme druhou část překladu, a zatím čekáme na vaše komentáře a zveme vás na , který se koná již dnes v 20:00.
Zdroj: habr.com
