Saluton, amikoj. Antaŭĝoje de la lanĉo de la kurso , tradicie kundividas kun vi la tradukon de utila materialo.
Programaro solvas pli kaj pli da ĉiutagaj taskoj, dum fariĝas pli kaj pli kompleksa. Kiel Marc Andressen iam diris, ĝi konsumas la mondon.
Kiel rezulto, la maniero kiel aplikaĵoj estas evoluigitaj kaj liveritaj dramece ŝanĝiĝis dum la lastaj jaroj. Tiuj estis ŝanĝoj de tektona skalo kiuj rezultigis aron de principoj. Ĉi tiuj principoj pruvis esti helpema en teamkonstruado, projektado, evoluado kaj liverado de via aplikaĵo al finaj uzantoj.
La principoj povas esti resumitaj jene: la aplikaĵo devus esti malgranda, ret-bazita, kaj havi programist-centran arkitekturon. Konsiderante ĉi tiujn tri principojn, vi povas krei fortikan, fin-al-finan aplikaĵon, kiu povas esti rapide kaj sekure liverita al la fina uzanto, kaj estas facile skalebla kaj etendebla.
Ĉiu el la proponitaj principoj havas kelkajn aspektojn, kiujn ni diskutos por montri kiel ĉiu principo kontribuas al la fina celo, kiu estas la rapida livero de fidindaj aplikoj, kiuj estas facile konservi kaj uzi. Ni rigardos la principojn rilate al iliaj maloj por klarigi kion ĝi signifas, diru: "Certu, ke vi uzas principo de malgrandeco".
Ni esperas, ke ĉi tiu artikolo instigos vin uzi la proponitajn principojn por konstrui modernajn aplikaĵojn, kiuj provizos unuecan aliron al dezajno en la kunteksto de ĉiam kreskanta teknologia stako.
Aplikante ĉi tiujn principojn, vi trovos vin profiti de la plej novaj tendencoj en programaro, inkluzive de la al la disvolviĝo kaj livero de aplikoj, la uzo de ujoj (ekzemple, ) kaj ujajn instrumentadkadrojn (ekzemple, ), la uzo de mikroservoj (inkluzive de la Mikroserva Arkitekturo и por mikroservaj aplikoj.
Kio estas moderna aplikaĵo?
Modernaj aplikoj? Moderna stako? Kion precize signifas "moderna"?
Plej multaj programistoj havas nur ĝeneralan ideon pri kio konsistas moderna aplikaĵo, do necesas klare difini ĉi tiun koncepton.
Moderna programo subtenas plurajn klientojn, ĉu ĝi estas uzantinterfaco de la biblioteko React JavaScript, poŝtelefona aplikaĵo por Android aŭ iOS, aŭ aplikaĵo, kiu konektas al alia API. Moderna aplikaĵo implicas nedifinitan nombron da klientoj por kiuj ĝi disponigas datumojn aŭ servojn.
Moderna aplikaĵo disponigas API por aliri la petitajn datumojn kaj servojn. La API devus esti neŝanĝebla kaj konstanta, kaj ne skribita specife por specifa peto de specifa kliento. La API disponeblas per HTTP(S) kaj disponigas aliron al ĉiuj funkciaĵoj disponeblaj en la GUI aŭ CLI.
La datumoj devas esti haveblaj en komune akceptita, kunfunkciebla formato kiel JSON. API elmontras objektojn kaj servojn en pura, organizita maniero, kiel RESTful API aŭ GraphQL provizas decan interfacon.
Modernaj aplikoj estas konstruitaj sur la moderna stako, kaj la moderna stako estas la stako kiu subtenas tiajn aplikojn, respektive. Ĉi tiu stako permesas al programisto facile krei aplikaĵon kun HTTP-interfaco kaj klaraj API-finpunktoj. La elektita aliro permesos al via aplikaĵo facile ricevi kaj sendi datumojn en formato JSON. Alivorte, la moderna stako respondas al la elementoj de la Dekdu-Faktora Apliko por .
Popularaj versioj de ĉi tiu tipo de stako baziĝas sur , , , , и . Mikroserva Arkitekturo reprezentas ekzemplon de moderna stako efektivigita en ĉiu el la menciitaj lingvoj.
Bonvolu noti, ke ni ne rekomendas ekskluzive mikroservan aliron. Multaj el vi laboras kun monolitoj, kiuj bezonas evolui, dum aliaj traktas SOA-aplikojn, kiuj disetendiĝas kaj evoluas por fariĝi mikroservaj aplikoj. Ankoraŭ aliaj moviĝas al senservilaj aplikoj, kaj iuj efektivigas kombinaĵojn de ĉi-supraj. La principoj skizitaj en la artikolo validas por ĉiu el ĉi tiuj sistemoj kun nur kelkaj etaj modifoj.
Principoj
Nun kiam ni havas komunan komprenon pri kio estas moderna aplikaĵo kaj moderna stako, estas tempo plonĝi en la arkitekturon kaj evoluajn principojn, kiuj bone utilos al vi por disvolvi, efektivigi kaj konservi modernan aplikaĵon.
Unu el la principoj sonas kiel "faru malgrandajn aplikojn", ni nur nomu ĝin principo de malgrandeco. Estas nekredeble kompleksaj aplikoj, kiuj konsistas el multaj moviĝantaj partoj. Siavice, konstrui aplikaĵon el malgrandaj diskretaj komponantoj faciligas desegni, konservi kaj labori kun ĝi entute. (Rimarku, ke ni diris "simpligas" ne "simpligas").
La dua principo estas, ke ni povas pliigi programistan produktivecon helpante ilin koncentriĝi pri la funkcioj, kiujn ili disvolvas, liberigante ilin de infrastrukturo kaj CI/KD-zorgoj dum efektivigo. Do, resume, nia aliro koncentrita sur programistoj.
Fine, ĉio pri via aplikaĵo devas esti konektita al la reto. Dum la pasintaj 20 jaroj, ni faris grandajn paŝojn al interreta estonteco dum retoj fariĝas pli rapidaj kaj aplikaĵoj pli kompleksaj. Kiel ni vidis, moderna aplikaĵo devas esti uzata per reto de multaj malsamaj klientoj. Apliki retan pensadon al arkitekturo havas signifajn avantaĝojn, kiuj bone kongruas principo de malgrandeco kaj la koncepto de la aliro, orientita al programisto.
Se vi memoras ĉi tiujn principojn kiam vi desegnas kaj efektivigas aplikaĵon, vi havos nekontesteblan avantaĝon en la disvolviĝo kaj livero de via produkto.
Ni rigardu ĉi tiujn tri principojn pli detale.
Malgrandeco principo
Estas malfacile por la homa cerbo percepti grandan kvanton da informoj samtempe. En psikologio, la esprimo kogna ŝarĝo rilatas al la totalsumo de mensa fortostreĉo postulata por reteni informojn en memoro. Redukti la kognan ŝarĝon sur programistoj estas prioritato ĉar ĝi permesas al ili koncentriĝi pri solvado de la problemo anstataŭ konservi la nunan kompleksan modelon de la tuta aplikaĵo kaj la funkciojn disvolvitajn en ilia kapo.
Aplikoj malkomponiĝas pro la sekvaj kialoj:
- Reduktita kogna ŝarĝo sur programistoj;
- Akcelo kaj simpligo de testado;
- Rapida livero de ŝanĝoj en la aplikaĵo.
Estas pluraj manieroj redukti la kognan ŝarĝon sur programistoj, kaj ĉi tie aperas la principo de malgrandeco.
Do jen tri manieroj redukti kognan ŝarĝon:
- Redukti la tempokadron, kiun ili devas konsideri dum disvolvado de nova funkcio - ju pli mallonga la tempokadro, des pli malalta la kogna ŝarĝo.
- Redukti la kvanton da kodo, sur kiu unufoja laboro estas farita - malpli da kodo - malpli da ŝarĝo.
- Simpligu la procezon fari pliigajn ŝanĝojn al aplikaĵo.
Reduktante la disvolvan tempon
Ni revenu al la tagoj kiam la metodiko waterfall estis la normo por la evoluprocezo, kaj tempokadroj de ses monatoj al du jaroj por evoluigado aŭ ĝisdatigado de aplikiĝo estis ofta praktiko. Tipe, inĝenieroj unue legus signifajn dokumentojn kiel ekzemple la produktpostuloj (PRD), sistema referencdokumento (SRD), arkitektura skizo, kaj komencus kombini ĉiujn ĉi tiujn aferojn kune en unu kognan modelon, laŭ kiu ili kodis. Ĉar la postuloj kaj, sekve, la arkitekturo ŝanĝiĝis, serioza penado devis esti farita por informi la tutan teamon pri ĝisdatigoj de la kogna modelo. Tia aliro, plej malbone, povus simple paralizi la laboron.
La plej granda ŝanĝo en la aplikaĵa evoluprocezo estis la enkonduko de la lerta metodaro. Unu el la ĉefaj trajtoj de la metodiko agile estas ripeta evoluo. Siavice, ĉi tio kondukas al redukto de la kogna ŝarĝo sur inĝenieroj. Anstataŭ postuli la disvolvan teamon efektivigi la aplikaĵon en unu longa ciklo, agile aliro permesas vin koncentriĝi pri malgrandaj kvantoj da kodo, kiu povas esti rapide provita kaj deplojita, dum ankaŭ ricevante reagojn. La kogna ŝarĝo de la programo ŝanĝiĝis de sesmonata al dujara tempokadro kun grandega kvanto da specifoj por dusemajna aldono aŭ funkcioŝanĝo celanta pli malklaran komprenon de granda programo.
Ŝanĝi la fokuson de amasa aplikaĵo al specifaj malgrandaj funkcioj, kiuj povas esti kompletigitaj en du-semajna sprinto, kun ne pli ol unu funkcio antaŭ la sekva sprinto en menso, estas grava ŝanĝo. Ĉi tio permesis al ni pliigi disvolvan produktivecon reduktante la kognan ŝarĝon, kiu konstante variadis.
En metodiko agile la fina aplikaĵo estas atendita esti iomete modifita versio de la origina koncepto, do la finpunkto de evoluo estas nepre ambigua. Nur la rezultoj de ĉiu specifa spurto povas esti klaraj kaj precizaj.
Malgrandaj kodbazoj
La sekva paŝo en reduktado de kogna ŝarĝo estas redukti la kodan bazon. Kiel regulo, modernaj aplikoj estas amasaj - fortika, entreprena aplikaĵo povas konsisti el miloj da dosieroj kaj centoj da miloj da linioj de kodo. Depende de kiel la dosieroj estas organizitaj, ligiloj kaj dependecoj inter kodo kaj dosieroj povas esti evidentaj, aŭ inverse. Eĉ sencimiga kodo ekzekuto mem povas esti problema, depende de la bibliotekoj uzitaj kaj kiom bone la sencimigaj iloj distingas inter bibliotekoj/pakaĵoj/moduloj kaj kutima kodo.
Konstrui funkciantan mensan modelon de la kodo de aplikaĵo povas preni impresan kvanton da tempo, kaj denove meti grandan kognan ŝarĝon sur la programiston. Tio estas precipe vera por monolitaj kodbazoj, kie ekzistas granda kvanto de kodo, kies interagado inter la funkciaj komponentoj ne estas klare difinita, kaj la apartigo de objektoj de atento estas ofte malklara ĉar funkciaj limoj ne estas respektataj.
Unu el la efikaj manieroj redukti la kognan ŝarĝon sur inĝenieroj estas moviĝi al mikroserva arkitekturo. En mikroserva aliro, ĉiu servo temigas unu aron da funkcioj; dum la signifo de la servo estas kutime difinita kaj komprenebla. La limoj de servo ankaŭ estas klaraj - memoru, ke komunikado kun servo estas farita per API, do datumoj generitaj de unu servo povas facile esti transdonitaj al alia.
Interago kun aliaj servoj estas kutime limigita al kelkaj uzantservoj kaj kelkaj provizantaj servoj kiuj uzas simplajn kaj purajn API-vokojn, kiel ekzemple uzado de REST. Ĉi tio signifas, ke la kogna ŝarĝo sur la inĝeniero estas grave reduktita. La plej granda defio restas kompreni la modelon de interagado de servo kaj kiel aferoj kiel transakcioj okazas tra pluraj servoj. Kiel rezulto, la uzo de mikroservoj reduktas kognan ŝarĝon reduktante la kvanton de kodo, difinante klarajn servlimojn kaj disponigante komprenon de la rilato inter uzantoj kaj provizantoj.
Malgrandaj pliigaj ŝanĝoj
La lasta elemento de la principo malgrandeco estas ŝanĝadministrado. Estas aparta tento por programistoj rigardi la kodan bazon (eĉ eble sian propran, pli malnovan kodon) kaj diri: "Ĉi tio estas aĉa, ni devas reverki ĉion." Foje ĉi tio estas la ĝusta decido, kaj foje ne. Ĝi metas la ŝarĝon de tutmonda modelŝanĝo sur la evoluan teamon, kiu siavice kondukas al masiva kogna ŝarĝo. Estas pli bone por inĝenieroj koncentriĝi pri la ŝanĝoj, kiujn ili povas fari dum la sprinto, por ke ili povu disvolvi la necesajn funkciojn ĝustatempe, kvankam iom post iom. La fina produkto devus simili la antaŭplanitan, sed kun kelkaj modifoj kaj testado por konveni la bezonojn de la kliento.
Dum reverkado de grandaj partoj de kodo, estas foje ne eble rapide liveri la ŝanĝon ĉar aliaj sistemaj dependecoj eniras. Por kontroli la fluon de ŝanĝoj, vi povas uzi funkcion kaŝadon. Principe, tio signifas, ke la funkcieco estas en produktado, sed ĝi ne estas havebla uzante la mediovariablajn agordojn (env-var) aŭ iun alian agordan mekanismon. Se la kodo pasis ĉiujn kvalitkontrolajn procezojn, tiam ĝi povas finiĝi en produktado en latenta stato. Tamen, ĉi tiu strategio nur funkcias se la funkcio estas poste ebligita. Alie, ĝi nur malordigos la kodon kaj aldonos kognan ŝarĝon, kiun la programisto devos trakti por esti produktiva. Ŝanĝadministrado kaj pliigaj ŝanĝoj mem helpas konservi la kognan ŝarĝon de programistoj je pagebla nivelo.
Inĝenieroj devas venki multajn malfacilaĵojn eĉ kun la simpla enkonduko de plia funkcieco. Fale de administrado, estus prudente redukti la nenecesan ŝarĝon de la teamo por ke ĝi povu koncentriĝi pri ŝlosilaj funkciaj elementoj. Estas tri aferoj, kiujn vi povas fari por helpi vian evoluan teamon:
- Uzu metodikon
agilelimigi la tempokadron en kiu la teamo devas temigi ŝlosilajn trajtojn. - Efektivigu vian aplikaĵon kiel plurajn mikroservojn. Ĉi tio limigos la nombron da funkcioj kiuj povas esti efektivigitaj kaj plifortigos la limojn, kiuj tenas la kognan ŝarĝon en la laboro.
- Preferu pliigajn ŝanĝojn ol grandajn kaj malfacilajn, ŝanĝu malgrandajn pecojn de kodo. Uzu funkcion kaŝadon por efektivigi ŝanĝojn eĉ se ili ne estos videblaj tuj post esti aldonitaj.
Se vi aplikas la principon de malgrandeco en via laboro, via teamo estos multe pli feliĉa, pli bone koncentrita pri efektivigo de la necesaj funkcioj, kaj pli verŝajne plirapidiĝos kvalitajn ŝanĝojn. Sed ĉi tio ne signifas, ke la laboro ne povas fariĝi pli komplika, foje, male, la enkonduko de nova funkcieco postulas la modifon de pluraj servoj, kaj ĉi tiu procezo povas esti pli malfacila ol simila en monolita arkitekturo. Ĉiukaze, la avantaĝoj de preni la malgrandecon valoras ĝin.
Fino de la unua parto.
Baldaŭ ni publikigos la duan parton de la traduko, kaj nun ni atendas viajn komentojn kaj invitas vin al , kiu okazos hodiaŭ je la 20.00.
fonto: www.habr.com