Hallo vriende. In afwagting van die bekendstelling van die kursus , deel tradisioneel die vertaling van nuttige materiaal met jou.
Sagteware los al hoe meer alledaagse take op, terwyl dit meer en meer kompleks word. Soos Marc Andressen eenkeer gesê het, dit verteer die wêreld.
Gevolglik het die manier waarop toepassings ontwikkel en gelewer word dramaties verander oor die afgelope paar jaar. Dit was verskuiwings van tektoniese skaal wat gelei het tot 'n stel beginsels. Hierdie beginsels het bewys dat dit nuttig is in spanbou, ontwerp, ontwikkeling en lewering van jou toepassing aan eindgebruikers.
Die beginsels kan soos volg opgesom word: die toepassing moet klein, webgebaseerd wees en 'n ontwikkelaargesentreerde argitektuur hê. Met hierdie drie beginsels in gedagte, kan jy 'n robuuste, end-tot-end-toepassing skep wat vinnig en veilig aan die eindgebruiker gelewer kan word, en maklik skaalbaar en uitbreibaar is.
Elkeen van die voorgestelde beginsels het 'n aantal aspekte wat ons sal bespreek om te wys hoe elke beginsel bydra tot die uiteindelike doel, wat die vinnige lewering van betroubare toepassings is wat maklik is om te onderhou en te gebruik. Ons sal kyk na die beginsels in verhouding tot hul teenoorgesteldes om te verduidelik wat dit beteken, sê: "Maak seker jy gebruik kleinheid beginsel".
Ons hoop dat hierdie artikel jou sal aanmoedig om die voorgestelde beginsels vir die bou van moderne toepassings te gebruik, wat 'n verenigde benadering tot ontwerp sal bied in die konteks van 'n steeds groeiende tegnologiestapel.
Deur hierdie beginsels toe te pas, sal jy vind dat jy voordeel trek uit die nuutste neigings in sagteware-ontwikkeling, insluitend die tot die ontwikkeling en aflewering van toepassings, die gebruik van houers (bv. ) en houerorkestrasieraamwerke (byvoorbeeld, ), die gebruik van mikrodienste (insluitend die Mikrodiensargitektuur и vir mikrodienstoepassings.
Wat is 'n moderne toepassing?
Moderne toepassings? Moderne stapel? Wat presies beteken "modern"?
Die meeste ontwikkelaars het slegs 'n algemene idee van waaruit 'n moderne toepassing bestaan, daarom is dit nodig om hierdie konsep duidelik te definieer.
'n Moderne toepassing ondersteun veelvuldige kliënte, of dit nou 'n React JavaScript-biblioteekgebruikerskoppelvlak, 'n Android- of iOS-mobiele toepassing is, of 'n toepassing wat aan 'n ander API koppel. 'n Moderne toepassing impliseer 'n onbepaalde aantal kliënte waarvoor dit data of dienste verskaf.
'n Moderne toepassing bied 'n API om toegang tot die gevraagde data en dienste te verkry. Die API moet onveranderlik en konstant wees, en nie spesifiek geskryf vir 'n spesifieke versoek van 'n spesifieke kliënt nie. Die API is beskikbaar oor HTTP(S) en bied toegang tot al die funksies wat in die GUI of CLI beskikbaar is.
Die data moet beskikbaar wees in 'n algemeen aanvaarde, interoperabele formaat soos JSON. 'n API stel voorwerpe en dienste op 'n skoon, georganiseerde manier bloot, soos RESTful API of GraphQL bied 'n ordentlike koppelvlak.
Moderne toepassings word op die moderne stapel gebou, en die moderne stapel is onderskeidelik die stapel wat sulke toepassings ondersteun. Hierdie stapel laat 'n ontwikkelaar toe om maklik 'n toepassing te skep met 'n HTTP-koppelvlak en duidelike API-eindpunte. Die gekose benadering sal jou aansoek toelaat om data maklik in JSON-formaat te ontvang en te stuur. Met ander woorde, die moderne stapel stem ooreen met die elemente van die Twaalf-faktor Aansoek vir .
Gewilde weergawes van hierdie tipe stapel is gebaseer op , , , , и . Mikrodiensargitektuur verteenwoordig 'n voorbeeld van 'n moderne stapel wat in elk van die genoemde tale geïmplementeer is.
Neem asseblief kennis dat ons nie 'n eksklusiewe mikrodiensbenadering voorstaan nie. Baie van julle werk met monoliete wat moet ontwikkel, terwyl ander met SOA-toepassings te doen het wat uitbrei en ontwikkel om mikrodienstoepassings te word. Nog ander beweeg na bedienerlose toepassings, en sommige implementeer kombinasies van bogenoemde. Die beginsels wat in die artikel uiteengesit word, is van toepassing op elk van hierdie stelsels met slegs 'n paar klein wysigings.
Beginsels
Noudat ons 'n algemene begrip het van wat 'n moderne toepassing en moderne stapel is, is dit tyd om te duik in die argitektuur- en ontwikkelingsbeginsels wat jou goed sal dien in die ontwikkeling, implementering en instandhouding van 'n moderne toepassing.
Een van die beginsels klink soos “maak klein aansoeke”, kom ons noem dit maar kleinheid beginsel. Daar is ongelooflik komplekse toepassings wat uit baie bewegende dele bestaan. Op sy beurt maak die bou van 'n toepassing uit klein, diskrete komponente dit makliker om dit as 'n geheel te ontwerp, in stand te hou en daarmee te werk. (Let daarop dat ons gesê het "vereenvoudig" nie "maak eenvoudig nie").
Die tweede beginsel is dat ons ontwikkelaarproduktiwiteit kan verhoog deur hulle te help om te fokus op die kenmerke wat hulle ontwikkel, terwyl hulle hulle bevry van infrastruktuur en CI/CD-kwessies tydens implementering. Dus, in 'n neutedop, ons benadering gefokus op ontwikkelaars.
Ten slotte moet alles oor jou toepassing aan die netwerk gekoppel wees. Oor die afgelope 20 jaar het ons groot vordering gemaak in die rigting van 'n netwerktoekoms namate netwerke vinniger word en toepassings meer kompleks word. Soos ons reeds gesien het, moet 'n moderne toepassing oor 'n netwerk deur baie verskillende kliënte gebruik word. Die toepassing van netwerkdenke op argitektuur hou aansienlike voordele in wat goed daarmee saamgaan kleinheid beginsel en die konsep van die benadering, ontwikkelaar georiënteerd.
As jy hierdie beginsels in gedagte hou wanneer jy 'n toepassing ontwerp en implementeer, sal jy 'n onteenseglike voordeel in die ontwikkeling en aflewering van jou produk hê.
Kom ons kyk in meer detail na hierdie drie beginsels.
Kleinheid beginsel
Dit is moeilik vir die menslike brein om 'n groot hoeveelheid inligting op dieselfde tyd waar te neem. In sielkunde verwys die term kognitiewe lading na die totale hoeveelheid geestelike inspanning wat nodig is om inligting in die geheue te behou. Die vermindering van die kognitiewe las op ontwikkelaars is 'n prioriteit omdat dit hulle in staat stel om te fokus op die oplossing van die probleem in plaas daarvan om die huidige komplekse model van die hele toepassing en die kenmerke wat ontwikkel word in hul kop te hou.
Aansoeke ontbind om die volgende redes:
- Verminderde kognitiewe las op ontwikkelaars;
- Versnelling en vereenvoudiging van toetsing;
- Vinnige aflewering van veranderinge in die toepassing.
Daar is verskeie maniere om die kognitiewe las op ontwikkelaars te verminder, en dit is waar die beginsel van kleinheid ter sprake kom.
Hier is dus drie maniere om kognitiewe lading te verminder:
- Verkort die tydsraamwerk wat hulle moet oorweeg wanneer hulle 'n nuwe kenmerk ontwikkel – hoe korter die tydraamwerk, hoe laer is die kognitiewe las.
- Verminder die hoeveelheid kode waarop eenmalige werk uitgevoer word - minder kode - minder vrag.
- Vereenvoudig die proses om inkrementele veranderinge aan 'n toepassing te maak.
Vermindering van die ontwikkelingstydraamwerk
Kom ons gaan terug na die dae toe die metodologie waterfall was die standaard vir die ontwikkelingsproses, en tydraamwerke van ses maande tot twee jaar vir die ontwikkeling of opdatering van 'n toepassing was algemene praktyk. Tipies sal ingenieurs eers relevante dokumente lees soos die produkvereistes (PRD), stelselverwysingsdokument (SRD), argitektuurbloudruk, en begin om al hierdie dinge saam te kombineer in een kognitiewe model, waarvolgens hulle gekodeer het. Aangesien die vereistes en gevolglik die argitektuur verander het, moes 'n ernstige poging aangewend word om die hele span in te lig oor opdaterings aan die kognitiewe model. So 'n benadering kan in die ergste geval die werk eenvoudig lamlê.
Die grootste verandering in die toepassingsontwikkelingsproses was die bekendstelling van die ratse metodologie. Een van die hoofkenmerke van die metodologie agile is 'n iteratiewe ontwikkeling. Op sy beurt lei dit tot 'n vermindering in die kognitiewe las op ingenieurs. In plaas daarvan om van die ontwikkelingspan te vereis om die toepassing in een lang siklus te implementeer, agile benadering laat jou toe om te fokus op klein hoeveelhede kode wat vinnig getoets en ontplooi kan word, terwyl jy ook terugvoer ontvang. Die toepassing se kognitiewe las het verskuif van 'n tydraamwerk van ses maande na twee jaar met 'n groot aantal spesifikasies vir 'n twee weke byvoeging of kenmerkverandering wat 'n meer vaag begrip van 'n groot toepassing gerig het.
Die verskuiwing van die fokus van 'n massiewe toepassing na spesifieke klein kenmerke wat in 'n tweeweekse naelloop voltooi kan word, met nie meer as een kenmerk voor die volgende naelloop in gedagte nie, is 'n beduidende verandering. Dit het ons in staat gestel om ontwikkelingsproduktiwiteit te verhoog, terwyl die kognitiewe las, wat voortdurend gewissel het, verminder het.
In metodologie agile die finale toepassing sal na verwagting 'n effens gewysigde weergawe van die oorspronklike konsep wees, so die eindpunt van ontwikkeling is noodwendig dubbelsinnig. Slegs die resultate van elke spesifieke naelloop kan duidelik en presies wees.
Klein kodebasisse
Die volgende stap in die vermindering van kognitiewe lading is om die kodebasis te verminder. Moderne toepassings is as 'n reël massief - 'n robuuste ondernemingstoepassing kan uit duisende lêers en honderdduisende reëls kode bestaan. Afhangende van hoe die lêers georganiseer is, kan skakels en afhanklikhede tussen kode en lêers voor die hand liggend wees, of omgekeerd. Selfs die uitvoering van ontfoutingskode self kan problematies wees, afhangende van die biblioteke wat gebruik word en hoe goed die ontfoutingsnutsmiddels onderskei tussen biblioteke/pakkette/modules en pasgemaakte kode.
Die bou van 'n werkende verstandelike model van 'n toepassing se kode kan 'n indrukwekkende hoeveelheid tyd neem, en weereens 'n groot kognitiewe las op die ontwikkelaar plaas. Dit is veral waar vir monolitiese kodebasisse, waar daar 'n groot hoeveelheid kode is, waarvan die interaksie tussen die funksionele komponente nie duidelik gedefinieer is nie, en die skeiding van voorwerpe van aandag word dikwels vervaag omdat funksionele grense nie gerespekteer word nie.
Een van die effektiewe maniere om die kognitiewe las op ingenieurs te verminder, is om na 'n mikrodiensargitektuur te beweeg. In 'n mikrodiensbenadering fokus elke diens op een stel kenmerke; terwyl die betekenis van die diens gewoonlik omskryf en verstaanbaar is. Die grense van 'n diens is ook duidelik - onthou dat kommunikasie met 'n diens via 'n API gedoen word, sodat data wat deur een diens gegenereer word maklik na 'n ander deurgegee kan word.
Interaksie met ander dienste is gewoonlik beperk tot 'n paar gebruikersdienste en 'n paar verskafferdienste wat eenvoudige en skoon API-oproepe gebruik, soos die gebruik van REST. Dit beteken dat die kognitiewe las op die ingenieur ernstig verminder word. Die grootste uitdaging bly om die diensinteraksiemodel te verstaan en hoe dinge soos transaksies oor verskeie dienste gebeur. As gevolg hiervan verminder die gebruik van mikrodienste kognitiewe las deur die hoeveelheid kode te verminder, duidelike diensgrense te definieer en 'n begrip te verskaf van die verhouding tussen gebruikers en verskaffers.
Klein inkrementele veranderinge
Die laaste element van die beginsel kleinheid is veranderingsbestuur. Dit is 'n besondere versoeking vir ontwikkelaars om na die kodebasis (selfs dalk hul eie, ouer kode) te kyk en te sê: "Dit is kak, ons moet dit alles herskryf." Soms is dit die regte besluit, en soms nie. Dit plaas die las van globale modelverandering op die ontwikkelingspan, wat weer lei tot massiewe kognitiewe las. Dit is beter vir ingenieurs om te fokus op die veranderinge wat hulle tydens die naelloop kan maak, sodat hulle die nodige funksionaliteit betyds kan uitrol, alhoewel geleidelik. Die finale produk moet soos die voorafbeplande een lyk, maar met 'n paar wysigings en toetsing om by die kliënt se behoeftes te pas.
Wanneer groot gedeeltes kode herskryf word, is dit soms nie moontlik om die verandering vinnig te lewer nie omdat ander stelselafhanklikhede ter sprake kom. Om die vloei van veranderinge te beheer, kan jy kenmerkversteek gebruik. In beginsel beteken dit dat die funksionaliteit in produksie is, maar dit is nie beskikbaar met die omgewingsveranderlike instellings (env-var) of 'n ander konfigurasiemeganisme nie. As die kode al die gehaltebeheerprosesse geslaag het, kan dit in 'n latente toestand in produksie beland. Hierdie strategie werk egter net as die funksie uiteindelik geaktiveer word. Andersins sal dit net die kode deurmekaar maak en 'n kognitiewe las byvoeg wat die ontwikkelaar sal moet hanteer om produktief te wees. Veranderingsbestuur en inkrementele veranderinge self help om ontwikkelaars se kognitiewe las op 'n bekostigbare vlak te hou.
Ingenieurs moet baie probleme oorkom, selfs met die eenvoudige bekendstelling van bykomende funksionaliteit. Aan die kant van bestuur sal dit verstandig wees om die onnodige las op die span te verminder sodat dit op sleutel funksionele elemente kan fokus. Daar is drie dinge wat jy kan doen om jou ontwikkelingspan te help:
- Gebruik metodologie
agileom die tydsraamwerk waarin die span op sleutelkenmerke moet fokus, te beperk. - Implementeer jou aansoek as verskeie mikrodienste. Dit sal die aantal kenmerke wat geïmplementeer kan word beperk en die grense versterk wat die kognitiewe las aan die werk hou.
- Verkies inkrementele veranderinge bo groot en onhandelbare, verander klein stukkies kode. Gebruik kenmerkversteek om veranderinge te implementeer, selfs al sal dit nie onmiddellik sigbaar wees nadat dit bygevoeg is nie.
As jy die beginsel van kleinheid in jou werk toepas, sal jou span baie gelukkiger wees, beter gefokus wees op die implementering van die nodige kenmerke, en meer geneig om kwalitatiewe veranderinge vinniger uit te voer. Maar dit beteken nie dat die werk nie meer ingewikkeld kan word nie, soms, inteendeel, die bekendstelling van nuwe funksionaliteit vereis die wysiging van verskeie dienste, en hierdie proses kan moeiliker wees as soortgelyk in 'n monolitiese argitektuur. In elk geval, die voordele van die kleinheid-benadering is die moeite werd.
Einde van die eerste deel.
Binnekort sal ons die tweede deel van die vertaling publiseer, en nou wag ons vir jou kommentaar en nooi ons jou na , wat vandag om 20.00:XNUMX sal plaasvind.
Bron: will.com