Ahojte, priatelia. Pred spustením kurzu , tradične sa s vami delíme o preklad užitočného materiálu.
Softvér rieši čoraz viac každodenných úloh, pričom sa stáva stále zložitejším. Ako raz povedal Marc Andreessen, pohltí svet.
V dôsledku toho sa v posledných rokoch prístupy k vývoju a dodávaniu aplikácií vážne zmenili. Boli to posuny tektonického rozsahu, ktoré viedli k vzniku súboru princípov. Tieto princípy sa ukázali ako užitočné pri formovaní tímov, navrhovaní, vývoji a doručovaní vašich aplikácií koncovým používateľom.
Princípy môžu byť zhrnuté nasledovne: aplikácia by mala byť malá, sieťová a mať architektúru orientovanú na vývojára. Opierajúc sa o tieto tri princípy, môžete vytvoriť robustnú, komplexnú aplikáciu, ktorú môžete rýchlo a bezpečne doručiť koncovému používateľovi a zároveň je ľahko škálovateľná a rozšíriteľná.
Každý z navrhovaných princípov má množstvo aspektov, ktoré sa pokúsime preskúmať, aby sme ukázali, ako každý princíp prispieva k dosiahnutiu konečného cieľa, ktorým je rýchle dodanie spoľahlivých aplikácií, ktoré sú jednoduché na údržbu a používanie. Budeme skúmať princípy v porovnaní s ich protikladmi, aby sme objasnili, čo znamená, povedzme, "Uistite sa, že používate princíp malosti».
Dúfame, že tento článok vás podnieti k tomu, aby ste používali navrhované princípy výstavby moderných aplikácií, ktoré poskytnú jednotný prístup k navrhovaniu v kontexte neustále rastúceho technického stacku.
Aplikovaním týchto princípov zistíte, že sa držíte najnovších trendov vo vývoji softvéru, vrátane prístupu k vývoju a dodávaniu aplikácií, využívanie kontajnerov (napríklad, ) a rámcov pre orchestráciu kontajnerov (napríklad, ), využívanie mikroslužieb (vrátane Mikroslužbovej Architektúry a pre mikroslužbové aplikácie.
Čo je moderná aplikácia?
Moderné aplikácie? Moderný stack? Čo vlastne znamená „moderný"?
Väčšina vývojárov má len všeobecnú predstavu o tom, čo tvorí modernú aplikáciu, preto je potrebné poskytnúť jasnú definíciu tohto pojmu.
Moderná aplikácia podporuje viacerých klientov, či už je to používateľské rozhranie na knižnici JavaScript React, mobilná aplikácia pre Android alebo iOS, alebo aplikácia, ktorá sa spája s inou prostredníctvom API. Moderná aplikácia predpokladá existenciu neobmedzeného počtu klientov, pre ktorých poskytuje dáta alebo služby.
Moderná aplikácia poskytuje API na prístup k požadovaným údajom a službám. API by malo byť nemenné a trvalé, a nie napísané špecificky na konkrétnu požiadavku z nejakého konkrétneho klienta. API je dostupné cez HTTP(S) a poskytuje prístup ku všetkým funkciám, ktoré sú k dispozícii v GUI alebo CLI.
Údaje by mali byť dostupné v bežnom, kompatibilnom formáte, ako je JSON. API poskytuje objekty a služby v zrozumiteľnej, usporiadanej forme, napríklad RESTful API alebo GraphQL poskytujú vyhovujúce rozhranie.
Moderné aplikácie sú postavené na modernom stacku, a moderný stack je ten stack, ktorý podporuje takéto aplikácie. Takýto stack umožňuje vývojárovi ľahko vytvoriť aplikáciu s HTTP rozhraním a jasnými koncovými bodmi API. Zvolený prístup umožní vašej aplikácii ľahko prijímať a posielať dáta vo formáte JSON. Inými slovami, moderný stack zodpovedá prvkom Dvanástich faktorov aplikácie pre .
Populárne verzie tohto typu stacku sú založené na , , , , a . Architektúra mikroslužieb je príkladom moderného stacku realizovaného v každom z uvedených jazykov.
Všimnite si, že nepropagujeme výlučne mikroslužobný prístup. Mnohí z vás pracujú s monolitmi, ktoré sa musia rozvíjať, zatiaľ čo iní sa zaoberajú aplikáciami SOA, ktoré sa rozširujú a vyvíjajú na mikroslužobné aplikácie. Tí tretí smerujú k nasadeniu bezserverových aplikácií a niektorí implementujú kombinácie z uvedeného. Princípy uvedené v článku sú aplikovateľné na každú z týchto systémov len s niekoľkými drobnými zmenami.
Principy
Teraz, keď sme dosiahli spoločné porozumenie toho, čo je moderná aplikácia a moderný stack, nastal čas ponoriť sa do princípov architektúry a vývoja, ktoré vám dobre poslúžia pri vývoji, implementácii a podpore modernej aplikácie.
Jeden z princípov znie ako „vytvárajte malé aplikácie“, nechajme to jednoducho nazvať princípom malosti. Existujú neuveriteľne zložité aplikácie, ktoré sa skladajú z veľkého množstva pohyblivých komponentov. Na druhej strane, budovanie aplikácie z malých diskrétnych komponentov zjednodušuje jej návrh, údržbu a celkovú prácu s ňou. (Všimnite si, že sme povedali „zjednodušuje“, a nie „robí jednoduchým“).
Druhý princíp spočíva v tom, že môžeme zvýšiť produktivitu vývojárov tým, že im pomáhame sústrediť sa na funkcie, ktoré vyvíjajú, pričom ich zbavujeme starostí o infraštruktúru a CI/CD počas implementácie. Takže, v skratke, náš prístup je zameraný na vývojárov.
Nakoniec, všetko, čo sa týka vašej aplikácie, by malo byť pripojené k sieti. V posledných 20 rokoch sme sa výrazne posunuli k sieťovej budúcnosti, pretože siete sa stali rýchlejšími a aplikácie zložitejšími. Ako sme už zistili, moderná aplikácia musí byť používaná cez sieť mnohými rôznymi klientmi. Použitie sieťového myslenia v architektúre má významné výhody, ktoré dobre zapadajú do princípom malosti a konceptu prístupu, zameraného na vývojárov.
Ak si pri vývoji a implementácii aplikácie zapamätáte uvedené princípy, budete mať nepochybné výhody pri vývoji a dodávaní svojho produktu.
Poďme sa na tieto tri princípy pozrieť podrobnejšie.
Princíp malosti
Ľudskému mozgu robí problém naraz prijímať veľké množstvo informácií. V psychológii pojem kognitívna záťaž znamená celkové množstvo mentálnych námahy potrebných na uchovanie informácií v pamäti. Zníženie kognitívnej záťaže na vývojárov je prioritou, pretože v takom prípade sa môžu sústrediť na riešenie problému, namiesto toho, aby si v hlave udržiavali aktuálny komplexný model celej aplikácie a vyvíjaných funkcií.
Aplikácie sú rozdelené z nasledujúcich dôvodov:
- Zníženie kognitívneho zaťaženia pre vývojárov;
- Rýchlejšie a jednoduchšie testovanie;
- Rýchla dodávka zmien v aplikácii.
Existuje niekoľko spôsobov, ako znížiť kognitívne zaťaženie pre vývojárov, a tu vstupuje do hry princíp malosti.
Takže tri spôsoby zníženia kognitívneho zaťaženia:
- Zmenšiť časový rámec, ktorý musia zohľadniť pri vývoji novej funkcie – čím je časový rámec kratší, tým je kognitívne zaťaženie nižšie.
- Znížiť množstvo kódu, nad ktorým sa pracuje naraz – menej kódu, menej zaťaženia.
- Zjednodušiť proces vykonávania inkrementálnych zmien v aplikácii.
Zníženie časových rámcov vývoja
Vráťme sa do čias, keď metodológia waterfall bola štandardom pre proces vývoja a časové rámce od šiestich mesiacov do dvoch rokov pre vývoj alebo aktualizáciu aplikácie boli bežnou praxou. Zvyčajne najprv inžinieri čítali príslušné dokumenty, ako sú požiadavky na produkt (PRD), referenčný dokument systému (SRD), plán architektúry a začínali spájať všetky tieto veci do jednej kognitívnej modelu, podľa ktorej písali kód. Ako sa meniace požiadavky a architektúra museli zamýšľať vážne úsilie by informovať celý tím o aktualizáciách kognitívnej modelu. Takýto prístup mohol v najhoršom prípade jednoducho paralyzovať prácu.
Najväčšou zmenou v procese vývoja aplikácií sa stalo zavedenie metodológie agile. Jedným z hlavných rysov metodológie agile je iteratívny vývoj. To vedie k zníženiu kognitívneho zaťaženia pre inžinierov. Namiesto toho, aby sa od tímu vývojárov vyžadovalo implementovať aplikáciu v jednom dlhom cykle, agile prístup umožňuje sústrediť sa na malé objemy kódu, ktoré môžu byť rýchlo testované a nasadené, pričom sa tiež získava spätná väzba. Kognitívne zaťaženie aplikácie sa posunulo z časového rámca od šiestich mesiacov do dvoch rokov s ohľadom na obrovské množstvo špecifikácií na dvojtýždňové pridanie alebo zmeny funkcií, zamerané na menej jasné porozumenie väčšej aplikácii.
Zmenenie zamerania z masívnej aplikácie na konkrétne malé funkcie, ktoré môžu byť dokončené v dvojtýždňovom sprinte, s pohľadom dopredu len na jednu funkciu z nasledujúceho sprintu je významná zmena. Toto umožnilo zvýšiť produktivitu vývoja, pričom sa znižovalo kognitívne zaťaženie, ktoré sa neustále menilo.
V metodológii agile sa predpokladá, že konečná aplikácia bude trochu zmenenou verziou pôvodnej koncepcie, takže konečný bod vývoja je nevyhnutne nejednoznačný. Jasné a presné môžu byť iba výsledky jednotlivých spintov.
Malé kódové základy
Ďalším krokom v znížení kognitívneho zaťaženia je zníženie veľkosti kódovej základne. Moderné aplikácie sú zvyčajne masívne – spoľahlivá, podniková aplikácia môže pozostávať z tisícov súborov a stovkami tisíc riadkov kódu. V závislosti od organizácie súborov môžu byť vzťahy a závislosti kódu a súborov na jednej strane jasné alebo naopak. Dokonca aj ladenie samotného vykonávania kódu môže vyvolávať problémy v závislosti od použitých knižníc a toho, ako dobre nástroje na ladenie delimitujú knižnice/pakety/moduly a používateľský kód.
Vybudovanie funkčného mentálneho modelu kódu aplikácie môže zabrať značné množstvo času a opäť uložiť na vývojára veľké kognitívne zaťaženie. To je obzvlášť charakteristické pre monolitické bázy kódu, kde je veľké množstvo kódu a interakcie medzi funkčnými komponentmi nie sú jasne definované, pričom rozdelenie pozornosti je často rozmazané, pretože nie sú dodržané funkčné hranice.
Jedným z efektívnych spôsobov, ako znížiť kognitívne zaťaženie inžinierov, je prechod na mikroservisnú architektúru. V mikroservisnom prístupe sa každý servis sústreďuje na jeden súbor funkcií; zmysel servisu je zvyčajne definovaný a zrozumiteľný. Hranice servisu sú tiež jasné – pamätajte na to, že komunikácia so servisom sa uskutočňuje pomocou API, takže dáta generované jedným servisom môžu byť jednoducho prenesené do iného.
Interakcia s inými službami je zvyčajne obmedzená na niekoľko používateľských služieb a niekoľko služieb poskytovateľa, ktoré používajú jednoduché a jasné API volania, napríklad prostredníctvom REST. To znamená, že kognitívna záťaž na inžiniera je výrazne znížená. Najzložitejšou úlohou zostáva pochopenie modelu interakcie služieb a toho, ako sa také veci ako transakcie dejú v niekoľkých službách. Nakoniec používanie mikroservisov znižuje kognitívnu záťaž, znižuje množstvo kódu, stanovuje jasné hranice služby a zabezpečuje pochopenie vzťahov medzi používateľmi a poskytovateľmi.
Malé inkrementálne zmeny
Posledný prvok princípu maličkosti – je to riadenie zmien. Špeciálnym pokušením pre vývojárov je pozrieť sa na kódovú bázu (možno aj na vlastný, starší kód) a vyhlásiť: „To je hrozné, musíme to všetko prepísať.“ Niekedy je to správne rozhodnutie, a niekedy nie. Narušuje to tím vývojárov bremenom globálnej zmeny modelu, čo na oplátku vedie k rozsiahlej kognitívnej záťaži. Lepšie je, ak sa inžinieri zameriavajú na zmeny, ktoré môžu uskutočniť počas sprintu, aby potom v pravý čas uviedli potrebnú funkcionalitu, aj keby to bolo postupne. Konečný produkt by mal pripomínať predbežne plánovaný, ale s niektorými zmenami a testovaním, aby vyhovel potrebám zákazníka.
Pri prepise veľkých častí kódu sa niekedy rýchla implementácia zmien ukáže ako nemožná, keďže vstupujú do hry iné závislosti systému. Aby sa kontroloval tok zmien, môže sa využiť skrytie funkcií (feature hiding). V princípe to znamená, že funkcia je na produkcii, ale nie je prístupná prostredníctvom nastavení premenných prostredia (env-var) alebo nejakého iného konfiguračného mechanizmu. Ak kód prejde všetkými procesmi kontroly kvality, môže sa ocitnúť v produkcii v skrytom stave. Avšak táto stratégia funguje iba vtedy, ak bude funkcia nakoniec povolená. V opačnom prípade len zamieňa kód a pridáva kognitívnu záťaž, ktorú musia vývojári zvládnuť na efektívnu prácu. Riadenie zmien a inkrementálne zmeny samy o sebe pomáhajú udržiavať kognitívnu záťaž vývojárov na prijateľnej úrovni.
Inžinieri sa musia vysporiadať s množstvom zložitostí aj pri jednoduchom zavedení dodatočnej funkčnosti. Z pohľadu vedenia by bolo rozumné znížiť zbytočnú záťaž na tím, aby sa mohol sústrediť na kľúčové prvky funkčnosti. Existujú tri veci, ktoré môžete urobiť, aby ste pomohli svojmu tímu vývojárov:
- Použiť metodológiu
agile, aby sa obmedzili časové rámce, v ktorých sa tím musí sústrediť na kľúčové funkcie. - Zrealizovať svoju aplikáciu ako niekoľko mikroslužieb. To obmedzí počet implementovaných funkcií a posilní hranice, ktoré udržiavajú kognitívnu záťaž počas práce.
- Preferujte inkrementálne zmiany pred veľkými a robustnými, upravujte malé časti kódu. Používajte skrytie funkcií na implementáciu zmien, aj keď nebudú viditeľné hneď po pridaní.
Ak použijete vo svojej práci princíp malosti, váš tím bude oveľa šťastnejší, lepšie sa zameria na realizáciu potrebných funkcií a s väčšou pravdepodobnosťou rýchlejšie zavádza kvalitné zmeny. Ale to neznamená, že práca nemôže byť zložitá; niekedy naopak, zavedenie novej funkcionality vyžaduje modifikáciu niekoľkých služieb a tento proces môže byť náročnejší ako podobný v monolitickej architektúre. V každom prípade stoja výhody aplikácie prístupu malosti za to.
Koniec prvej časti.
Čoskoro zverejníme druhú časť prekladu, a zatiaľ čakáme na vaše komentáre a pozývame vás na , ktorý sa uskutoční už dnes o 20:00.
Zdroj: habr.com
