Pozdrav prijatelji. U iščekivanju pokretanja tečaja , tradicionalno s vama dijelimo prijevode korisnog materijala.
Softver rješava sve više svakodnevnih zadataka, a pritom postaje sve složeniji. Kao što je jednom rekao Marc Andressen, 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 tektonskih razmjera koji su rezultirali skupom načela. Ovi principi su se pokazali korisnima u izgradnji tima, dizajniranju, razvoju i isporuci vaše aplikacije krajnjim korisnicima.
Načela se mogu sažeti na sljedeći način: aplikacija bi trebala biti mala, web-bazirana i imati arhitekturu usmjerenu na programera. Imajući na umu ova tri načela, možete stvoriti 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, a to je brza isporuka pouzdanih aplikacija koje su jednostavne za održavanje i korištenje. Pogledat ćemo načela u odnosu na njihove suprotnosti kako bismo razjasnili što to znači, recimo: "Provjerite da li koristite načelo malenkosti".
Nadamo se da će vas ovaj članak potaknuti da upotrijebite predložena načela za izgradnju modernih aplikacija, koje će pružiti jedinstveni pristup dizajnu u kontekstu stalno rastućeg niza tehnologija.
Primjenom ovih načela moći ćete iskoristiti prednosti najnovijih trendova u razvoju softvera, uključujući na razvoj i isporuku aplikacija, korištenje spremnika (npr. ) i okviri za orkestraciju spremnika (na primjer, ), korištenje mikroservisa (uključujući arhitekturu mikroservisa и za mikroservisne aplikacije.
Što je moderna aplikacija?
Moderne aplikacije? Moderna hrpa? Što točno znači "moderno"?
Većina programera ima samo opću predodžbu o tome od čega se sastoji moderna aplikacija, stoga je potrebno jasno definirati ovaj koncept.
Moderna aplikacija podržava više klijenata, bilo da se radi o korisničkom sučelju React JavaScript biblioteke, Android ili iOS mobilnoj aplikaciji ili aplikaciji koja se povezuje s drugim API-jem. Moderna aplikacija podrazumijeva neodređeni broj klijenata za koje pruža podatke ili usluge.
Moderna aplikacija nudi 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 omogućuje pristup svim funkcijama dostupnim u GUI ili CLI.
Podaci moraju biti dostupni u općeprihvaćenom, interoperabilnom formatu kao što je JSON. API izlaže objekte i usluge na čist, organiziran način, poput RESTful API-ja ili GraphQL-a koji pružaju pristojno sučelje.
Moderne aplikacije izgrađene su na modernom stogu, a moderni stog je stog koji podržava takve aplikacije. Ovaj skup programerima omogućuje jednostavno kreiranje aplikacije s HTTP sučeljem i brisanje krajnjih točaka API-ja. Odabrani pristup omogućit će vašoj aplikaciji jednostavno primanje i slanje podataka u JSON formatu. Drugim riječima, moderni stack odgovara elementima dvanaestofaktorske aplikacije za .
Popularne verzije ove vrste snopa temelje se na , , , , и . Arhitektura mikroservisa predstavlja primjer modernog steka implementiranog u svakom od navedenih jezika.
Imajte na umu da ne zagovaramo isključivo mikroservisni pristup. Mnogi od vas rade s monolitima koji se trebaju razvijati, dok se drugi bave SOA aplikacijama koje se šire i razvijaju kako bi postale aplikacije mikroservisa. Drugi se pak kreću prema aplikacijama bez poslužitelja, a neki implementiraju kombinacije gore navedenog. Načela navedena u članku primjenjuju se na svaki od ovih sustava uz samo nekoliko manjih izmjena.
Načela
Sada kada imamo zajedničko razumijevanje što su moderna aplikacija i moderni skup, vrijeme je da zaronimo u arhitekturu i razvojna načela koja će vam dobro poslužiti u razvoju, implementaciji i održavanju moderne aplikacije.
Jedan od principa zvuči kao "pravi male aplikacije", nazovimo to jednostavno načelo malenkosti. Postoje nevjerojatno složene aplikacije koje se sastoje od mnogo pokretnih dijelova. Zauzvrat, izrada aplikacije od malih, diskretnih komponenti olakšava dizajn, održavanje i rad s njom kao cjelinom. (Imajte na umu da smo rekli "pojednostavljuje", a ne "čini jednostavnim").
Drugo načelo je da možemo povećati produktivnost programera pomažući im da se usredotoče na značajke koje razvijaju, dok ih oslobađamo briga o infrastrukturi i CI/CD-u tijekom implementacije. Dakle, ukratko, naš pristup usmjeren na programere.
Konačno, sve o vašoj aplikaciji mora biti povezano s mrežom. Tijekom proteklih 20 godina napravili smo velike korake prema umreženoj budućnosti kako mreže postaju brže, a aplikacije složenije. Kao što smo već vidjeli, modernu aplikaciju mora koristiti mnogo različitih klijenata preko mreže. Primjena mrežnog razmišljanja na arhitekturu ima značajne prednosti koje se slažu načelo malenkosti i koncept pristupa, orijentiran na programere.
Ako imate na umu ova načela prilikom dizajniranja i implementacije aplikacije, imat ćete neosporivu prednost u razvoju i isporuci vašeg proizvoda.
Pogledajmo ova tri principa detaljnije.
Načelo malenkosti
Ljudskom mozgu je teško percipirati veliku količinu informacija u isto vrijeme. U psihologiji se izraz kognitivno opterećenje odnosi na ukupnu količinu mentalnog napora potrebnog za zadržavanje informacija u pamćenju. Smanjenje kognitivnog opterećenja programera je prioritet jer im omogućuje da se usredotoče na rješavanje problema umjesto da zadrže trenutni složeni model cijele aplikacije i značajki koje se razvijaju u njihovoj glavi.
Aplikacije se raspadaju iz sljedećih razloga:
- Smanjeno kognitivno opterećenje programera;
- Ubrzanje i pojednostavljenje testiranja;
- Brza dostava promjena u aplikaciji.
Postoji nekoliko načina za smanjenje kognitivnog opterećenja programera, a tu dolazi do izražaja načelo malenosti.
Evo tri načina za smanjenje kognitivnog opterećenja:
- Smanjite vremenski okvir koji moraju uzeti u obzir pri razvoju nove značajke – što je kraći vremenski okvir, manje je kognitivno opterećenje.
- Smanjite količinu koda na kojem se obavlja jednokratni rad - manje koda - manje opterećenja.
- Pojednostavite postupak unošenja inkrementalnih promjena u aplikaciju.
Smanjenje vremenskog okvira razvoja
Vratimo se u dane 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. Obično bi inženjeri prvo pročitali relevantne dokumente kao što su zahtjevi za proizvod (PRD), referentni dokument o sustavu (SRD), nacrt arhitekture i počeli kombinirati sve te stvari zajedno u jedan kognitivni model, prema kojem su kodirali. Kako su se zahtjevi, a samim time i arhitektura mijenjali, potrebno je uložiti ozbiljan napor da se cijeli tim informira o ažuriranjima kognitivnog modela. Takav bi pristup, u najgorem slučaju, mogao jednostavno paralizirati rad.
Najveća promjena u procesu razvoja aplikacija bilo je uvođenje agilne metodologije. Jedno od glavnih obilježja metodologije agile je iterativni razvoj. Zauzvrat, to dovodi do smanjenja kognitivnog opterećenja inženjera. Umjesto da od razvojnog tima zahtijevaju implementaciju aplikacije u jednom dugom ciklusu, agile pristup vam omogućuje da se usredotočite na male količine koda koji se može brzo testirati i implementirati, a istovremeno primati povratne informacije. Kognitivno opterećenje aplikacije pomaknuto je sa šestomjesečnog na dvogodišnji vremenski okvir s ogromnom količinom specifikacija za dvotjedno dodavanje ili promjenu značajke koja cilja na nejasnije razumijevanje velike aplikacije.
Prebacivanje fokusa s masivne aplikacije na specifične male značajke koje se mogu dovršiti u dvotjednom sprintu, bez više od jedne značajke prije sljedećeg sprinta na umu, značajna je promjena. To nam je omogućilo povećanje razvojne produktivnosti uz smanjenje kognitivnog opterećenja koje je stalno fluktuiralo.
U metodologiji agile očekuje se da će konačna aplikacija biti malo modificirana verzija izvornog koncepta, tako da je krajnja točka razvoja nužno dvosmislena. Samo rezultati svakog pojedinačnog sprinta mogu biti jasni i precizni.
Male baze kodova
Sljedeći korak u smanjenju kognitivnog opterećenja je smanjenje baze koda. U pravilu, moderne aplikacije su masivne - robusna, poslovna aplikacija može se sastojati od tisuća datoteka i stotina tisuća redaka koda. Ovisno o tome kako su datoteke organizirane, veze i ovisnosti između koda i datoteka mogu biti očite ili obrnuto. Čak i samo izvršavanje koda za otklanjanje pogrešaka može biti problematično, ovisno o bibliotekama koje se koriste i koliko dobro alati za uklanjanje pogrešaka razlikuju biblioteke/pakete/module i prilagođeni kod.
Izgradnja radnog mentalnog modela koda aplikacije može potrajati impresivnu količinu vremena i još jednom staviti veliki kognitivni teret na programera. To se posebno odnosi na monolitne kodne baze, gdje postoji velika količina koda čija interakcija između funkcionalnih komponenti nije jasno definirana, a razdvajanje objekata pažnje često je zamagljeno jer se ne poštuju funkcionalne granice.
Jedan od učinkovitih načina za smanjenje kognitivnog opterećenja inženjera je prelazak na mikroservisnu arhitekturu. U mikroservisnom pristupu, svaka usluga se fokusira na jedan skup značajki; dok je značenje usluge obično definirano i razumljivo. Granice usluge također su jasne - zapamtite da se komunikacija s uslugom odvija putem API-ja, tako da se podaci koje generira jedna usluga mogu lako proslijediti drugoj.
Interakcija s drugim uslugama obično je ograničena na nekoliko korisničkih usluga i nekoliko usluga pružatelja koji koriste jednostavne i čiste API pozive, kao što je korištenje REST-a. 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 događaju na više usluga. Kao rezultat toga, korištenje mikrousluga smanjuje kognitivno opterećenje smanjenjem količine koda, definiranjem jasnih granica usluga i pružanjem razumijevanja odnosa između korisnika i pružatelja usluga.
Male inkrementalne promjene
Posljednji element načela malenkost je upravljanje promjenama. Posebno je iskušenje za programere da pogledaju bazu koda (čak možda i vlastiti, stariji kod) i kažu: "Ovo je sranje, moramo sve to ponovno napisati." Ponekad je to prava odluka, a ponekad nije. To stavlja teret globalne promjene modela na razvojni tim, što zauzvrat dovodi do golemog kognitivnog opterećenja. Bolje je da se inženjeri usredotoče na promjene koje mogu napraviti tijekom sprinta, tako da mogu uvesti potrebnu funkcionalnost pravodobno, iako postupno. Konačni proizvod trebao bi nalikovati unaprijed planiranom, ali uz određene izmjene i testiranja kako bi odgovarao potrebama naručitelja.
Kada se prepisuju veliki dijelovi koda, ponekad nije moguće brzo isporučiti promjenu jer druge ovisnosti o sustavu dolaze u igru. Kako biste kontrolirali tijek promjena, možete koristiti skrivanje značajki. U načelu, to znači da je funkcionalnost u proizvodnji, ali nije dostupna pomoću postavki varijable okruženja (env-var) ili nekog drugog konfiguracijskog mehanizma. Ako je kôd prošao sve procese kontrole kvalitete, može završiti u proizvodnji u latentnom stanju. Međutim, ova strategija funkcionira samo ako je značajka na kraju omogućena. Inače će samo zatrpati kod i dodati kognitivno opterećenje s kojim će se programer morati nositi kako bi bio produktivan. Upravljanje promjenama i same postupne promjene pomažu u održavanju kognitivnog opterećenja programera na prihvatljivoj razini.
Inženjeri moraju prevladati mnoge poteškoće čak i uz jednostavno uvođenje dodatne funkcionalnosti. Od strane menadžmenta, bilo bi mudro smanjiti nepotrebno opterećenje tima kako bi se mogao fokusirati na ključne funkcionalne elemente. Postoje tri stvari koje možete učiniti kako biste pomogli svom razvojnom timu:
- Koristite metodologiju
agilekako bi se ograničio vremenski okvir u kojem se tim mora usredotočiti na ključne značajke. - Implementirajte svoju aplikaciju kao više mikroservisa. To će ograničiti broj značajki koje se mogu implementirati i ojačati granice koje održavaju kognitivno opterećenje na djelu.
- Dajte prednost inkrementalnim promjenama u odnosu na velike i nezgrapne, mijenjajte male dijelove koda. Koristite skrivanje značajki za implementaciju promjena čak i ako one neće biti vidljive odmah nakon dodavanja.
Ako u svom radu primijenite načelo malenkosti, vaš će tim biti mnogo sretniji, bolje usredotočen na implementaciju potrebnih značajki i vjerojatnije je da će brže uvesti kvalitativne promjene. Ali to ne znači da se posao ne može zakomplicirati, ponekad, naprotiv, uvođenje nove funkcionalnosti zahtijeva modifikaciju nekoliko usluga, a taj proces može biti teži od sličnog u monolitnoj arhitekturi. U svakom slučaju, prednosti pristupa malenkosti su vrijedne toga.
Kraj prvog dijela.
Uskoro ćemo objaviti i drugi dio prijevoda, a sada očekujemo vaše komentare i pozivamo vas na njih , koji će se održati danas u 20.00 sati.
Izvor: www.habr.com