Pozdravljeni prijatelji. V pričakovanju začetka tečaja , tradicionalno z vami deli prevod uporabnega gradiva.
Programska oprema rešuje vse več vsakodnevnih nalog, hkrati pa postaja vse bolj kompleksna. Kot je nekoč dejal Marc Andressen, požre svet.
Posledično se je način razvoja in dostave aplikacij v zadnjih nekaj letih močno spremenil. To so bili premiki tektonskega obsega, ki so povzročili nabor načel. Ta načela so se izkazala za koristna pri oblikovanju skupine, oblikovanju, razvoju in dostavi vaše aplikacije končnim uporabnikom.
Načela je mogoče povzeti na naslednji način: aplikacija mora biti majhna, spletna in imeti arhitekturo, osredotočeno na razvijalce. Z upoštevanjem teh treh načel lahko ustvarite robustno aplikacijo od konca do konca, ki jo je mogoče hitro in varno dostaviti končnemu uporabniku ter je enostavno prilagodljiva in razširljiva.
Vsako od predlaganih načel ima številne vidike, o katerih bomo razpravljali, da pokažemo, kako vsako načelo prispeva h končnemu cilju, ki je hitra dobava zanesljivih aplikacij, ki jih je enostavno vzdrževati in uporabljati. Načela bomo pogledali v povezavi z njihovimi nasprotji, da bi razjasnili, kaj pomeni, recimo: "Prepričajte se, da uporabljate načelo majhnosti".
Upamo, da vas bo ta članek spodbudil k uporabi predlaganih načel za gradnjo sodobnih aplikacij, ki bodo zagotovile enoten pristop k oblikovanju v kontekstu vedno večjega tehnološkega sklada.
Z uporabo teh načel boste izkoristili najnovejše trende v razvoju programske opreme, vključno z razvoju in dostavi aplikacij, uporabi vsebnikov (npr. ) in ogrodja za orkestracijo vsebnikov (npr. ), uporaba mikrostoritev (vključno z arhitekturo mikrostoritev и za mikrostoritvene aplikacije.
Kaj je sodobna aplikacija?
Sodobne aplikacije? Sodoben sklad? Kaj točno pomeni "moderno"?
Večina razvijalcev ima le splošno predstavo o tem, iz česa je sestavljena sodobna aplikacija, zato je treba ta koncept jasno opredeliti.
Sodobna aplikacija podpira več odjemalcev, ne glede na to, ali gre za uporabniški vmesnik knjižnice React JavaScript, mobilno aplikacijo za Android ali iOS ali aplikacijo, ki se povezuje z drugim API-jem. Sodobna aplikacija pomeni nedoločeno število strank, za katere zagotavlja podatke ali storitve.
Sodobna aplikacija ponuja API za dostop do zahtevanih podatkov in storitev. API mora biti nespremenljiv in konstanten ter ne napisan posebej za določeno zahtevo določenega odjemalca. API je na voljo prek HTTP(S) in omogoča dostop do vseh funkcij, ki so na voljo v GUI ali CLI.
Podatki morajo biti na voljo v splošno sprejetem, interoperabilnem formatu, kot je JSON. API razkrije predmete in storitve na čist, organiziran način, na primer API RESTful ali GraphQL zagotavljata spodoben vmesnik.
Sodobne aplikacije so zgrajene na sodobnem skladu, sodoben sklad pa je sklad, ki podpira takšne aplikacije. Ta sklad omogoča razvijalcu, da preprosto ustvari aplikacijo z vmesnikom HTTP in počisti končne točke API-ja. Izbrani pristop bo vaši aplikaciji omogočil enostavno sprejemanje in pošiljanje podatkov v formatu JSON. Z drugimi besedami, sodoben sklad ustreza elementom Dvanajstfaktorske aplikacije za .
Priljubljene različice te vrste skladov temeljijo na , , , , и . Arhitektura mikrostoritev predstavlja primer sodobnega sklada, implementiranega v vsakem od omenjenih jezikov.
Upoštevajte, da ne zagovarjamo pristopa izključno z mikrostoritvami. Mnogi od vas delate z monoliti, ki se morajo razvijati, medtem ko se drugi ukvarjajo z aplikacijami SOA, ki se širijo in razvijajo v aplikacije mikrostoritev. Spet drugi se usmerjajo k brezstrežniškim aplikacijam, nekateri pa izvajajo kombinacije zgoraj naštetega. Načela, opisana v članku, veljajo za vsakega od teh sistemov z le nekaj manjšimi spremembami.
Načela
Zdaj, ko imamo skupno razumevanje, kaj sta sodobna aplikacija in sodoben sklad, je čas, da se poglobimo v arhitekturo in razvojna načela, ki vam bodo dobro služila pri razvoju, izvajanju in vzdrževanju sodobne aplikacije.
Eno od načel zveni kot "naredi majhne aplikacije", recimo temu načelo majhnosti. Obstajajo neverjetno zapletene aplikacije, ki so sestavljene iz številnih gibljivih delov. Po drugi strani pa izdelava aplikacije iz majhnih, diskretnih komponent olajša načrtovanje, vzdrževanje in delo z njo kot celoto. (Upoštevajte, da smo rekli "poenostavi" in ne "poenostavi").
Drugo načelo je, da lahko povečamo produktivnost razvijalcev tako, da jim pomagamo, da se osredotočijo na funkcije, ki jih razvijajo, hkrati pa jih osvobodimo skrbi glede infrastrukture in CI/CD med izvajanjem. Torej, na kratko, naš pristop osredotočen na razvijalce.
Končno mora biti vse o vaši aplikaciji povezano z omrežjem. V zadnjih 20 letih smo naredili velike korake v smeri omrežne prihodnosti, saj postajajo omrežja hitrejša in aplikacije bolj zapletene. Kot smo že videli, mora sodobno aplikacijo prek omrežja uporabljati veliko različnih odjemalcev. Uporaba omrežnega razmišljanja v arhitekturi ima pomembne prednosti, ki se dobro ujemajo z njo načelo majhnosti in koncept pristopa, usmerjen v razvijalce.
Če boste ta načela upoštevali pri načrtovanju in izvajanju aplikacije, boste imeli nesporno prednost pri razvoju in dostavi vašega izdelka.
Oglejmo si ta tri načela podrobneje.
načelo majhnosti
Človeški možgani težko zaznajo veliko količino informacij hkrati. V psihologiji se izraz kognitivna obremenitev nanaša na skupno količino miselnega napora, ki je potreben za ohranitev informacij v spominu. Zmanjšanje kognitivne obremenitve razvijalcev je prednostna naloga, saj jim omogoča, da se osredotočijo na reševanje problema, namesto da bi v glavi ohranili trenutni zapleteni model celotne aplikacije in funkcij, ki se razvijajo.
Aplikacije se razgradijo zaradi naslednjih razlogov:
- Zmanjšana kognitivna obremenitev razvijalcev;
- Pospešitev in poenostavitev testiranja;
- Hitra dostava sprememb v aplikaciji.
Obstaja več načinov za zmanjšanje kognitivne obremenitve razvijalcev in tu nastopi načelo majhnosti.
Tukaj so torej trije načini za zmanjšanje kognitivne obremenitve:
- Zmanjšajte časovni okvir, ki ga morajo upoštevati pri razvoju nove funkcije – krajši kot je časovni okvir, manjša je kognitivna obremenitev.
- Zmanjšajte količino kode, na kateri se izvaja enkratno delo - manj kode - manj obremenitve.
- Poenostavite postopek postopnega spreminjanja aplikacije.
Zmanjšanje časovnega okvira razvoja
Vrnimo se v čase, ko je metodologija waterfall je bil standard za razvojni proces, časovni okviri od šestih mesecev do dveh let za razvoj ali posodobitev aplikacije pa so bili običajna praksa. Običajno bi inženirji najprej prebrali ustrezne dokumente, kot so zahteve za izdelek (PRD), sistemski referenčni dokument (SRD), arhitekturni načrt, in začeli vse te stvari združevati v en kognitivni model, v skladu s katerim so kodirali. Ker so se spreminjale zahteve in posledično arhitektura, se je bilo treba resno potruditi, da smo celotno ekipo obveščali o posodobitvah kognitivnega modela. Takšen pristop bi lahko v najslabšem primeru preprosto ohromil delo.
Največja sprememba v procesu razvoja aplikacij je bila uvedba agilne metodologije. Ena glavnih značilnosti metodologije agile je ponavljajoč se razvoj. To posledično vodi do zmanjšanja kognitivne obremenitve inženirjev. Namesto da bi od razvojne ekipe zahtevali, da aplikacijo implementira v enem dolgem ciklu, agile pristop vam omogoča, da se osredotočite na majhne količine kode, ki jo je mogoče hitro preizkusiti in uvesti, hkrati pa prejemati povratne informacije. Kognitivna obremenitev aplikacije se je premaknila s šestmesečnega na dvoletni časovni okvir z ogromno količino specifikacij za dvotedenski dodatek ali spremembo funkcije, ki cilja na bolj zamegljeno razumevanje velike aplikacije.
Premik fokusa z obsežne aplikacije na posebne majhne funkcije, ki jih je mogoče dokončati v dvotedenskem šprintu, pri čemer v mislih ni več kot ena funkcija pred naslednjim šprintom, je pomembna sprememba. To nam je omogočilo povečanje razvojne produktivnosti in hkrati zmanjšanje kognitivne obremenitve, ki je nenehno nihala.
V metodologiji agile končna aplikacija naj bi bila nekoliko spremenjena različica prvotnega koncepta, zato je končna točka razvoja nujno dvoumna. Le rezultati posameznega sprinta so lahko jasni in natančni.
Majhne kodne baze
Naslednji korak pri zmanjševanju kognitivne obremenitve je zmanjšanje kodne baze. Sodobne aplikacije so praviloma ogromne - robustna poslovna aplikacija je lahko sestavljena iz tisočev datotek in več sto tisoč vrstic kode. Odvisno od tega, kako so datoteke organizirane, so lahko povezave in odvisnosti med kodo in datotekami očitne ali obratno. Tudi samo izvajanje kode za odpravljanje napak je lahko problematično, odvisno od uporabljenih knjižnic in tega, kako dobro orodja za odpravljanje napak razlikujejo med knjižnicami/paketi/moduli in kodo po meri.
Gradnja delujočega miselnega modela kode aplikacije lahko traja impresivno količino časa in še enkrat predstavlja veliko kognitivno breme za razvijalca. To še posebej velja za monolitne kodne baze, kjer obstaja velika količina kode, katere interakcija med funkcionalnimi komponentami ni jasno definirana, ločevanje predmetov pozornosti pa je pogosto zabrisano, ker se funkcionalne meje ne upoštevajo.
Eden od učinkovitih načinov za zmanjšanje kognitivne obremenitve inženirjev je prehod na arhitekturo mikrostoritev. Pri mikrostoritvenem pristopu se vsaka storitev osredotoča na en sklop funkcij; medtem ko je pomen storitve običajno definiran in razumljiv. Tudi meje storitve so jasne – ne pozabite, da komunikacija s storitvijo poteka prek API-ja, zato je mogoče podatke, ki jih ustvari ena storitev, zlahka posredovati drugi.
Interakcija z drugimi storitvami je običajno omejena na nekaj uporabniških storitev in nekaj storitev ponudnika, ki uporabljajo preproste in čiste klice API-ja, kot je uporaba REST. To pomeni, da je kognitivna obremenitev inženirja resno zmanjšana. Največji izziv ostaja razumevanje modela interakcije storitev in kako se stvari, kot so transakcije, zgodijo v več storitvah. Posledično uporaba mikrostoritev zmanjša kognitivno obremenitev z zmanjšanjem količine kode, definiranjem jasnih meja storitev in zagotavljanjem razumevanja odnosa med uporabniki in ponudniki.
Majhne postopne spremembe
Zadnji element načela majhnost je upravljanje sprememb. Za razvijalce je posebna skušnjava, da pogledajo bazo kode (celo morda svojo, starejšo kodo) in rečejo: "To je sranje, vse moramo napisati na novo." Včasih je to prava odločitev, včasih pa ne. Breme globalne spremembe modela nalaga razvojni ekipi, kar posledično vodi do velike kognitivne obremenitve. Bolje je, da se inženirji osredotočijo na spremembe, ki jih lahko naredijo med šprintom, tako da lahko pravočasno, čeprav postopoma, uvedejo potrebno funkcionalnost. Končni izdelek naj bo podoben vnaprej načrtovanemu, vendar z nekaj modifikacijami in testiranji glede na potrebe naročnika.
Pri prepisovanju velikih delov kode včasih ni mogoče hitro izvesti spremembe, ker pridejo v poštev druge odvisnosti sistema. Če želite nadzorovati tok sprememb, lahko uporabite skrivanje funkcij. Načeloma to pomeni, da je funkcionalnost v izdelavi, vendar ni na voljo z nastavitvami spremenljivke okolja (env-var) ali kakšnim drugim konfiguracijskim mehanizmom. Če je koda prestala vse procese nadzora kakovosti, lahko konča v proizvodnji v latentnem stanju. Vendar ta strategija deluje le, če je funkcija sčasoma omogočena. V nasprotnem primeru bo kodo samo obremenilo in dodalo kognitivno obremenitev, s katero se bo razvijalec moral ukvarjati, da bo produktiven. Upravljanje sprememb in postopne spremembe same po sebi pomagajo ohranjati obvladljivo kognitivno delovno obremenitev razvijalcev.
Inženirji morajo premagati številne težave že s preprosto uvedbo dodatnih funkcionalnosti. S strani vodstva bi bilo smotrno zmanjšati nepotrebno obremenitev ekipe, da bi se lahko osredotočila na ključne funkcionalne elemente. Svoji razvojni skupini lahko pomagate s tremi stvarmi:
- Uporabite metodologijo
agileomejiti časovni okvir, v katerem se mora ekipa osredotočiti na ključne značilnosti. - Implementirajte svojo aplikacijo kot več mikrostoritev. To bo omejilo število funkcij, ki jih je mogoče implementirati, in okrepilo meje, ki ohranjajo kognitivno obremenitev pri delu.
- Dajte prednost postopnim spremembam kot velikim in okornim, spremenite majhne dele kode. Uporabite skrivanje funkcij za izvajanje sprememb, tudi če ne bodo vidne takoj po dodajanju.
Če boste pri svojem delu uporabili načelo majhnosti, bo vaša ekipa veliko srečnejša, bolje osredotočena na implementacijo potrebnih funkcij in bolj verjetno bo hitreje uvedla kvalitativne spremembe. Toda to ne pomeni, da delo ne more postati bolj zapleteno, včasih, nasprotno, uvedba nove funkcionalnosti zahteva spremembo več storitev in ta proces je lahko težji od podobnega v monolitni arhitekturi. V vsakem primeru so prednosti pristopa majhnosti vredne.
Konec prvega dela.
Kmalu bomo objavili drugi del prevoda, zdaj pa pričakujemo vaše komentarje in vas vabimo k temu , ki bo danes ob 20.00.
Vir: www.habr.com