Zdravo prijatelji. U iščekivanju pokretanja kursa , tradicionalno s vama dijelimo prijevod korisnog materijala.
Softver rješava sve više svakodnevnih problema, a istovremeno postaje sve složeniji. Kao što je Marc Andreessen jednom rekao, proždire svijet.
Kao rezultat toga, način na koji se aplikacije razvijaju i isporučuju dramatično se promijenio u posljednjih nekoliko godina. To su bili pomaci na tektonskoj skali koji su rezultirali nizom principa. Ovi principi su se pokazali korisnima u izgradnji tima, dizajniranju, razvoju i isporuci vaše aplikacije krajnjim korisnicima.
Principi se mogu sažeti na sljedeći način: aplikacija mora biti mala, web-bazirana i imati arhitekturu usmjerenu na programere. Gradeći na ova tri principa, možete kreirati robusnu, end-to-end aplikaciju koja se može brzo i sigurno isporučiti krajnjem korisniku, te je lako skalabilna i proširiva.
Svaki od predloženih principa ima niz aspekata o kojima ćemo raspravljati kako bismo pokazali kako svaki princip doprinosi krajnjem cilju brzog pružanja pouzdanih aplikacija koje se lako održavaju i koriste. Pogledat ćemo principe u poređenju sa njihovim suprotnostima kako bismo razjasnili šta znači reći: „Obavezno koristite princip malenosti".
Nadamo se da će vas ovaj članak ohrabriti da koristite predložene principe za izgradnju modernih aplikacija koje će pružiti jedinstven pristup dizajnu u kontekstu sve većeg tehnološkog niza.
Primjenom ovih principa otkrit ćete da koristite prednosti najnovijih trendova u razvoju softvera, uključujući i za razvoj i isporuku aplikacija, korištenje kontejnera (npr. ) i okviri orkestracije kontejnera (na primjer, ), korištenje mikroservisa (uključujući mikroservisnu arhitekturu и za mikroservisne aplikacije.
Šta je moderna aplikacija?
Moderne aplikacije? Moderni steck? Šta tačno znači "moderno"?
Većina programera ima samo osnovno razumijevanje od čega se sastoji moderna aplikacija, pa je potrebno jasno definirati ovaj koncept.
Moderna aplikacija podržava više klijenata, bilo da se radi o korisničkom interfejsu koji koristi React JavaScript biblioteku, mobilnoj aplikaciji za Android ili iOS ili aplikaciji koja se povezuje na drugu preko API-ja. Moderna aplikacija podrazumijeva neograničen broj klijenata za koje pruža podatke ili usluge.
Moderna aplikacija pruža API za pristup traženim podacima i uslugama. API bi trebao biti nepromjenjiv i konstantan, a ne napisan posebno za određeni zahtjev određenog klijenta. API je dostupan preko HTTP(S) i pruža pristup svim funkcijama koje se nalaze u GUI ili CLI.
Podaci moraju biti dostupni u uobičajenom, interoperabilnom formatu kao što je JSON. API izlaže objekte i usluge u jasnom, organiziranom obliku; na primjer, RESTful API ili GraphQL pružaju pristojan interfejs.
Moderne aplikacije su izgrađene na modernom steku, a moderan stek je stog koji podržava takve aplikacije. Ovaj stog omogućava programeru da lako kreira aplikaciju sa HTTP interfejsom i čistim API krajnjim tačkama. Pristup koji odaberete omogućit će vašoj aplikaciji da lako prihvati i pošalje podatke u JSON formatu. Drugim riječima, moderni stek odgovara elementima Twelve-Factor Application for .
Popularne verzije ove vrste steka zasnovane su na , , , , и . Mikroservisna arhitektura predstavlja primjer modernog steka implementiranog na svakom od navedenih jezika.
Imajte na umu da ne zagovaramo pristup isključivo mikroservisima. Mnogi od vas rade sa monolitima koji treba da se razvijaju, dok se drugi bave SOA aplikacijama koje se šire i razvijaju kako bi postale mikroservisne aplikacije. Drugi se kreću ka aplikacijama bez servera, a neki implementiraju kombinacije gore navedenog. Principi navedeni u ovom članku primjenjuju se na svaki od ovih sistema uz samo nekoliko manjih modifikacija.
Principi
Sada kada imamo osnovno razumijevanje o tome šta su moderna aplikacija i moderan stek, vrijeme je da zaronimo u arhitekturu i principe dizajna koji će vam dobro poslužiti u dizajniranju, implementaciji i održavanju moderne aplikacije.
Jedan od principa je “izrada malih aplikacija”, nazovimo to princip malenosti. Postoje nevjerovatno složene aplikacije koje imaju puno pokretnih dijelova. Zauzvrat, izgradnja aplikacije od malih, diskretnih komponenti olakšava dizajn, održavanje i upotrebu u celini. (Imajte na umu da smo rekli “čini ga jednostavnim”, a ne “čini ga jednostavnim”).
Drugi princip je da možemo povećati produktivnost programera pomažući im da se fokusiraju na karakteristike koje razvijaju, dok ih oslobađamo brige o infrastrukturi i CI/CD-u tokom implementacije. Dakle, ukratko, naš pristup orijentisan na programere.
Konačno, sve o vašoj aplikaciji mora biti povezano na mrežu. U proteklih 20 godina, uvelike smo napredovali ka umreženoj budućnosti jer su mreže postale brže, a aplikacije složenije. Kao što smo već vidjeli, mnogo različitih klijenata mora koristiti modernu aplikaciju širom mreže. Primjena mrežnog razmišljanja na arhitekturu ima značajne prednosti koje se dobro uklapaju princip malenosti i koncept pristupa, orijentisan na programere.
Ako ove principe imate na umu kada dizajnirate i implementirate aplikaciju, imat ćete izrazitu prednost u razvoju i isporuci vašeg proizvoda.
Pogledajmo ova tri principa detaljnije.
Princip malenosti
Ljudskom mozgu je teško da percipira velike količine informacija odjednom. U psihologiji, pojam kognitivnog opterećenja odnosi se na ukupnu količinu mentalnog napora potrebnog za zadržavanje informacija u memoriji. Smanjenje kognitivnog opterećenja za programere je prioritet jer se tada mogu fokusirati na rješavanje problema umjesto da drže trenutni složeni model cijele aplikacije i funkcija koje se razvijaju u svojoj glavi.
Aplikacije se dekomponuju iz sljedećih razloga:
- Smanjenje kognitivnog opterećenja programera;
- Ubrzanje i pojednostavljenje testiranja;
- Brza dostava izmjena aplikacije.
Postoji nekoliko načina da se smanji kognitivno opterećenje programera, a tu dolazi do izražaja princip malenosti.
Dakle, tri načina za smanjenje kognitivnog opterećenja:
- Smanjite vremenski okvir koji moraju uzeti u obzir prilikom razvoja nove funkcije – što je kraći vremenski okvir, to je niže kognitivno opterećenje.
- Smanjite količinu koda na kojem se radi odjednom - manje koda - manje opterećenja.
- Pojednostavite proces unošenja inkrementalnih izmjena u vašu aplikaciju.
Smanjeni vremenski okviri razvoja
Vratimo se na vremena kada je metodologija waterfall bio je standard za proces razvoja, a vremenski okviri od šest mjeseci do dvije godine za razvoj ili ažuriranje aplikacije bili su uobičajena praksa. Tipično, inženjeri bi prvo pročitali relevantne dokumente kao što su zahtjevi za proizvod (PRD), referentni dokument sistema (SRD), plan arhitekture i počeli bi integrirati sve ove stvari zajedno u jedan kognitivni model prema kojem su pisali kod. Kako su se zahtjevi, a samim tim i arhitektura, mijenjali, morali su se uložiti značajni napori da se cijeli tim informiše o ažuriranjima kognitivnog modela. U najgorem slučaju, ovaj pristup bi jednostavno mogao paralizirati rad.
Najveća promjena u procesu razvoja aplikacije je uvođenje agilne metodologije. Jedna od glavnih karakteristika metodologije agile - Ovo je iterativni razvoj. Zauzvrat, to dovodi do smanjenja kognitivnog opterećenja inženjera. Umjesto da se od razvojnog tima zahtijeva da implementira aplikaciju u jednom dugom ciklusu, agile Pristup vam omogućava da se fokusirate na male količine koda koji se mogu brzo testirati i implementirati, a istovremeno primati povratne informacije. Kognitivno opterećenje aplikacije pomaknulo se sa vremenskog okvira od šest mjeseci na dvije godine, s ogromnom količinom specifikacija, na dvonedjeljno dodavanje ili promjenu funkcije, ciljajući na difuznije razumijevanje velike aplikacije.
Prebacivanje fokusa sa velike aplikacije na specifične male karakteristike koje se mogu završiti u dvonedeljnom sprintu, gledajući unapred na ne više od jedne funkcije iz sledećeg sprinta na umu je značajna promena. To je omogućilo povećanje produktivnosti razvoja uz smanjenje kognitivnog opterećenja koje je stalno fluktuiralo.
U metodologiji agile Očekuje se da će konačna aplikacija biti malo modifikovana verzija originalnog koncepta, tako da je konačna tačka razvoja nužno dvosmislena. Samo rezultati svakog konkretnog sprinta mogu biti jasni i precizni.
Male baze kodova
Sljedeći korak u smanjenju kognitivnog opterećenja je smanjenje baze koda. Obično su moderne aplikacije masivne — robusna, poslovna aplikacija može se sastojati od hiljada datoteka i stotina hiljada linija koda. Ovisno o organizaciji datoteka, veze i ovisnosti između koda i datoteka mogu ili ne moraju biti očigledne. Čak i otklanjanje grešaka u samom izvršavanju koda može biti problematično, ovisno o korištenim bibliotekama i koliko dobro alati za otklanjanje grešaka razlikuju biblioteke/pakete/module i korisnički kod.
Izgradnja radnog mentalnog modela koda aplikacije može potrajati značajno vrijeme, opet stavljajući veliko kognitivno opterećenje na programera. Ovo posebno važi za monolitne kodne baze, gde postoji velika količina koda, interakcije između funkcionalnih komponenti nisu jasno definisane, a razdvajanje objekata pažnje je često zamagljeno jer se ne poštuju funkcionalne granice.
Jedan efikasan način da se smanji kognitivno opterećenje inženjera je prelazak na arhitekturu mikroservisa. U pristupu mikroservisa, svaka usluga se fokusira na jedan skup funkcija; značenje usluge je obično definisano i razumljivo. Granice usluge su također jasne - zapamtite da se komunikacija sa servisom odvija pomoću API-ja, tako da se podaci koje generiše jedna usluga mogu lako prenijeti na drugu.
Interakcija s drugim uslugama obično je ograničena na nekoliko korisničkih usluga i nekoliko usluga provajdera koji koriste jednostavne i čiste API pozive, kao što je REST. To znači da je kognitivno opterećenje inženjera ozbiljno smanjeno. Najveći izazov ostaje razumijevanje modela interakcije usluge i načina na koji se stvari poput transakcija dešavaju na više usluga. Konačno, korištenje mikroservisa smanjuje kognitivno opterećenje smanjenjem količine koda, definiranjem jasnih granica usluge i pružanjem uvida u odnos korisnika i dobavljača.
Male inkrementalne promjene
Poslednji element principa malo je upravljanje promjenama. Za programere je posebno primamljivo da pogledaju bazu koda (čak možda i svoj, stariji kod) i kažu: "Ovo je sranje, moramo da prepišemo cijelu ovu stvar." Ponekad je to ispravna odluka, a ponekad nije. To stavlja teret promjena globalnog modela na razvojni tim, što zauzvrat rezultira ogromnim kognitivnim opterećenjem. Bolje je da se inženjeri fokusiraju na promjene koje mogu napraviti tokom sprinta, kako bi potom mogli na vrijeme, iako postepeno, uvesti potrebnu funkcionalnost. Konačni proizvod treba da liči na unapred planirani, ali uz određene modifikacije i testiranja kako bi odgovarao potrebama klijenta.
Prilikom ponovnog pisanja velikih dijelova koda, ponekad je nemoguće brzo unijeti promjenu jer druge sistemske ovisnosti dolaze u igru. Da biste kontrolirali tok promjena, možete koristiti sakrivanje karakteristika. U osnovi, to znači da je funkcionalnost prisutna u produkciji, ali nije dostupna kroz postavke varijabli okruženja (env-var) ili bilo koji drugi mehanizam konfiguracije. Ako je kod prošao sve procese kontrole kvaliteta, može završiti u proizvodnji u skrivenom stanju. Međutim, ova strategija funkcionira samo ako je funkcija na kraju omogućena. U suprotnom, samo će zatrpati kod i dodati kognitivno opterećenje s kojim će se programer morati nositi da bi bio produktivan. Upravljanje promjenama i same inkrementalne promjene pomažu u održavanju kognitivnog opterećenja programera na pristupačnom nivou.
Inženjeri moraju savladati mnoge poteškoće čak i kada jednostavno implementiraju dodatnu funkcionalnost. Bilo bi mudro da menadžment smanji nepotrebno opterećenje tima kako bi se mogao fokusirati na ključne elemente funkcionalnosti. Postoje tri stvari koje možete učiniti da pomognete svom razvojnom timu:
- Koristite metodologiju
agile, kako bi se ograničio vremenski okvir u kojem se tim mora fokusirati na ključne karakteristike. - Implementirajte svoju aplikaciju kao nekoliko mikroservisa. Ovo će ograničiti broj uvedenih karakteristika i ojačati granice koje sadrže kognitivno opterećenje tokom rada.
- Preferirajte inkrementalne promjene u odnosu na velike, glomazne, mijenjajte male dijelove koda. Koristite skrivanje funkcija za implementaciju promjena čak i ako one neće biti vidljive odmah nakon što se dodaju.
Ako u svom radu primijenite princip malenosti, vaš tim će biti mnogo sretniji, bolje fokusiran na isporuku potrebnih funkcija i vjerovatnije je da će brže uvesti promjene u kvalitetu. Ali to ne znači da posao ne može postati složeniji; ponekad, naprotiv, uvođenje nove funkcionalnosti zahtijeva modifikaciju nekoliko servisa i taj proces može biti složeniji od sličnog u monolitnoj arhitekturi. U svakom slučaju, prednosti korištenja pristupa su malo vrijedne.
Kraj prvog dijela.
Uskoro ćemo objaviti drugi dio prijevoda, ali sada čekamo vaše komentare i pozivamo vas na to , koji će se održati danas u 20.00 časova.
izvor: www.habr.com