ProHoster > Blogs > Administrācija > NGINX modernu lietojumprogrammu izstrādes principi. 1. daļa

NGINX modernu lietojumprogrammu izstrādes principi. 1. daļa

Sveiki draugi. Gaidot kursu uzsākÅ”anu "Aizmugures izstrādātājs PHP", mēs tradicionāli dalāmies ar jums noderÄ«ga materiāla tulkojumu.

Programmatūra atrisina arvien vairāk ikdienas problēmu, vienlaikus kļūstot arvien sarežģītāka. Kā reiz teica Marks Andreesens, tas patērē pasauli.

NGINX modernu lietojumprogrammu izstrādes principi. 1. daļa

Rezultātā lietojumprogrammu izstrādes un piegādes veids pēdējos gados ir krasi mainÄ«jies. Tās bija izmaiņas tektoniskā mērogā, kuru rezultātā radās principu kopums. Å ie principi ir izrādÄ«juÅ”ies noderÄ«gi, veidojot komandu, izstrādājot, izstrādājot un nogādājot jÅ«su lietojumprogrammu galalietotājiem.

Principus var apkopot Ŕādi: lietojumprogrammai jābÅ«t mazai, tÄ«meklÄ« balstÄ«tai, un tai jābÅ«t uz izstrādātāju orientētai arhitektÅ«rai. Balstoties uz Å”iem trim principiem, varat izveidot stabilu, visaptveroÅ”u lietojumprogrammu, ko var ātri un droÅ”i piegādāt galalietotājam, un tā ir viegli mērogojama un paplaÅ”ināma.

NGINX modernu lietojumprogrammu izstrādes principi. 1. daļa

Katram no piedāvātajiem principiem ir vairāki aspekti, kurus mēs apspriedÄ«sim, lai parādÄ«tu, kā katrs princips palÄ«dz sasniegt gala mērÄ·i ā€“ ātri nodroÅ”ināt uzticamas lietojumprogrammas, kuras ir viegli uzturēt un lietot. Mēs aplÅ«kosim principus salÄ«dzinājumā ar to pretstatiem, lai noskaidrotu, ko nozÄ«mē teikt: ā€œPārliecinieties, ka lietojat mazuma princips'.

Mēs ceram, ka Å”is raksts mudinās jÅ«s izmantot piedāvātos principus modernu lietojumprogrammu izveidei, kas nodroÅ”inās vienotu dizaina pieeju arvien pieaugoŔās tehnoloÄ£iju kopas kontekstā.

