Kaixo lagunak. Ikastaroaren abiarazteari begira , tradizioz zurekin partekatzen dugu material erabilgarriaren itzulpena.
Softwareak gero eta eguneroko arazo gehiago konpontzen ditu, gero eta konplexuagoa den bitartean. Marc Andreessen behin esan bezala, mundua kontsumitzen ari da.
Ondorioz, aplikazioak garatzeko eta entregatzeko modua izugarri aldatu da azken urteotan. Hauek eskala tektonikoko aldaketak ziren, eta printzipio multzo bat eragin zuten. Printzipio hauek lagungarriak izan dira talde bat sortzeko, zure aplikazioa diseinatzeko, garatzeko eta azken erabiltzaileei entregatzeko.
Printzipioak honela laburbil daitezke: aplikazioak txikia izan behar du, webean oinarritutakoa eta garatzaileengan oinarritutako arkitektura izan behar du. Hiru printzipio hauek oinarri hartuta, amaierako aplikazio sendo bat sor dezakezu, azken erabiltzaileari azkar eta seguru entregatu ahal izango zaiona, eta erraz eskalagarria eta hedagarria dena.
Proposatutako printzipio bakoitzak eztabaidatuko ditugun alderdi batzuk ditu, printzipio bakoitzak mantentzen eta erabiltzeko errazak diren aplikazio fidagarriak azkar emateko azken helburuan nola laguntzen duen erakusteko. Printzipioak haien kontrakoekin alderatuta aztertuko ditugu, esatea zer den argitzeko: "Ziurtatu erabiltzen duzula txikitasunaren printzipioa'.
Artikulu honek gero eta hazten ari den teknologia-pila baten testuinguruan diseinu bateratua emango duten aplikazio modernoak eraikitzeko proposatutako printzipioak erabiltzera animatzen zaituela espero dugu.
Printzipio hauek aplikatuz, software garapenaren azken joerak aprobetxatuz aurkituko duzu, besteak beste aplikazioen garapenari eta entregari, edukiontziak erabiltzeari (adibidez, ) eta edukiontzien orkestrazio esparruak (adibidez, ), mikrozerbitzuen erabilera (Mikrozerbitzuen Arkitektura barne ΠΈ mikrozerbitzuen aplikazioetarako.
Zer da aplikazio moderno bat?
Aplikazio modernoak? Pila modernoa? Zer esan nahi du zehazki "modernoa"?
Garatzaile gehienek aplikazio moderno bat zertan datzan oinarrizko ulermena besterik ez dute, beraz, beharrezkoa da kontzeptu hori argi definitzea.
Aplikazio moderno batek hainbat bezero onartzen ditu, izan React JavaScript liburutegia erabiltzen duen erabiltzaile-interfazea, Android edo iOS-erako mugikorrentzako aplikazio bat edo API baten bidez beste batekin konektatzen den aplikazio bat. Aplikazio moderno batek datu edo zerbitzuak eskaintzen dituen bezero kopuru mugagabea dakar.
Aplikazio moderno batek API bat eskaintzen du eskatutako datu eta zerbitzuetara sartzeko. APIa aldaezina eta konstantea izan behar du, eta ez bezero zehatz baten eskaera zehatz baterako idatzia. APIa HTTP(S) bidez eskuragarri dago eta GUI edo CLI-n aurkitzen diren funtzionalitate guztietarako sarbidea ematen du.
Datuek formatu komun eta elkarreragingarri batean egon behar dute eskuragarri, hala nola JSON. API batek objektuak eta zerbitzuak forma argi eta antolatuan erakusten ditu; adibidez, RESTful API edo GraphQL-ek interfaze duin bat eskaintzen dute.
Aplikazio modernoak pila moderno batean eraikitzen dira, eta pila moderno bat aplikazio horiek onartzen dituen pila da, hurrenez hurren. Pila honi esker, garatzaileak erraz sor ditzake aplikazio bat HTTP interfaze batekin eta API amaierako puntuak garbitzeko. Aukeratzen duzun ikuspegiari esker, zure aplikazioak erraz onartu eta bidal ditzake datuak JSON formatuan. Beste era batera esanda, pila modernoa hamabi faktoreen aplikazioaren elementuei dagokie .
Pila mota honen bertsio ezagunak oinarritzen dira , , , , ΠΈ . Mikrozerbitzuen Arkitektura aipatutako hizkuntzetako bakoitzean inplementatutako pila moderno baten adibidea adierazten du.
Kontuan izan ez dugula mikrozerbitzuen ikuspegi hutsa defendatzen. Zuetako asko eboluzionatu behar duten monolitoekin ari zarete lanean, eta beste batzuk, berriz, mikrozerbitzuen aplikazio bihurtzeko hedatzen eta eboluzionatzen ari diren SOA aplikazioekin ari zarete. Beste batzuk zerbitzaririk gabeko aplikazioetara mugitzen ari dira, eta batzuk aurrekoen konbinazioak ezartzen ari dira. Artikulu honetan azaltzen diren printzipioak sistema horietako bakoitzean aplikatzen dira aldaketa txiki batzuekin.
Printzipioak
Aplikazio moderno bat eta pila moderno bat zer den oinarrizko ulertzen dugunean, aplikazio moderno bat diseinatzeko, inplementatzeko eta mantentzeko balioko dizuten arkitektura eta diseinu printzipioetan murgiltzeko garaia da.
Printzipioetako bat "aplikazio txikiak eraikitzea" da, dei dezagun txikitasunaren printzipioa. Zati mugikor asko dituzten aplikazio izugarri konplexuak daude. Era berean, osagai txiki eta diskretuetatik aplikazio bat eraikitzeak errazagoa egiten du diseinua, mantentzea eta erabilera orokorrean. (Kontuan izan βerraz egiten duβ esan genuela eta ez βerraz egiten duβ).
Bigarren printzipioa garatzaileen produktibitatea areagotu dezakegula garatzen ari diren eginbideetan zentratzen lagunduz, inplementazio garaian azpiegituraz eta CI/CDaz kezkatu gabe. Beraz, laburbilduz, gure planteamendua garatzaileei zuzenduta.
Azkenik, zure aplikazioari buruzko guztia sarera konektatuta egon behar da. Azken 20 urteotan, asko aurreratu dugu sareko etorkizunerantz, sareak azkarragoak eta aplikazioak konplexuagoak direlako. Lehen ikusi dugunez, aplikazio moderno bat sare batean erabili behar dute hainbat bezerok. Sare-pentsamendua arkitekturari aplikatzeak ondo egokitzen zaizkion onura handiak ditu txikitasunaren printzipioa eta ikuspegiaren kontzeptua, garatzaileei zuzenduta.
Aplikazio bat diseinatzean eta inplementatzean printzipio hauek kontuan hartzen badituzu, abantaila nabarmena izango duzu zure produktua garatzeko eta entregatzeko.
Ikus ditzagun hiru printzipio hauek zehatzago.
Txikitasunaren printzipioa
Giza garunarentzat zaila da informazio kopuru handiak aldi berean hautematea. Psikologian, karga kognitiboa terminoak informazioa memorian gordetzeko behar den esfortzu mentala adierazten du. Garatzaileen karga kognitiboa murriztea lehentasuna da, orduan arazoa konpontzera bideratu daitezkeelako aplikazio osoaren egungo eredu konplexua eta garatzen ari diren ezaugarriak buruan eduki beharrean.
Aplikazioak honako arrazoi hauengatik deskonposatzen dira:
- Garatzaileen karga kognitiboa murriztea;
- Probak azkartzea eta sinplifikatzea;
- Aplikazioan aldaketak azkar bidaltzea.
Garatzaileen karga kognitiboa murrizteko hainbat modu daude, eta hor sartzen da txikitasunaren printzipioa.
Beraz, karga kognitiboa murrizteko hiru modu:
- Murriztu eginbide berri bat garatzerakoan kontuan hartu behar duten denbora-tartea: zenbat eta denbora-tarte laburragoa izan, orduan eta karga kognitiboa txikiagoa izango da.
- Murriztu aldi berean lantzen ari den kodea - kode gutxiago - karga gutxiago.
- Sinplifikatu zure aplikazioan aldaketak egiteko prozesua.
Garapen-epeak murriztea
Itzuli gaitezen metodologia garaietara waterfall garapen-prozesurako estandarra zen, eta aplikazio bat garatzeko edo eguneratzeko sei hilabetetik bi urteko epeak ohiko praktika ziren. Normalean, ingeniariek lehenik dokumentu garrantzitsuak irakurtzen zituzten, hala nola, produktuen eskakizunak (PRD), sistemaren erreferentzia dokumentua (SRD), arkitektura plana, eta gauza horiek guztiak bateratzen hasten ziren eredu kognitibo batean, zeinaren arabera kodea idatzi zuten. Eskakizunak, eta, beraz, arkitektura aldatu zirenez, ahalegin handiak egin behar izan ziren talde osoa eredu kognitiboaren eguneratzeen berri izateko. Kasurik txarrenean, ikuspegi honek lana geldiarazi besterik ez luke egin.
Aplikazioen garapen prozesuan aldaketarik handiena metodologia arinaren sarrera izan zen. Metodologiaren ezaugarri nagusietako bat agile - Hau garapen iteratiboa da. Era berean, horrek ingeniarien karga kognitiboa murriztea dakar. Garapen-taldeari aplikazioa ziklo luze batean inplementatu beharrean, agile Ikuspegiari esker, azkar probatu eta heda daitezkeen kode kopuru txikietan zentratu zaitezke, feedbacka jasoz. Aplikazio baten karga kognitiboa sei hilabeteko denbora-tartetik bi urteko izatera pasatu da, zehaztapen kopuru handiarekin, bi asteko funtzio gehigarri edo aldatzera, aplikazio handi baten ulermen zabalago batera bideratuz.
Fokua aplikazio masibo batetik bi asteko esprintean osa daitezkeen ezaugarri txiki zehatzetara aldatzea, hurrengo esprintetik eginbide bat baino gehiago kontuan izan gabe, aldaketa nabarmena da. Horrek garapenaren produktibitatea areagotzea ahalbidetu zuen, karga kognitiboa murriztuz, etengabe aldatzen baitzen.
Metodologian agile azken aplikazioa jatorrizko kontzeptuaren bertsio apur bat aldatua izatea espero da, beraz, azken garapen-puntua anbiguoa da nahitaez. Sprint zehatz bakoitzaren emaitzak soilik izan daitezke argiak eta zehatzak.
Kode-oinarri txikiak
Karga kognitiboa murrizteko hurrengo urratsa kodearen oinarria murriztea da. Normalean, aplikazio modernoak izugarriak dira: enpresa-aplikazio sendoak milaka fitxategi eta ehunka milaka kode lerro izan ditzake. Fitxategien antolaketaren arabera, kodearen eta fitxategien arteko loturak eta menpekotasunak agerikoak izan daitezke edo ez. Kodearen exekuzioa bera araztea ere arazotsua izan daiteke, erabilitako liburutegien eta arazketa-tresnek liburutegi/pakete/moduluen eta erabiltzaile-kodeen artean nola bereizten duten.
Aplikazio baten kodearen eredu mental funtzionala eraikitzeak denbora asko behar izan dezake, berriro ere karga kognitibo handia jarriz garatzaileari. Hau bereziki egia da kode-oinarri monolitikoetan, non kode kopuru handia dagoen, osagai funtzionalen arteko elkarrekintzak ez daude argi eta garbi definituta, eta arreta-objektuen bereizketa sarri lausotu egiten da, muga funtzionalak errespetatzen ez direlako.
Ingeniarien karga kognitiboa murrizteko modu eraginkor bat mikrozerbitzuen arkitekturara pasatzea da. Mikrozerbitzuen ikuspegian, zerbitzu bakoitza funtzio multzo batean zentratzen da; zerbitzuaren esanahia definitu eta ulergarria izan ohi da. Zerbitzuaren mugak ere argiak dira - gogoratu zerbitzuarekiko komunikazioa API baten bidez egiten dela, beraz, zerbitzu batek sortutako datuak erraz transferi daitezkeela beste batera.
Beste zerbitzu batzuekin elkarrekintza normalean erabiltzaile-zerbitzu gutxi batzuetara eta API dei soil eta garbiak erabiltzen dituzten hornitzaile-zerbitzu batzuetara mugatzen da, hala nola REST. Horrek esan nahi du ingeniariaren karga kognitiboa larriki murrizten dela. Erronka handiena zerbitzuen interakzio eredua ulertzea eta transakzioak bezalako gauzak hainbat zerbitzutan nola gertatzen diren ulertzea izaten jarraitzen du. Azken finean, mikrozerbitzuak erabiltzeak karga kognitiboa murrizten du kode kopurua murriztuz, zerbitzuen muga argiak definituz eta erabiltzaile eta hornitzaile harremanari buruzko ikuspegia emanez.
Aldaketa gehigarriak txikiak
Printzipioaren azken elementua txikia aldaketaren kudeaketa da. Garatzaileentzat bereziki tentagarria da kode-oinarri bat aztertzea (baita, agian, kode zaharragoa ere) eta esatea: "Hau kaskarra da, gauza hau berridatzi behar dugu". Batzuetan erabaki egokia da, eta beste batzuetan ez. Eredu globalaren aldaketen zama garapen-taldearen gainean jartzen du, eta horrek karga kognitibo handia eragiten du. Hobe da ingeniariek esprintean egin ditzaketen aldaketetan zentratzea, eta, horrela, beharrezkoak diren funtzionalitateak garaiz zabal ditzaten, pixkanaka bada ere. Azken produktuak aurrez aurreikusitakoaren antza izan behar du, baina aldaketa eta proba batzuk eginda, bezeroaren beharretara egokitzeko.
Kode zati handiak berridazten direnean, batzuetan ezinezkoa da aldaketa bat azkar ematea, sistemaren beste menpekotasunak sartzen baitira jokoan. Aldaketen fluxua kontrolatzeko, eginbideak ezkutatzea erabil dezakezu. Funtsean, horrek esan nahi du funtzionaltasuna hor dagoela ekoizpenean, baina ez dago erabilgarri ingurune-aldagaien ezarpenen bidez (env-var) edo beste edozein konfigurazio mekanismoren bidez. Kodeak kalitate-kontroleko prozesu guztiak gainditu baditu, baliteke ekoizpenean ezkutuko egoera batean amaitzea. Hala ere, estrategia honek funtzioa azkenean gaituta badago bakarrik funtzionatzen du. Bestela, kodea nahasi eta karga kognitiboa gehituko du garatzaileak produktiboa izateko aurre egin beharko dion. Aldaketen kudeaketak eta gehitze-aldaketak beraiek garatzaileen karga kognitiboa maila irisgarri batean mantentzen laguntzen dute.
Ingeniariek zailtasun asko gainditu behar dituzte funtzionalitate osagarriak besterik ez dituztenean ere. Zuhurra litzateke zuzendaritzak taldearen alferrikako lan karga murriztea, funtzionalitatearen funtsezko elementuetan zentratu ahal izateko. Zure garapen taldeari laguntzeko hiru gauza egin ditzakezu:
- Erabili metodologia
agile, taldeak funtsezko ezaugarrietan arreta jarri behar duen denbora-tartea mugatzeko. - Inplementatu zure aplikazioa hainbat mikrozerbitzu gisa. Honek sartutako ezaugarrien kopurua mugatuko du eta lanean ari diren bitartean karga kognitiboa duten mugak indartuko ditu.
- Hobestu aldaketa gehigarriak handi eta zailak baino, aldatu kode txikiak. Erabili eginbidea ezkutatzea aldaketak ezartzeko, gehitu ondoren berehala ikusgai egongo ez badira ere.
Zure lanean txikitasunaren printzipioa aplikatzen baduzu, zure taldea askoz alaiagoa izango da, beharrezkoak diren funtzioak eskaintzera hobeto bideratuko da eta kalitate-aldaketak azkarrago zabaltzeko aukera handiagoa izango du. Baina horrek ez du esan nahi lana konplexuagoa izan daitekeenik; batzuetan, aitzitik, funtzionaltasun berriak sartzeak hainbat zerbitzu aldatzea eskatzen du eta prozesu hori arkitektura monolitiko batean antzeko bat baino konplexuagoa izan daiteke. Nolanahi ere, hurbilketa erabiltzearen onurak apur bat merezi du.
Lehen zatiaren amaiera.
Laster argitaratuko dugu itzulpenaren bigarren zatia, baina orain zuen iruzkinen zain gaude eta gonbidatzen zaituztegu. , gaur arratsaldeko 20.00etan izango dena.
Iturria: www.habr.com