Dobrý deň, priatelia. V očakávaní spustenia kurzu , už tradične sa s vami podelíme o preklad užitočného materiálu.
Softvér rieši čoraz viac každodenných problémov, pričom sa stáva čoraz zložitejším. Ako raz povedal Marc Andreessen, pohlcuje svet.
Výsledkom je, že spôsob, akým sú aplikácie vyvíjané a dodávané, sa za posledných pár rokov dramaticky zmenil. Boli to posuny na tektonickom meradle, ktoré vyústili do súboru princípov. Tieto princípy sa ukázali ako užitočné pri budovaní tímu, navrhovaní, vývoji a poskytovaní vašej aplikácie koncovým používateľom.
Princípy možno zhrnúť takto: aplikácia musí byť malá, webová a musí mať architektúru zameranú na vývojárov. Na základe týchto troch princípov môžete vytvoriť robustnú, komplexnú aplikáciu, ktorá môže byť rýchlo a bezpečne doručená koncovému používateľovi a je ľahko škálovateľná a rozšíriteľná.
Každý z navrhovaných princípov má množstvo aspektov, o ktorých budeme diskutovať, aby sme ukázali, ako každý princíp prispieva ku konečnému cieľu rýchleho poskytovania spoľahlivých aplikácií, ktoré sa ľahko udržiavajú a používajú. Pozrieme sa na princípy v porovnaní s ich protikladmi, aby sme objasnili, čo znamená povedať: „Uisti sa, že používaš princíp malosti".
Dúfame, že tento článok vás povzbudí, aby ste použili navrhované princípy na vytváranie moderných aplikácií, ktoré poskytnú jednotný dizajnový prístup v kontexte neustále rastúceho technologického balíka.
Aplikovaním týchto princípov zistíte, že využijete najnovšie trendy vo vývoji softvéru, vrátane na vývoj a dodávanie aplikácií, používanie kontajnerov (napr. ) a rámce orchestrácie kontajnerov (napr. ), používanie mikroslužieb (vrátane architektúry mikroslužieb и pre mikroservisné aplikácie.
Čo je moderná aplikácia?
Moderné aplikácie? Moderný zásobník? Čo presne znamená „moderné“?
Väčšina vývojárov má len základné znalosti o tom, z čoho pozostáva moderná aplikácia, preto je potrebné tento pojem jasne definovať.
Moderná aplikácia podporuje viacero klientov, či už ide o používateľské rozhranie využívajúce knižnicu React JavaScript, mobilnú aplikáciu pre Android alebo iOS alebo aplikáciu, ktorá sa s inou pripája cez API. Moderná aplikácia zahŕňa neurčitý počet 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 konštantné a nemalo by byť napísané špeciálne pre konkrétnu požiadavku od konkrétneho klienta. Rozhranie API je dostupné cez HTTP(S) a poskytuje prístup ku všetkým funkciám nachádzajúcim sa v GUI alebo CLI.
Údaje musia byť dostupné v bežnom interoperabilnom formáte, ako je JSON. Rozhranie API odhaľuje objekty a služby v jasnej, organizovanej forme; napríklad RESTful API alebo GraphQL poskytujú slušné rozhranie.
Moderné aplikácie sú postavené na modernom zásobníku a moderný zásobník je zásobník, ktorý podporuje takéto aplikácie, resp. Tento zásobník umožňuje vývojárom jednoducho vytvoriť aplikáciu s rozhraním HTTP a jasnými koncovými bodmi API. Prístup, ktorý zvolíte, umožní vašej aplikácii jednoducho prijímať a odosielať údaje vo formáte JSON. Inými slovami, moderný zásobník zodpovedá prvkom aplikácie Twelve-Factor Application for .
Populárne verzie tohto typu zásobníka sú založené na , , , , и . Architektúra mikroservisov predstavuje príklad moderného zásobníka implementovaného v každom z uvedených jazykov.
Upozorňujeme, že nepodporujeme čisto mikroslužby. Mnohí z vás pracujú s monolitmi, ktoré sa musia vyvíjať, zatiaľ čo iní sa zaoberajú aplikáciami SOA, ktoré sa rozširujú a vyvíjajú, aby sa stali aplikáciami mikroslužieb. Ešte iní smerujú k aplikáciám bez servera a niektoré implementujú kombinácie vyššie uvedeného. Princípy uvedené v tomto článku platia pre každý z týchto systémov len s niekoľkými malými úpravami.
Zásady
Teraz, keď máme základné znalosti o tom, čo sú moderná aplikácia a moderný zásobník, je čas ponoriť sa do architektúry a princípov dizajnu, ktoré vám dobre poslúžia pri navrhovaní, implementácii a údržbe modernej aplikácie.
Jedným z princípov je „vytvárať malé aplikácie“, nazvime to princíp malosti. Existujú neuveriteľne zložité aplikácie, ktoré majú veľa pohyblivých častí. Vytvorenie aplikácie z malých, diskrétnych komponentov zase uľahčuje celkový dizajn, údržbu a používanie. (Všimnite si, že sme povedali „urobí to jednoduchým“ a nie „urobí to jednoduchým“).
Druhým princípom je, že môžeme zvýšiť produktivitu vývojárov tým, že im pomôžeme sústrediť sa na funkcie, ktoré vyvíjajú, a zároveň ich oslobodíme od starostí s infraštruktúrou a CI/CD počas implementácie. Takže v skratke náš prístup orientovaný na vývojárov.
Nakoniec všetko o vašej aplikácii musí byť pripojené k sieti. Za posledných 20 rokov sme výrazne pokročili smerom k zosieťovanej budúcnosti, keďže siete sa zrýchlili a aplikácie sa stali zložitejšími. Ako sme už videli, modernú aplikáciu musí používať v sieti veľa rôznych klientov. Aplikácia sieťového myslenia na architektúru má významné výhody, ktoré sa k nej hodia princíp malosti a koncepcia prístupu, orientovaný na vývojárov.
Ak budete mať tieto princípy na pamäti pri navrhovaní a implementácii aplikácie, budete mať výraznú výhodu pri vývoji a dodávaní vášho produktu.
Pozrime sa na tieto tri princípy podrobnejšie.
Princíp malosti
Pre ľudský mozog je ťažké vnímať veľké množstvo informácií naraz. V psychológii pojem kognitívna záťaž označuje celkové množstvo duševného úsilia potrebného na uchovanie informácií v pamäti. Zníženie kognitívnej záťaže vývojárov je prioritou, pretože sa potom môžu sústrediť na riešenie problému namiesto toho, aby v hlave držali súčasný komplexný model celej aplikácie a vyvíjaných funkcií.
Aplikácie sú rozložené z nasledujúcich dôvodov:
- Zníženie kognitívnej záťaže vývojárov;
- zrýchlenie a zjednodušenie testovania;
- Rýchle dodanie zmien do aplikácie.
Existuje niekoľko spôsobov, ako znížiť kognitívnu záťaž vývojárov, a práve tu vstupuje do hry princíp malosti.
Takže tri spôsoby, ako znížiť kognitívnu záťaž:
- Znížte časový rámec, ktorý musia zohľadniť pri vývoji novej funkcie – čím kratší časový rámec, tým nižšie kognitívne zaťaženie.
- Znížte množstvo kódu, na ktorom sa súčasne pracuje – menej kódu – menšie zaťaženie.
- Zjednodušte proces vykonávania postupných zmien vo vašej aplikácii.
Znížené časové rámce vývoja
Vráťme sa do čias, kedy metodika waterfall bol štandardom pre proces vývoja a časové rámce od šiestich mesiacov do dvoch rokov na vývoj alebo aktualizáciu aplikácie boli bežnou praxou. Inžinieri by si zvyčajne najskôr prečítali príslušné dokumenty, ako sú požiadavky na produkt (PRD), systémový referenčný dokument (SRD), plán architektúry a začali všetky tieto veci integrovať do jedného kognitívneho modelu, podľa ktorého napísali kód. Keďže požiadavky a teda aj architektúra sa menili, bolo potrebné vyvinúť značné úsilie, aby bol celý tím informovaný o aktualizáciách kognitívneho modelu. V najhoršom prípade by tento prístup mohol jednoducho paralyzovať prácu.
Najväčšou zmenou v procese vývoja aplikácie bolo zavedenie agilnej metodiky. Jedna z hlavných čŕt metodiky agile - Toto je iteračný vývoj. To zase vedie k zníženiu kognitívnej záťaže inžinierov. Namiesto toho, aby vývojový tím vyžadoval implementáciu aplikácie v jednom dlhom cykle, agile Tento prístup vám umožňuje zamerať sa na malé množstvá kódu, ktoré možno rýchlo otestovať a nasadiť a zároveň získať spätnú väzbu. Kognitívna záťaž aplikácie sa posunula z časového rámca šiestich mesiacov na dva roky, s obrovským množstvom špecifikácií, na dvojtýždňové pridanie alebo zmenu funkcií so zameraním na difúznejšie pochopenie veľkej aplikácie.
Presunutie zamerania z masívnej aplikácie na špecifické malé funkcie, ktoré je možné dokončiť v dvojtýždňovom sprinte, s výhľadom dopredu na nie viac ako jednu funkciu z nasledujúceho sprintu je významnou zmenou. To umožnilo zvýšiť produktivitu vývoja a zároveň znížiť kognitívnu záťaž, ktorá neustále kolísala.
V metodológii agile Očakáva sa, že konečná aplikácia bude mierne upravená verzia pôvodného konceptu, takže konečný vývojový bod je nevyhnutne nejednoznačný. Iba výsledky každého konkrétneho šprintu môžu byť jasné a presné.
Malé kódové základne
Ďalším krokom pri znižovaní kognitívnej záťaže je redukcia kódovej základne. Moderné aplikácie sú zvyčajne masívne – robustná podniková aplikácia môže pozostávať z tisícok súborov a stoviek tisíc riadkov kódu. V závislosti od organizácie súborov môžu alebo nemusia byť zrejmé prepojenia a závislosti medzi kódom a súbormi. Dokonca aj ladenie samotného vykonávania kódu môže byť problematické v závislosti od použitých knižníc a od toho, ako dobre ladiace nástroje rozlišujú medzi knižnicami/balíkmi/modulmi a používateľským kódom.
Vytvorenie funkčného mentálneho modelu kódu aplikácie môže trvať značné množstvo času, čo opäť predstavuje veľkú kognitívnu záťaž na vývojára. To platí najmä pre monolitické kódové základne, kde existuje veľké množstvo kódu, interakcie medzi funkčnými komponentmi nie sú jasne definované a rozdelenie zamerania je často nejasné, pretože sa nerešpektujú funkčné hranice.
Jedným z účinných spôsobov, ako znížiť kognitívne zaťaženie inžinierov, je prejsť na architektúru mikroslužieb. V mikroservisnom prístupe sa každá služba zameriava na jeden súbor funkcií; význam služby je zvyčajne definovaný a zrozumiteľný. Hranice služby sú tiež jasné – pamätajte, že komunikácia so službou prebieha pomocou API, takže dáta generované jednou službou možno ľahko preniesť do inej.
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 čisté volania API, ako napríklad REST. To znamená, že kognitívne zaťaženie inžiniera je výrazne znížené. Najväčšou výzvou zostáva pochopenie modelu interakcie so službami a toho, ako sa veci ako transakcie dejú vo viacerých službách. V konečnom dôsledku používanie mikroslužieb znižuje kognitívnu záťaž znížením množstva kódu, definovaním jasných hraníc služieb a poskytnutím prehľadu o vzťahu medzi používateľom a poskytovateľom.
Malé postupné zmeny
Posledný prvok princípu málo je riadenie zmien. Pre vývojárov je obzvlášť lákavé pozrieť sa na kódovú základňu (dokonca možno aj na ich vlastný, starší kód) a povedať si: "Toto je svinstvo, musíme to celé prepísať." Niekedy je to správne rozhodnutie a niekedy nie. Na vývojový tím kladie bremeno globálnych zmien modelu, čo následne vedie k masívnej kognitívnej záťaži. Pre inžinierov je lepšie zamerať sa na zmeny, ktoré môžu urobiť počas sprintu, aby potom mohli včas, aj keď postupne, zaviesť potrebnú funkcionalitu. Finálny produkt by sa mal podobať na vopred naplánovaný produkt, avšak s určitými úpravami a testovaním, aby vyhovoval potrebám klienta.
Pri prepisovaní veľkých častí kódu je niekedy nemožné rýchlo dodať zmenu, pretože do hry vstupujú iné systémové závislosti. Ak chcete riadiť tok zmien, môžete použiť skrytie funkcií. V zásade to znamená, že funkcia je v produkcii, ale nie je dostupná prostredníctvom nastavení premenných prostredia (env-var) alebo iného konfiguračného mechanizmu. Ak kód prešiel všetkými procesmi kontroly kvality, môže skončiť vo výrobe v skrytom stave. Táto stratégia však funguje iba vtedy, ak je funkcia nakoniec povolená. V opačnom prípade to len zahltí kód a pridá kognitívnu záťaž, s ktorou sa bude musieť vývojár vyrovnať, aby bol produktívny. Riadenie zmien a prírastkové zmeny samotné pomáhajú udržiavať kognitívnu záťaž vývojárov na dostupnej úrovni.
Inžinieri musia prekonať mnohé ťažkosti aj pri jednoduchej implementácii dodatočných funkcií. Bolo by rozumné, aby manažment znížil zbytočnú pracovnú záťaž tímu, aby sa mohol sústrediť na kľúčové prvky funkčnosti. Existujú tri veci, ktoré môžete urobiť, aby ste pomohli svojmu vývojovému tímu:
- Použite metodiku
agile, aby sa obmedzil časový rámec, v ktorom sa tím musí sústrediť na kľúčové funkcie. - Implementujte svoju aplikáciu ako niekoľko mikroslužieb. To obmedzí počet zavedených funkcií a posilní hranice, ktoré obsahujú kognitívnu záťaž pri práci.
- Uprednostňujte postupné zmeny pred veľkými, nepraktickými, zmeňte malé kúsky kódu. Použite skrytie funkcií na implementáciu zmien, aj keď nebudú viditeľné ihneď po ich pridaní.
Ak vo svojej práci uplatníte princíp malosti, váš tím bude oveľa šťastnejší, lepšie zameraný na poskytovanie potrebných funkcií a s väčšou pravdepodobnosťou rýchlejšie zavedie zmeny kvality. To však neznamená, že sa práca nemôže stať zložitejšou, niekedy si naopak zavedenie novej funkcionality vyžaduje úpravu viacerých služieb a tento proces môže byť zložitejší ako podobný v monolitickej architektúre. V každom prípade výhody používania tohto prístupu mierne stoja za to.
Koniec prvej časti.
Čoskoro zverejníme druhú časť prekladu, no už teraz čakáme na vaše pripomienky a pozývame vás , ktorý sa uskutoční dnes o 20.00 hod.
Zdroj: hab.com