Përshëndetje miq. Në pritje të nisjes së kursit , tradicionalisht ndajmë me ju përkthimin e materialit të dobishëm.
Softueri zgjidh gjithnjë e më shumë probleme të përditshme, ndërsa bëhet gjithnjë e më kompleks. Siç tha dikur Marc Andreessen, ajo po konsumon botën.
Si rezultat, mënyra se si zhvillohen dhe shpërndahen aplikacionet ka ndryshuar në mënyrë dramatike gjatë viteve të fundit. Këto ishin zhvendosje në një shkallë tektonike që rezultuan në një sërë parimesh. Këto parime kanë rezultuar të dobishme në ndërtimin e një ekipi, dizajnimin, zhvillimin dhe dorëzimin e aplikacionit tuaj tek përdoruesit përfundimtarë.
Parimet mund të përmblidhen si më poshtë: aplikacioni duhet të jetë i vogël, i bazuar në ueb dhe të ketë një arkitekturë me qendër zhvilluesi. Duke u mbështetur në këto tre parime, ju mund të krijoni një aplikacion të fuqishëm, nga fundi në fund, që mund të dorëzohet shpejt dhe në mënyrë të sigurt te përdoruesi fundor, dhe është lehtësisht i shkallëzueshëm dhe i shtrirë.
Secili prej parimeve të propozuara ka një sërë aspektesh që do t'i diskutojmë për të treguar se si secili parim kontribuon në qëllimin përfundimtar të ofrimit të shpejtë të aplikacioneve të besueshme që janë të lehta për t'u mirëmbajtur dhe përdorur. Ne do t'i shikojmë parimet në krahasim me të kundërtat e tyre për të sqaruar se çfarë do të thotë të thuash: "Sigurohu që të përdorësh parimi i vogëlsisë'.
Shpresojmë që ky artikull t'ju inkurajojë të përdorni parimet e propozuara për ndërtimin e aplikacioneve moderne që do të ofrojnë një qasje të unifikuar të projektimit në kontekstin e një grumbulli teknologjik gjithnjë në rritje.
Duke zbatuar këto parime, do ta gjeni veten duke përfituar nga tendencat më të fundit në zhvillimin e softuerit, duke përfshirë për zhvillimin dhe shpërndarjen e aplikacioneve, përdorimin e kontejnerëve (për shembull, ) dhe kornizat e orkestrimit të kontejnerëve (për shembull, ), përdorimi i mikroshërbimeve (përfshirë Arkitekturën Microservice и për aplikime mikroservice.
Çfarë është një aplikacion modern?
Aplikacione moderne? Rafte moderne? Çfarë do të thotë saktësisht "moderne"?
Shumica e zhvilluesve kanë vetëm një kuptim bazë të asaj se çfarë përbëhet një aplikacion modern, kështu që është e nevojshme të përcaktohet qartë ky koncept.
Një aplikacion modern mbështet klientë të shumtë, qoftë një ndërfaqe përdoruesi duke përdorur bibliotekën React JavaScript, një aplikacion celular për Android ose iOS, ose një aplikacion që lidhet me një tjetër nëpërmjet një API. Një aplikacion modern nënkupton një numër të pacaktuar klientësh për të cilët ofron të dhëna ose shërbime.
Një aplikacion modern ofron një API për të hyrë në të dhënat dhe shërbimet e kërkuara. API duhet të jetë i pandryshueshëm dhe konstant, dhe jo i shkruar posaçërisht për një kërkesë specifike nga një klient specifik. API është i disponueshëm përmes HTTP(S) dhe ofron akses në të gjithë funksionalitetin që gjendet në GUI ose CLI.
Të dhënat duhet të jenë të disponueshme në një format të përbashkët, të ndërveprueshëm si JSON. Një API ekspozon objektet dhe shërbimet në një formë të qartë dhe të organizuar; për shembull, një API RESTful ose GraphQL ofron një ndërfaqe të mirë.
Aplikacionet moderne janë ndërtuar në një pirg modern, dhe një pirg modern është grupi që mbështet aplikacione të tilla, përkatësisht. Ky grumbull i lejon zhvilluesit të krijojë lehtësisht një aplikacion me një ndërfaqe HTTP dhe të pastrojë pikat fundore të API-së. Qasja që zgjidhni do të lejojë që aplikacioni juaj të pranojë dhe dërgojë lehtësisht të dhëna në formatin JSON. Me fjalë të tjera, pirgja moderne korrespondon me elementët e Aplikacionit Dymbëdhjetë Faktorësh për .
Versionet e njohura të këtij lloji të pirgut bazohen në , , , , и . Arkitektura e Microservice paraqet një shembull të një pirg modern të implementuar në secilën nga gjuhët e përmendura.
Ju lutemi vini re se ne nuk mbrojmë një qasje thjesht mikroshërbimesh. Shumë prej jush po punojnë me monolite që duhet të evoluojnë, ndërsa të tjerët po merren me aplikacione SOA që po zgjerohen dhe zhvillohen për t'u bërë aplikacione mikroservice. Akoma të tjerë po lëvizin drejt aplikacioneve pa server dhe disa po zbatojnë kombinime të sa më sipër. Parimet e përshkruara në këtë artikull zbatohen për secilin prej këtyre sistemeve me vetëm disa modifikime të vogla.
Parimet
Tani që kemi një kuptim themelor se çfarë janë një aplikacion modern dhe një pirg modern, është koha të zhytemi në arkitekturën dhe parimet e dizajnit që do t'ju shërbejnë mirë në projektimin, zbatimin dhe mirëmbajtjen e një aplikacioni modern.
Një nga parimet është "ndërtimi i aplikacioneve të vogla", le ta quajmë atë parimi i vogëlsisë. Ka aplikacione tepër komplekse që kanë shumë pjesë lëvizëse. Nga ana tjetër, ndërtimi i një aplikacioni nga komponentë të vegjël, diskretë e bën më të lehtë dizajnimin, mirëmbajtjen dhe përdorimin në përgjithësi. (Vini re se ne thamë "e bën të thjeshtë" dhe jo "e bën të thjeshtë").
Parimi i dytë është se ne mund të rrisim produktivitetin e zhvilluesve duke i ndihmuar ata të përqëndrohen në veçoritë që po zhvillojnë, duke i çliruar ata nga shqetësimi për infrastrukturën dhe CI/CD gjatë zbatimit. Pra, me pak fjalë, qasja jonë e orientuar nga zhvilluesi.
Më në fund, gjithçka në lidhje me aplikacionin tuaj duhet të lidhet me rrjetin. Gjatë 20 viteve të fundit, ne kemi përparuar shumë drejt një të ardhmeje të lidhur në rrjet, pasi rrjetet janë bërë më të shpejta dhe aplikacionet janë bërë më komplekse. Siç e kemi parë tashmë, një aplikacion modern duhet të përdoret përmes një rrjeti nga shumë klientë të ndryshëm. Zbatimi i të menduarit të rrjetit në arkitekturë ka përfitime të rëndësishme që përshtaten mirë parimi i vogëlsisë dhe koncepti i qasjes, e orientuar nga zhvilluesi.
Nëse i mbani parasysh këto parime kur hartoni dhe zbatoni një aplikacion, do të keni një avantazh të veçantë në zhvillimin dhe shpërndarjen e produktit tuaj.
Le t'i shikojmë këto tre parime në mënyrë më të detajuar.
Parimi i vogëlsisë
Është e vështirë për trurin e njeriut të perceptojë sasi të mëdha informacioni në të njëjtën kohë. Në psikologji, termi ngarkesë kognitive i referohet sasisë totale të përpjekjes mendore të nevojshme për të mbajtur informacionin në kujtesë. Zvogëlimi i ngarkesës njohëse te zhvilluesit është një prioritet sepse ata më pas mund të fokusohen në zgjidhjen e problemit në vend që të mbajnë modelin aktual kompleks të të gjithë aplikacionit dhe veçoritë që zhvillohen në kokën e tyre.
Aplikacionet dekompozohen për arsyet e mëposhtme:
- Reduktimi i ngarkesës njohëse te zhvilluesit;
- Përshpejtimi dhe thjeshtimi i testimit;
- Dorëzimi i shpejtë i ndryshimeve në aplikacion.
Ka disa mënyra për të reduktuar ngarkesën njohëse te zhvilluesit, dhe këtu hyn në lojë parimi i vogëlsisë.
Pra, tre mënyra për të reduktuar ngarkesën njohëse:
- Zvogëloni kornizën kohore që ata duhet të marrin parasysh kur zhvillojnë një veçori të re - sa më i shkurtër të jetë afati kohor, aq më e ulët është ngarkesa njohëse.
- Zvogëloni sasinë e kodit që po punohet në një kohë - më pak kod - më pak ngarkesë.
- Thjeshtoni procesin e bërjes së ndryshimeve në rritje në aplikacionin tuaj.
Korniza kohore të reduktuara të zhvillimit
Le të kthehemi në kohët kur metodologjia waterfall ishte standardi për procesin e zhvillimit dhe afatet kohore prej gjashtë muajsh deri në dy vjet për zhvillimin ose përditësimin e një aplikacioni ishin praktikë e zakonshme. Në mënyrë tipike, inxhinierët fillimisht lexojnë dokumentet përkatëse si kërkesat e produktit (PRD), dokumentin e referencës së sistemit (SRD), planin e arkitekturës dhe fillojnë të integrojnë të gjitha këto gjëra së bashku në një model kognitiv sipas të cilit ata shkruan kodin. Ndërsa kërkesat, dhe për rrjedhojë arkitektura, ndryshuan, duheshin bërë përpjekje të konsiderueshme për të mbajtur të gjithë ekipin të informuar për përditësimet e modelit njohës. Në rastin më të keq, kjo qasje thjesht mund të paralizojë punën.
Ndryshimi më i madh në procesin e zhvillimit të aplikacioneve ishte prezantimi i metodologjisë së shkathët. Një nga tiparet kryesore të metodologjisë agile - Ky është zhvillim përsëritës. Nga ana tjetër, kjo çon në një reduktim të ngarkesës njohëse të inxhinierëve. Në vend që t'i kërkohet ekipit të zhvillimit të zbatojë aplikacionin në një cikël të gjatë, agile Qasja ju lejon të përqendroheni në sasi të vogla kodi që mund të testohen dhe vendosen shpejt, duke marrë gjithashtu reagime. Ngarkesa njohëse e një aplikacioni është zhvendosur nga një kornizë kohore prej gjashtë muajsh në dy vjet, me një sasi të madhe specifikimesh, në një shtesë ose ndryshim funksioni dyjavor, duke synuar një kuptim më të përhapur të një aplikacioni të madh.
Zhvendosja e fokusit nga një aplikacion masiv në veçori të vogla specifike që mund të plotësohen në një sprint dy-javor, duke parë përpara në jo më shumë se një veçori nga sprinti tjetër në mendje është një ndryshim i rëndësishëm. Kjo bëri të mundur rritjen e produktivitetit të zhvillimit duke reduktuar ngarkesën njohëse, e cila ishte vazhdimisht e luhatshme.
Në metodologji agile aplikacioni përfundimtar pritet të jetë një version paksa i modifikuar i konceptit origjinal, kështu që pika përfundimtare e zhvillimit është domosdoshmërisht e paqartë. Vetëm rezultatet e çdo sprinti specifik mund të jenë të qarta dhe të sakta.
Baza e kodeve të vogla
Hapi tjetër në reduktimin e ngarkesës njohëse është zvogëlimi i bazës së kodit. Në mënyrë tipike, aplikacionet moderne janë masive - një aplikacion i fuqishëm, i ndërmarrjes 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ë midis kodit dhe skedarëve mund të jenë ose jo të dukshme. Edhe korrigjimi i ekzekutimit të kodit në vetvete mund të jetë problematik, në varësi të bibliotekave të përdorura dhe sa mirë dallojnë mjetet e korrigjimit midis bibliotekave/pakove/moduleve dhe kodit të përdoruesit.
Ndërtimi i një modeli mendor funksional të kodit të një aplikacioni mund të marrë një kohë të konsiderueshme, duke vendosur përsëri një ngarkesë të madhe njohëse te zhvilluesi. Kjo është veçanërisht e vërtetë për bazat monolitike të kodeve, ku ka një sasi të madhe kodi, ndërveprimet midis komponentëve funksionalë nuk janë të përcaktuar qartë dhe ndarja e objekteve të vëmendjes shpesh është e paqartë sepse nuk respektohen kufijtë funksionalë.
Një mënyrë efektive për të reduktuar ngarkesën njohëse të inxhinierëve është kalimi në një arkitekturë të mikroshërbimeve. Në një qasje mikroservice, çdo shërbim fokusohet në një grup funksionesh; kuptimi i shërbimit është zakonisht i përcaktuar dhe i kuptueshëm. Kufijtë e shërbimit janë gjithashtu të qartë - mbani mend se komunikimi me shërbimin kryhet duke përdorur një API, kështu që të dhënat e krijuara nga një shërbim mund të transferohen lehtësisht në një tjetër.
Ndërveprimi me shërbime të tjera zakonisht kufizohet në disa shërbime përdoruesish dhe disa shërbime ofruesish që përdorin thirrje të thjeshta dhe të pastra API, të tilla si REST. Kjo do të thotë që ngarkesa njohëse e inxhinierit është reduktuar seriozisht. Sfida më e madhe mbetet të kuptuarit e modelit të ndërveprimit të shërbimit dhe se si ndodhin gjëra të tilla si transaksionet nëpër shërbime të shumta. Në fund të fundit, përdorimi i mikroshërbimeve zvogëlon ngarkesën njohëse duke reduktuar sasinë e kodit, duke përcaktuar kufij të qartë të shërbimit dhe duke ofruar njohuri në marrëdhënien përdorues-ofrues.
Ndryshime të vogla në rritje
Elementi i fundit i parimit pak është menaxhimi i ndryshimit. Është veçanërisht joshëse për zhvilluesit që të shikojnë një bazë kodi (madje ndoshta kodin e tyre, më të vjetër) dhe të thonë, "Kjo është gjë e keqe, ne duhet ta rishkruajmë të gjithë këtë gjë." Ndonjëherë është vendimi i duhur dhe ndonjëherë jo. Ai vendos barrën e ndryshimeve të modelit global mbi ekipin e zhvillimit, i cili nga ana tjetër rezulton në ngarkesë masive njohëse. Është më mirë që inxhinierët të përqendrohen në ndryshimet që mund të bëjnë gjatë sprintit, në mënyrë që më pas të mund të hapin funksionalitetin e nevojshëm në kohën e duhur, megjithëse gradualisht. Produkti përfundimtar duhet të ngjajë me atë të planifikuar më parë, por me disa modifikime dhe testime për t'iu përshtatur nevojave të klientit.
Kur rishkruani pjesë të mëdha të kodit, ndonjëherë është e pamundur të jepni shpejt një ndryshim sepse hyjnë në lojë varësi të tjera të sistemit. Për të kontrolluar rrjedhën e ndryshimeve, mund të përdorni fshehjen e veçorive. Në thelb, kjo do të thotë se funksionaliteti është atje në prodhim, por ai nuk është i disponueshëm përmes cilësimeve të variablave të mjedisit (env-var) ose ndonjë mekanizmi tjetër konfigurimi. Nëse kodi i ka kaluar të gjitha proceset e kontrollit të cilësisë, ai mund të përfundojë në prodhim në një gjendje të fshehtë. Megjithatë, kjo strategji funksionon vetëm nëse funksioni aktivizohet përfundimisht. Përndryshe, ai vetëm do të rrëmojë kodin dhe do të shtojë ngarkesën njohëse me të cilën zhvilluesi do të duhet të përballojë për të qenë produktiv. Menaxhimi i ndryshimeve dhe ndryshimet në rritje ndihmojnë në mbajtjen e ngarkesës njohëse të zhvilluesve në një nivel të arritshëm.
Inxhinierët duhet të kapërcejnë shumë vështirësi edhe kur thjesht zbatojnë funksione shtesë. Do të ishte e kujdesshme që menaxhmenti të zvogëlojë ngarkesën e panevojshme të punës në ekip, në mënyrë që ai të fokusohet në elementët kyç të funksionalitetit. Ka tre gjëra që mund të bëni për të ndihmuar ekipin tuaj të zhvillimit:
- Përdorni metodologjinë
agile, për të kufizuar kornizën kohore në të cilën ekipi duhet të fokusohet në karakteristikat kryesore. - Zbatoni aplikacionin tuaj si disa mikroshërbime. Kjo do të kufizojë numrin e veçorive të prezantuara dhe do të forcojë kufijtë që përmbajnë ngarkesë njohëse gjatë punës.
- Preferoni ndryshimet në rritje ndaj atyre të mëdha, të vështira, ndryshoni pjesë të vogla të kodit. Përdorni fshehjen e veçorive për të zbatuar ndryshimet edhe nëse ato nuk do të jenë të dukshme menjëherë pasi të shtohen.
Nëse zbatoni parimin e vogëlsisë në punën tuaj, ekipi juaj do të jetë shumë më i lumtur, i fokusuar më mirë në ofrimin e veçorive të nevojshme dhe më shumë gjasa për të nxjerrë më shpejt ndryshimet e cilësisë. Por kjo nuk do të thotë që puna nuk mund të bëhet më komplekse; ndonjëherë, përkundrazi, futja e një funksionaliteti të ri kërkon modifikim të disa shërbimeve dhe ky proces mund të jetë më kompleks se një i ngjashëm në një arkitekturë monolitike. Në çdo rast, përfitimet e përdorimit të qasjes janë paksa të vlefshme.
Fundi i pjesës së parë.
Së shpejti do të publikojmë pjesën e dytë të përkthimit, por tani presim komentet tuaja dhe ju ftojmë , e cila do të zhvillohet sot në orën 20.00.
Burimi: www.habr.com