Përshëndetje, miq. Në prag të lansimit të kursit , tradicionalisht ndajem me ju përkthimin e materialit të dobishëm.
Software-i zgjidh gjithnjë e më shumë detyra të përditshme, duke u bërë gjithashtu gjithnjë e më kompleks. Siç tha një herë Mark Andreessen, ai po pushton botën.
Si rezultat, gjatë disa viteve të fundit, qasjet ndaj zhvillimit dhe ofrimit të aplikacioneve kanë ndryshuar seriozisht. Këto ishin lëvizje të mëdha që çuan në formimin e një grupi parimesh. Këto parime ishin të dobishme në formimin e ekipit, dizajnimin, zhvillimin dhe shpërndarjen e aplikacionit tuaj tek përdoruesit përfundimtarë.
Parimet mund të përmbledhen si më poshtë: aplikacioni duhet të jetë i vogël, i lidhur me rrjetin dhe të ketë një arkitekturë të orientuar nga zhvilluesi. Duke u mbështetur në këto tri parime, mund të krijoni një aplikacion të besueshëm dhe të plotë, i cili mund të shpërndahet shpejt dhe në mënyrë të sigurt tek përdoruesit përfundimtarë, si dhe të jetë i lehtë për t'u skalier dhe zgjeruar.
Secili nga parimet e propozuara ka një numër aspektesh që ne do t'i diskutojmë për të treguar se si secili parim kontribuon në arritjen e qëllimit përfundimtar, i cili është të ofrojmë aplikacione të besueshme që janë të lehta për t'u mbajtur dhe përdorur. Ne do të shqyrtojmë parimet në krahasim me kundërshtitë e tyre për të sqaruar se çfarë do të thotë, për shembull, «Sigurohuni se përdorni parimin e vogëlsisë».
Shpresojmë se ky artikull do t'ju inkurajojë të përdorni parimet e propozuara për ndërtimin e aplikacioneve moderne, të cilat do ta sigurojnë një qasje të përbashkët në dizajnin në kontekstin e një grumbulli teknologjish që rritet vazhdimisht.
Duke aplikuar këto parime, do të zbuloni se po shfrytëzoni tendencat e fundit në zhvillimin e software-it, duke përfshirë qasjen në zhvillimin dhe shpërndarjen e aplikacioneve, përdorimin e enëve (p.sh., ) dhe kornizave për orkestrimin e enëve (p.sh., ), përdorimin e mikroshërbimeve (përfshirë Arkitekturën Mikroshërbimore dhe për aplikacionet mikroshërbimore.
Čfarë është një aplikacion modern?
Aplikacionet moderne? Grupi modern? Çfarë do të thotë saktësisht «modern»?
Shumica e zhvilluesve kanë vetëm një përceptim të përgjithshëm të asaj që përbën një aplikacion modern, prandaj është e nevojshme të jepet një definicion i qartë për këtë koncept.
Një aplikacion modern mbështet disa klientë, qofshin ato ndërfaqe përdoruesi në bibliotekën JavaScript React, një aplikacion mobil për Android ose iOS, ose një aplikacion që lidhet me një tjetër përmes API-së. Një aplikacion modern nënkupton praninë e një numri të pacaktuar klientësh, për të cilët ai ofron të dhëna ose shërbime.
Një aplikacion modern ofron një API për qasje në të dhënat dhe shërbimet që kërkohen. API duhet të jetë e pandryshueshme dhe e qëndrueshme, dhe jo e shkruar posaçërisht për ndonjë kërkesë specifike nga ndonjë klient të caktuar. API është e aksesueshme përmes HTTP(S) dhe siguron qasje në të gjithë funksionalitetin që ka ndërfaqja GUI ose CLI.
Të dhënat duhet të jenë të aksesueshme në një format të njohur dhe të përshtatshëm, si JSON. API ofron objekte dhe shërbime në një formë të kuptueshme dhe të organizuar, për shembull, API-të RESTful ose GraphQL ofrojnë një ndërfaqe të dukshme.
Aplikacionet moderne ndërtohen mbi një grup modern, dhe një grup modern është ai që mbështet aplikacione të tilla, për rrjedhojë. Ky grup e lejon zhvilluesin të krijojë me lehtësi një aplikacion me ndërfaqe HTTP dhe pika të qarta API. Qasja e zgjedhur do t'i lejojë aplikacionit tuaj të pranojë dhe dërgojë të dhëna në formatin JSON me lehtësi. Me fjalë të tjera, grupi modern përputhet me elementet e Aplikasi-it të Dymbëdhjetë-Faktorësh për .
Versionet më të njohura të këtij lloji të grupit bazohen në , , , , dhe . Arkitektura Mikroshërbimore përfaqëson një shembull të grupit modern, i realizuar në secilin prej gjuhëve të përmendura.
Vini re se ne nuk po propagandojmë ekskluzivisht qasjen mikroshërbimore. Shumë prej jush punojnë me monolite që duhet të zhvillohen, ndërsa të tjerë po merren me aplikacione SOA që zgjerohen dhe zhvillohen për t'u bërë aplikacione mikroshërbimore. Të tretët po lëvizin në drejtimin e aplikacioneve pa server (serverless), ndërsa disa po implementojnë kombinime të asaj që është përmendur më lart. Parimet e përshkruara në artikull janë të aplikueshme për secilën nga këto sisteme me disa ndryshime të vogla.
Parimet
Tani që arritëm një kuptim të përbashkët për atë se çfarë janë aplikacionet moderne dhe staku modern, është koha të thellohemi në parimet e arkitekturës dhe zhvillimit, që do t'ju shërbejnë mirë në zhvillimin, zbatimin dhe mbështetje të një aplikacioni modern.
Një nga parimet është "krijo aplikacione të vogla", le të e quajmë thjesht principi i voglësisë. Ekzistojnë aplikacione tepër të ndërlikuara, të përbërë nga shumë komponentë lëvizës. Nga ana tjetër, ndërtimi i një aplikacioni nga komponente të vogla dhe discrete lehtëson projektimin, mirëmbajtjen dhe funksionimin e tij në përgjithësi. (Vini re, ne thamë "lehtëson", dhe jo "bën të lehtë").
Princi i dytë është se ne mund të rrisim produktivitetin e zhvilluesve duke i ndihmuar ata të përqëndrohen në funksionalitetet që po zhvillojnë, dhe në të njëjtën kohë duke i liruar ata nga shqetësimet për infrastrukturën dhe CI/CD gjatë zbatimit. Pra, me pak fjalë, qasja jonë është e orientuar drejt zhvilluesve.
Në fund, gjithçka që lidhet me aplikacionin tuaj duhet të jetë e lidhur me rrjetin. Gjatë 20 viteve të fundit kemi bërë përparime të konsiderueshme drejt së ardhmes rrjetore, pasi rrjetet kanë bërë më të shpejtë, ndërsa aplikacionet janë bërë më të ndërlikuara. Siç e kemi zbuluar, një aplikacion modern duhet të përdoret nëpërmjet rrjetit nga shumë klientë të ndryshëm. Aplikimi i mendimit rrjetor në arkitekturë ka përparësi të mëdha, të cilat lidhen mirë me principi i voglësisë dhe konceptin e qasjes, të orientuar drejt zhvilluesve.
Nëse gjatë zhvillimit dhe zbatimit të aplikacionit mbani mend këto principe, do të keni një avantazh të padiskutueshëm në zhvillimin dhe dorëzimin e produktit tuaj.
Le të shqyrtojmë këto tre parime më në detaje.
Principi i voglësisë
Truri i njeriut ka vështirësi të perceptojë një sasi të madhe informacioni njëkohësisht. Në psikologji, termi ngarkesa kogitative përshkruan sasinë e përgjithshme të përpjekjeve mendore që nevojiten për të mbajtur informacionin në memorie. Reduktimi i ngarkesës kogitative për zhvilluesit është prioritet, pasi kështu ata mund të përqëndrohen në zgjidhjen e problemeve, përveçse të mbajnë mend modelin kompleks aktual të gjithë aplikacionit dhe funksionalitetet që po zhvillojnë.
Aplikacionet dekonstruktohen për arsyet e mëposhtme:
- Reduktimi i ngarkesës kogitative për zhvilluesit;
- Shpejtësimi dhe lehtësimi i testimit;
- Dorëzimi i shpejtë i ndryshimeve në aplikacion.
Ekzistojnë disa mënyra për të ulur ngarkesën kogitative për zhvilluesit, dhe këtu hyn në lojë principi i voglësisë.
Pra, tre mënyra për të ulur ngarkesën kogitative:
- Të zvogëlohet afati kohor që ata duhet të konsiderojnë gjatë zhvillimit të një funksionaliteti të ri – sa më i shkurtër të jetë afati, aq më e ulët është ngarkesa kogitative.
- Të reduktohet sasitë e kodit mbi të cilin po punohet njëkohësisht – më pak kod, më pak ngarkesë.
- Të thjeshtohet procesi i bërjes së ndryshimeve inkrementale në aplikacion.
Reduktimi i afateve kohore të zhvillimit
Le të kthehemi në ato kohëra kur metodologjia waterfall ishte standardi për procesin e zhvillimit, dhe afatet nga gjashtë muaj deri në dy vjet për zhvillimin ose përditësimin e një aplikacioni ishin praktikë e zakonshme. Si rregull, inxhinierët fillimisht lexonin dokumentet përkatëse, siç janë kërkesat për produktin (PRD), dokumenti referues i sistemit (SRD), plani i arkitekturës dhe fillonin të bashkonin të gjitha këto gjëra së bashku në një model kogitiv, sipas të cilit ata shkruanin kodin. Ndërsa kërkesat dhe, për rrjedhojë, arkitektura ndryshonin, duhej të bëheshin përpjekje të mëdha për të informuar të gjithë ekipin mbi azhurnimet e modelit kogitiv. Një qasje e tillë mund të paralizonte punën në rastin më të keq.
Ndryshimi më i madh në procesin e zhvillimit të aplikacioneve ka qenë zbatimi i metodologjisë agile. Një nga veçoritë kryesore të metodologjisë agile është zhvillimi iterativ. Kjo, nga ana tjetër, çon në uljen e ngarkesës kogitative për inxhinierët. Në vend që të kërkohet nga ekipi i zhvilluesve të realizojë aplikacionin në një cikël të gjatë, agile qasja lejon përqëndrimin në sasi të vogla të kodit që mund të testohen dhe implementohen shpejt, duke marrë gjithashtu edhe feedback. Ngarkesa kogitative e aplikacionit është zhvendosur nga afati kohor nga gjashtë muaj deri në dy vjet me një sasi të madhe specifikimesh në një dyjavësh për shtimin ose ndryshimin e funksionalitetit, e orientuar nga një kuptim më të paqartë për një aplikacion të madh.
Fokusi nga aplikacionet e mëdha në funksione të vogla specifike që mund të përfundojnë brenda një sprinti dyjavor, me një vështrim para se mos kalojë një funksion nga sprinti i ardhshëm në mendje, është një ndryshim i rëndësishëm. Kjo ka lejuar që të rritet produktiviteti i zhvillimit duke e zvogëluar ngarkesën kognitive që ishte vazhdimisht e luhatur.
Në metodologjinë agile supozon se aplikacioni përfundimtar do të jetë një version pak të ndryshuar i konceptit fillestar, kështu që pika përfundimtare e zhvillimit është domosdoshmërisht e paqartë. Vetëm rezultatet e secilit sprint të veçantë mund të jenë të qarta dhe të saktë.
Baza të vogla koduese
Hapi tjetër në zvogëlimin e ngarkesës kognitive është reduktimi i bazës koduese. Zakonisht, aplikacionet moderne janë masive – një aplikacion i besueshëm dhe për korporata mund të përbëhet nga mijëra skedarë dhe qindra mijëra rreshta kodi. Në varësi të organizimit të skedarëve, lidhjet dhe varësitë e kodit mund të jenë të qarta ose ndryshe. Edhe debugs e ekzekutimit të kodit mund të shkaktojnë probleme, në varësi të bibliotekave të përdorura dhe se sa mirë mjetet e debuggimit ndajnë bibliotekat/paketat/modules nga kodi i përdoruesit.
Ndërtimi i një modeli mendor funktional të kodit të aplikacionit mund të marrë një kohë të konsiderueshme dhe përsëri ta ngarkojë zhvilluesin me një ngarkesë kognitive të madhe. Kjo është veçanërisht e zakonshme për bazat e kodit monolitike, ku ka një sasi të madhe kodi dhe ndërveprimi midis komponenteve funksionale nuk është qartë i përcaktuar, dhe ndarja e objekteve të vëmendjes shpesh është e paqartë, pasi kufijtë funksional nuk respektohen.
Një nga mënyrat efektive për të zvogëluar ngarkesën kognitive të inxhinierëve është kalimi në një arkitekturë mikroshërbimesh. Në qasjen mikroshërbim, çdo shërbim përqendrohet në një grup funksionesh; ku kuptimi i shërbimit është zakonisht i përcaktuar dhe i qartë. Kufijtë e shërbimit gjithashtu janë të qartë – kujtoni se komunikimi me shërbimin bëhet përmes API, kështu që të dhënat e gjeneruara nga një shërbim mund të transferohen lehtësisht në një tjetër.
Ndërveprimi me shërbime të tjera zakonisht është i kufizuar në disa shërbime të përdoruesve dhe disa shërbime ofruesi, të cilat përdorin thirrje API të thjeshta dhe të pastra, siç janë ato përmes REST. Kështu, ngarkesa kognitive për inxhinierët zvogëlohet ndjeshëm. Problemi më i ndërlikuar mbetet kuptimi i modelit të ndërveprimit të shërbimeve dhe se si gjërat si transaksionet ndodhin në disa shërbime. Si rezultat, përdorimi i mikroshërbimeve ul ngarkesën kognitive duke zvogëluar sasinë e kodit, duke përcaktuar kufijtë e qartë të shërbimit dhe duke siguruar kuptimin e marrëdhënieve midis përdoruesve dhe ofruesve.
Ndryshime të vogla inkrementale
Elementi i fundit i parimit të vogla është menaxhimi i ndryshimeve. Një tundim i veçantë për zhvilluesit është të shikojnë bazën e kodit (madje, ndoshta, kodin e tyre më të vjetër) dhe të deklarojnë: "Kjo është e keqe, na duhet ta ri-shkruajmë çdo gjë." Ndodhin disa herë që kjo është një zgjidhje e drejtë, dhe disa herë jo. Kjo regjistron ekipin e zhvilluesve me barrën e një ndryshimi global të modelit, që, në të tjera, sjell një ngarkesë kognitive të gjerë. Më mirë është që inxhinierët të përqendrohen në ndryshimet që ata mund të bëjnë brenda një sprinti, për të nxjerrë në mënyrë të duhur funksionalitetin e nevojshëm, pavarësisht se gradualisht. Produkti përfundimtar duhet të jetë një version i planifikuar paraprakisht, por me disa ndryshime dhe teste për të përmbushur nevojat e klientit.
Kur në riparimin e pjesëve të mëdha të kodit, nganjëherë është e pamundur të realizohet shpejt dorëzimi i ndryshimeve, sepse këtu përfshihen varësi të tjera të sistemit. Për të kontrolluar fluksin e ndryshimeve, mund të përdoret ndalja e funksionalitetit (feature hiding). Në parim, kjo do të thotë se funksionaliteti ekziston në prodhim, por nuk është e qasshme përmes konfigurimeve të variablave të mjedisit (env-var) ose ndonjë mekanizmi tjetër konfigurimi. Nëse kodi ka kaluar të gjitha proceset e kontrolleve të cilësisë, ai mund të gjendet në prodhim në një gjendje të fshehur. Megjithatë, kjo strategji funksionon vetëm nëse funksioni përfundimisht do të aktivizohet. Ndryshe, ai do të mbushë thjesht kodin dhe do të shtojë një ngarkesë mendore që zhvilluesi do të duhet të përballojë për të punuar në mënyrë produktive. Menaxhimi i ndryshimeve dhe ndryshimet inkrementale vetë ndihmojnë për të mbajtur ngarkesën mendore të zhvilluesve në një nivel të pranueshëm.
Inxhinierët përballen me shumë sfida edhe në realizimin e funksionaliteteve të reja. Nga ana e menaxhimit, do të ishte e arsyeshme të reduktohej ngarkesa e tepërt për ekipin, në mënyrë që ata të mund të përqendrohen në elementet kyçe të funksionalitetit. Ka tri gjëra që mund të bëni për të ndihmuar ekipin tuaj të zhvilluesve:
- Përdor metodologji
agile, për të kufizuar afatet, në të cilat ekipi duhet të përqendrohet në funksionet kyçe. - Implementoni aplikacionin tuaj si disa mikrosërvise. Kjo do të kufizojë numrin e funksionaliteteve që stërviten dhe do të forcojë kufijtë që mbajnë ngarkesën mendore gjatë punës.
- Preferoni ndryshime inkrementale sesa të mëdha dhe voluminoze; ndryshoni copa të vogla të kodit. Aplikoni fshehjen e funksioneve për të realizuar ndryshimet, edhe nëse ato nuk do të jenë të dukshme menjëherë pas shtimit.
Nëse ju aplikoni parimin e vogël në punën tuaj, ekipi juaj do të jetë shumë më i lumtur, do të përqendrohet më mirë në realizimin e funksionaliteteve të nevojshme dhe do të ketë më shumë mundësi për të dorëzuar ndryshime cilësore më shpejt. Por kjo nuk do të thotë se puna nuk mund të komplikohet; ndonjëherë, përkundrazi, implementimi i funksionaliteteve të reja kërkon modifikimin e disa shërbimeve dhe ky proces mund të jetë më i komplikuar se ai në arkitekturën monolite. Megjithatë, përfitimet nga aplikimi i qasjes së vogël ia vlen.
Fundi i pjesës së parë.
Së shpejti do të publikojmë pjesën e dytë të përkthimit, dhe tani po presim komentet tuaja dhe ju ftojmë në , që do të mbahet sot në orën 20.00.
Burimi: habr.com