Piemērojot Å”os principus, jÅ«s varēsit izmantot jaunākās programmatÅ«ras izstrādes tendences, tostarp DevOps lietojumprogrammu izstrādei un piegādei, konteineru izmantoÅ”anai (piemēram, dokers) un konteineru orÄ·estrÄ“Å”anas ietvarus (piemēram, Kubernetes), mikropakalpojumu izmantoÅ”ana (tostarp Microservice Architecture nginx Šø tÄ«kla komunikācijas arhitektÅ«ra mikropakalpojumu lietojumprogrammām.

Kas ir moderna lietotne?

MÅ«sdienÄ«gas lietojumprogrammas? MÅ«sdienu kaudze? Ko Ä«sti nozÄ«mē ā€œmodernsā€?

Lielākajai daļai izstrādātāju ir tikai pamata izpratne par to, no kā sastāv mÅ«sdienu lietojumprogramma, tāpēc ir nepiecieÅ”ams skaidri definēt Å”o jēdzienu.

MÅ«sdienÄ«ga lietojumprogramma atbalsta vairākus klientus, neatkarÄ«gi no tā, vai tā ir lietotāja saskarne, izmantojot React JavaScript bibliotēku, mobilā lietojumprogramma Android vai iOS, vai lietojumprogramma, kas savienojas ar citu, izmantojot API. MÅ«sdienÄ«ga lietojumprogramma ietver nenoteiktu skaitu klientu, kuriem tā nodroÅ”ina datus vai pakalpojumus.

MÅ«sdienÄ«ga lietojumprogramma nodroÅ”ina API, lai piekļūtu pieprasÄ«tajiem datiem un pakalpojumiem. API ir jābÅ«t nemainÄ«gai un nemainÄ«gai, un tā nav rakstÄ«ta Ä«paÅ”i konkrētam klienta pieprasÄ«jumam. API ir pieejama, izmantojot HTTP(S), un nodroÅ”ina piekļuvi visām GUI vai CLI funkcijām.

Datiem ir jābÅ«t pieejamiem kopējā, sadarbspējÄ«gā formātā, piemēram, JSON. API atklāj objektus un pakalpojumus skaidrā, sakārtotā formā; piemēram, RESTful API vai GraphQL nodroÅ”ina pienācÄ«gu saskarni.

MÅ«sdienu lietojumprogrammas ir veidotas uz moderna steka, un modernā steks ir attiecÄ«gi steks, kas atbalsta Ŕādas lietojumprogrammas. Å Ä« kaudze ļauj izstrādātājam viegli izveidot lietojumprogrammu ar HTTP saskarni un skaidriem API galapunktiem. JÅ«su izvēlētā pieeja ļaus jÅ«su lietojumprogrammai viegli pieņemt un nosÅ«tÄ«t datus JSON formātā. Citiem vārdiem sakot, modernā kaudze atbilst divpadsmit faktoru lietojumprogrammas elementiem mikropakalpojumi.

Šāda veida kaudzes populārās versijas ir balstÄ«tas uz Java, Pitons, mezgls, rubÄ«ns, PHP Šø Go. Mikropakalpojumu arhitektÅ«ra nginx ir modernas kaudzes piemērs, kas ieviests katrā no minētajām valodām.

LÅ«dzu, ņemiet vērā, ka mēs neatbalstām tikai mikropakalpojumu pieeju. Daudzi no jums strādā ar monolÄ«tiem, kuriem ir jāattÄ«stās, savukārt citi nodarbojas ar SOA lietojumprogrammām, kas paplaÅ”inās un attÄ«stās, lai kļūtu par mikropakalpojumu lietojumprogrammām. Vēl citi virzās uz lietojumprogrammām bez serveriem, un daži ievieÅ” iepriekÅ” minēto kombinācijas. Å ajā rakstā izklāstÄ«tie principi attiecas uz katru no Ŕīm sistēmām tikai ar dažām nelielām izmaiņām.

Principi

Tagad, kad mums ir pamatzināŔanas par to, kas ir moderna lietojumprogramma un moderna steks, ir pienācis laiks ienirt arhitektÅ«rā un projektÄ“Å”anas principos, kas jums noderēs modernas lietojumprogrammas projektÄ“Å”anā, ievieÅ”anā un uzturÄ“Å”anā.

Viens no principiem ir "veidojiet mazas aplikācijas", sauksim tā mazuma princips. Ir neticami sarežģītas lietojumprogrammas, kurās ir daudz kustÄ«gu daļu. Savukārt lietojumprogrammas izveide no maziem, diskrētiem komponentiem padara to vieglāk izstrādātu, uzturēt un lietot kopumā. (Ņemiet vērā, ka mēs teicām ā€œpadara to vienkārÅ”uā€, nevis ā€œpadara vienkārÅ”uā€).

Otrais princips ir tāds, ka mēs varam palielināt izstrādātāju produktivitāti, palÄ«dzot viņiem koncentrēties uz funkcijām, ko viņi izstrādā, vienlaikus atbrÄ«vojot viņus no raizēm par infrastruktÅ«ru un CI/CD ievieÅ”anas laikā. Tātad, Ä«sumā, mÅ«su pieeja uz izstrādātāju orientēts.

Visbeidzot, visam jÅ«su lietojumprogrammai ir jābÅ«t savienotam ar tÄ«klu. Pēdējo 20 gadu laikā mēs esam ievērojami virzÄ«juÅ”ies uz tÄ«klu nākotnē, jo tÄ«kli ir kļuvuÅ”i ātrāki un lietojumprogrammas ir kļuvuÅ”as sarežģītākas. Kā mēs jau redzējām, moderna lietojumprogramma tÄ«klā ir jāizmanto daudziem dažādiem klientiem. TÄ«kla domāŔanas pielietoÅ”anai arhitektÅ«rā ir ievērojamas priekÅ”rocÄ«bas, kas labi atbilst mazuma princips un pieejas koncepcija, uz izstrādātāju orientēts.

Ja paturēsiet prātā Å”os principus, izstrādājot un ievieÅ”ot lietojumprogrammu, jums bÅ«s izteiktas priekÅ”rocÄ«bas sava produkta izstrādē un piegādē.

Apskatīsim Ŕos trīs principus sīkāk.

Mazuma princips

Cilvēka smadzenēm ir grÅ«ti uzreiz uztvert lielu informācijas daudzumu. PsiholoÄ£ijā termins kognitÄ«vā slodze attiecas uz kopējo garÄ«gās piepÅ«les apjomu, kas nepiecieÅ”ams, lai saglabātu informāciju atmiņā. Izstrādātāju kognitÄ«vās slodzes samazināŔana ir prioritāte, jo viņi pēc tam var koncentrēties uz problēmas risināŔanu, nevis paturēt prātā paÅ”reizējo sarežģīto visas lietojumprogrammas modeli un izstrādātās funkcijas.

NGINX modernu lietojumprogrammu izstrādes principi. 1. daļa

Lietojumprogrammas tiek sadalÄ«tas Ŕādu iemeslu dēļ:

  • Samazināt izstrādātāju kognitÄ«vo slodzi;
  • TestÄ“Å”anas paātrināŔana un vienkārÅ”oÅ”ana;
  • Ātra aplikācijas izmaiņu piegāde.


Ir vairāki veidi, kā samazināt izstrādātāju kognitīvo slodzi, un Ŕeit tiek izmantots mazuma princips.

Tātad, trīs veidi, kā samazināt kognitīvo slodzi:

  1. Samaziniet laika posmu, kas viņiem jāņem vērā, izstrādājot jaunu funkciju ā€“ jo Ä«sāks laika posms, jo mazāka ir kognitÄ«vā slodze.
  2. Samaziniet koda daudzumu, pie kura tiek strādāts vienlaikus ā€” mazāk koda ā€” mazāk slodzes.
  3. VienkārÅ”ojiet pakāpenisku izmaiņu veikÅ”anu savā lietojumprogrammā.

Samazināts izstrādes laika posms

AtgriezÄ«simies tajos laikos, kad metodoloÄ£ija waterfall bija izstrādes procesa standarts, un laika periodi no seÅ”iem mēneÅ”iem lÄ«dz diviem gadiem lietojumprogrammas izstrādei vai atjaunināŔanai bija ierasta prakse. Parasti inženieri vispirms izlasÄ«s attiecÄ«gos dokumentus, piemēram, produkta prasÄ«bas (PRD), sistēmas atsauces dokumentu (SRD), arhitektÅ«ras plānu un sāk integrēt visas Ŕīs lietas vienā kognitÄ«vā modelÄ«, saskaņā ar kuru viņi rakstÄ«ja kodu. Mainoties prasÄ«bām un lÄ«dz ar to arÄ« arhitektÅ«rai, bija jāpieliek lielas pÅ«les, lai visa komanda bÅ«tu informēta par kognitÄ«vā modeļa atjauninājumiem. Sliktākajā gadÄ«jumā Ŕī pieeja var vienkārÅ”i paralizēt darbu.

Lielākās izmaiņas aplikāciju izstrādes procesā bija veiklās metodoloÄ£ijas ievieÅ”ana. Viena no metodoloÄ£ijas galvenajām iezÄ«mēm agile - Tā ir iteratÄ«va attÄ«stÄ«ba. Savukārt tas noved pie inženieru kognitÄ«vās slodzes samazināŔanās. Tā vietā, lai izstrādātāju komandai bÅ«tu jāievieÅ” lietojumprogramma vienā garā ciklā, agile Å Ä« pieeja ļauj koncentrēties uz nelielu koda daudzumu, ko var ātri pārbaudÄ«t un izvietot, vienlaikus saņemot arÄ« atsauksmes. Lietojumprogrammas kognitÄ«vā slodze ir mainÄ«jusies no seÅ”u mēneÅ”u laika posma uz diviem gadiem ar milzÄ«gu specifikāciju skaitu uz divu nedēļu funkciju pievienoÅ”anu vai maiņu, kas ir vērsta uz izkliedētāku izpratni par lielu lietojumprogrammu.

Fokusa pārslēgÅ”ana no masÄ«vas lietojumprogrammas uz Ä«paŔām mazām funkcijām, kuras var pabeigt divu nedēļu sprintā, domājot par ne vairāk kā vienu funkciju no nākamā sprinta, ir bÅ«tiskas izmaiņas. Tas ļāva palielināt attÄ«stÄ«bas produktivitāti, vienlaikus samazinot kognitÄ«vo slodzi, kas pastāvÄ«gi svārstÄ«jās.

Metodoloģijā agile Paredzams, ka galīgais pieteikums būs nedaudz pārveidota sākotnējās koncepcijas versija, tāpēc galīgais izstrādes punkts noteikti ir neskaidrs. Skaidri un precīzi var būt tikai katra konkrētā sprinta rezultāti.

Mazas kodu bāzes

Nākamais solis kognitÄ«vās slodzes samazināŔanai ir koda bāzes samazināŔana. Parasti mÅ«sdienu lietojumprogrammas ir milzÄ«gas ā€” spēcÄ«ga, uzņēmuma lietojumprogramma var sastāvēt no tÅ«kstoÅ”iem failu un simtiem tÅ«kstoÅ”u koda rindu. AtkarÄ«bā no failu organizācijas, savienojumi un atkarÄ«bas starp kodu un failiem var bÅ«t vai nebÅ«t acÄ«mredzami. Pat paÅ”as koda izpildes atkļūdoÅ”ana var bÅ«t problemātiska atkarÄ«bā no izmantotajām bibliotēkām un no tā, cik labi atkļūdoÅ”anas rÄ«ki atŔķir bibliotēkas/pakas/moduļus un lietotāja kodu.

Lietojumprogrammas koda darba garÄ«gā modeļa izveide var aizņemt ievērojamu laiku, atkal radot lielu kognitÄ«vo slodzi izstrādātājam. Tas jo Ä«paÅ”i attiecas uz monolÄ«tajām kodu bāzēm, kur ir liels koda daudzums, funkcionālo komponentu mijiedarbÄ«ba nav skaidri definēta un uzmanÄ«bas objektu atdalÄ«Å”ana bieži ir neskaidra, jo netiek ievērotas funkcionālās robežas.

Viens efektÄ«vs veids, kā samazināt inženieru kognitÄ«vo slodzi, ir pāriet uz mikropakalpojumu arhitektÅ«ru. Mikropakalpojumu pieejā katrs pakalpojums koncentrējas uz vienu funkciju kopu; pakalpojuma nozÄ«me parasti ir definēta un saprotama. ArÄ« pakalpojuma robežas ir skaidras ā€“ atcerieties, ka saziņa ar servisu tiek veikta, izmantojot API, tāpēc viena pakalpojuma Ä£enerētos datus var viegli pārsÅ«tÄ«t uz citu.

MijiedarbÄ«ba ar citiem pakalpojumiem parasti aprobežojas ar dažiem lietotāju pakalpojumiem un dažiem pakalpojumu sniedzēja pakalpojumiem, kas izmanto vienkārÅ”us un tÄ«rus API zvanus, piemēram, REST. Tas nozÄ«mē, ka inženiera kognitÄ«vā slodze ir nopietni samazināta. Lielākais izaicinājums joprojām ir izprast pakalpojumu mijiedarbÄ«bas modeli un to, kā, piemēram, darÄ«jumi notiek vairākos pakalpojumos. Galu galā mikropakalpojumu izmantoÅ”ana samazina kognitÄ«vo slodzi, samazinot koda daudzumu, definējot skaidras pakalpojumu robežas un sniedzot ieskatu lietotāja un pakalpojumu sniedzēja attiecÄ«bās.

Nelielas pakāpeniskas izmaiņas

Pēdējais principa elements mazliet ir pārmaiņu vadÄ«ba. Izstrādātājiem ir Ä«paÅ”i vilinoÅ”i aplÅ«kot koda bāzi (pat, iespējams, viņu paÅ”u vecāku kodu) un teikt: "Tā ir muļķība, mums ir jāpārraksta visa Ŕī lieta." Dažreiz tas ir pareizs lēmums, un dažreiz tas nav. Tas uzliek globālo modeļu izmaiņu slogu izstrādes komandai, kas savukārt rada milzÄ«gu izziņas slodzi. Inženieriem labāk koncentrēties uz izmaiņām, ko viņi var veikt sprinta laikā, lai pēc tam varētu laicÄ«gi, kaut arÄ« pakāpeniski, ieviest nepiecieÅ”amo funkcionalitāti. Galaproduktam vajadzētu lÄ«dzināties iepriekÅ” plānotajam, taču ar dažām modifikācijām un testÄ“Å”anu, lai tas atbilstu klienta vajadzÄ«bām.

Pārrakstot lielas koda daļas, dažkārt nav iespējams ātri veikt izmaiņas, jo tiek izmantotas citas sistēmas atkarÄ«bas. Lai kontrolētu izmaiņu plÅ«smu, varat izmantot funkciju slēpÅ”anu. BÅ«tÄ«bā tas nozÄ«mē, ka funkcionalitāte ir pieejama ražoÅ”anā, taču tā nav pieejama, izmantojot vides mainÄ«go iestatÄ«jumus (env-var) vai kādu citu konfigurācijas mehānismu. Ja kods ir izturējis visus kvalitātes kontroles procesus, tas var nonākt ražoÅ”anā slēptā stāvoklÄ«. Tomēr Ŕī stratēģija darbojas tikai tad, ja funkcija beidzot ir iespējota. Pretējā gadÄ«jumā tas tikai pārblÄ«vēs kodu un pievienos kognitÄ«vo slodzi, ar kuru izstrādātājam bÅ«s jātiek galā, lai tas bÅ«tu produktÄ«vs. Izmaiņu pārvaldÄ«ba un pakāpeniskas izmaiņas palÄ«dz uzturēt izstrādātāju kognitÄ«vo slodzi pieejamā lÄ«menÄ«.

Inženieriem ir jāpārvar daudzas grÅ«tÄ«bas, pat vienkārÅ”i ievieÅ”ot papildu funkcionalitāti. VadÄ«bai bÅ«tu saprātÄ«gi samazināt nevajadzÄ«go darba slodzi komandai, lai tā varētu koncentrēties uz galvenajiem funkcionalitātes elementiem. Ir trÄ«s lietas, ko varat darÄ«t, lai palÄ«dzētu savai izstrādes komandai:

  1. Izmantojiet metodiku agile, lai ierobežotu laika posmu, kurā komandai jākoncentrējas uz galvenajām funkcijām.
  2. Ieviesiet savu lietojumprogrammu kā vairākus mikropakalpojumus. Tas ierobežos ieviesto funkciju skaitu un nostiprinās robežas, kas darba laikā satur kognitīvo slodzi.
  3. Dodiet priekÅ”roku pakāpeniskām izmaiņām, nevis lielām, smagnējām izmaiņām, mainiet nelielas koda daļas. Izmantojiet funkciju slēpÅ”anu, lai ieviestu izmaiņas pat tad, ja tās nebÅ«s redzamas uzreiz pēc pievienoÅ”anas.

Ja savā darbā izmantosit mazuma principu, jÅ«su komanda bÅ«s daudz laimÄ«gāka, labāk koncentrējas uz nepiecieÅ”amo funkciju nodroÅ”ināŔanu un, visticamāk, ātrāk ieviesÄ«s kvalitātes izmaiņas. Taču tas nenozÄ«mē, ka darbs nevar kļūt sarežģītāks, dažkārt, gluži otrādi, jaunas funkcionalitātes ievieÅ”anai nepiecieÅ”ama vairāku servisu modificÄ“Å”ana un Å”is process var bÅ«t sarežģītāks nekā lÄ«dzÄ«gs monolÄ«tā arhitektÅ«rā. Jebkurā gadÄ«jumā Ŕīs pieejas izmantoÅ”anas priekÅ”rocÄ«bas ir nedaudz tā vērtas.

Pirmās daļas beigas.

DrÄ«zumā publicēsim tulkojuma otro daļu, bet tagad gaidām jÅ«su komentārus un aicinām to darÄ«t Atvērto durvju diena, kas notiks Å”odien plkst.20.00.

Avots: www.habr.com

Pievieno komentāru