Hæ vinir. Í aðdraganda námskeiðsins , deila jafnan með þér þýðingunni á gagnlegu efni.
Hugbúnaður leysir sífellt fleiri hversdagsleg verkefni en verður sífellt flóknari. Eins og Marc Andressen sagði einu sinni, það eyðir heiminum.
Fyrir vikið hefur hvernig forrit eru þróuð og afhent hafa breyst verulega á undanförnum árum. Þetta voru breytingar á tektónískum mælikvarða sem leiddu af sér sett af meginreglum. Þessar meginreglur hafa reynst gagnlegar við að byggja upp hóp, hanna, þróa og koma forritinu þínu til endanotenda.
Hægt er að draga meginreglurnar saman sem hér segir: Forritið ætti að vera lítið, byggt á vefnum og hafa þróunarmiðaðan arkitektúr. Með þessar þrjár meginreglur í huga geturðu búið til öflugt, enda-til-enda forrit sem hægt er að koma á fljótlegan og öruggan hátt til endanotandans og er auðvelt að skala og stækka.
Hver af fyrirhuguðu meginreglunum hefur fjölda þátta sem við munum ræða til að sýna hvernig hver regla stuðlar að lokamarkmiðinu, sem er hröð afhending áreiðanlegra forrita sem auðvelt er að viðhalda og nota. Við munum skoða meginreglurnar í tengslum við andstæður þeirra til að skýra hvað það þýðir, segjum: "Gakktu úr skugga um að þú notir smæðarreglan'.
Við vonum að þessi grein muni hvetja þig til að nota fyrirhugaðar meginreglur til að byggja upp nútíma forrit, sem mun veita sameinaða nálgun við hönnun í samhengi við sívaxandi tæknistafla.
Með því að beita þessum meginreglum muntu finna sjálfan þig að nýta þér nýjustu strauma í hugbúnaðarþróun, þar á meðal við þróun og afhendingu forrita, notkun gáma (td. ) og gámahljómsveitarramma (til dæmis, ), notkun örþjónustu (þar á meðal örþjónustuarkitektúr и fyrir smáþjónustuforrit.
Hvað er nútíma forrit?
Nútíma forrit? Nútíma stafla? Hvað þýðir "nútímalegt" nákvæmlega?
Flestir verktaki hafa aðeins almenna hugmynd um hvað nútíma forrit samanstendur af, svo það er nauðsynlegt að skilgreina þetta hugtak skýrt.
Nútímalegt app styður marga viðskiptavini, hvort sem það er React JavaScript bókasafn notendaviðmót, Android eða iOS farsímaforrit eða app sem tengist öðru API. Nútíma forrit felur í sér ótiltekinn fjölda viðskiptavina sem það veitir gögn eða þjónustu fyrir.
Nútímalegt forrit býður upp á API til að fá aðgang að umbeðnum gögnum og þjónustu. API ætti að vera óbreytanlegt og stöðugt og ekki skrifað sérstaklega fyrir ákveðna beiðni frá tilteknum viðskiptavini. API er fáanlegt yfir HTTP(S) og veitir aðgang að allri virkni sem til er í GUI eða CLI.
Gögnin verða að vera tiltæk á almennt viðurkenndu, samhæfðu sniði eins og JSON. API afhjúpar hluti og þjónustu á hreinan, skipulagðan hátt, eins og RESTful API eða GraphQL veita viðeigandi viðmót.
Nútíma forrit eru byggð á nútímastaflanum og nútímastaflan er staflan sem styður slík forrit, í sömu röð. Þessi stafli gerir þróunaraðila kleift að búa til forrit með HTTP viðmóti og hreinum API endapunktum. Valin nálgun mun leyfa forritinu þínu að taka á móti og senda gögn á JSON sniði auðveldlega. Með öðrum orðum, nútíma stafla samsvarar þáttum tólfþátta umsóknarinnar fyrir .
Vinsælar útgáfur af þessari tegund af stafla eru byggðar á , , , , и . Örþjónustuarkitektúr táknar dæmi um nútíma stafla sem er útfærður á hverju af nefndum tungumálum.
Vinsamlegast athugaðu að við erum ekki að mælast eingöngu með örþjónustuaðferð. Mörg ykkar eru að vinna með einlita sem þurfa að þróast á meðan aðrir eru að fást við SOA forrit sem eru að stækka og þróast í að verða smáþjónustuforrit. Enn aðrir eru að færast í átt að netþjónalausum forritum og sumir eru að innleiða samsetningar af ofangreindu. Meginreglurnar sem lýst er í greininni eiga við um hvert þessara kerfa með aðeins nokkrum smávægilegum breytingum.
Principles
Nú þegar við höfum sameiginlegan skilning á því hvað nútíma forrit og nútíma stafla eru, er kominn tími til að kafa ofan í arkitektúr og þróunarreglur sem munu þjóna þér vel við að þróa, innleiða og viðhalda nútíma forriti.
Eitt af meginreglunum hljómar eins og "búa til lítil forrit", við skulum bara kalla það smæðarreglan. Það eru ótrúlega flókin forrit sem eru samsett úr mörgum hreyfanlegum hlutum. Að byggja upp forrit úr litlum, stakum hlutum gerir það aftur á móti auðveldara að hanna, viðhalda og vinna með það í heild. (Athugið að við sögðum „einfaldar“ ekki „gerir einfalda“).
Önnur reglan er sú að við getum aukið framleiðni þróunaraðila með því að hjálpa þeim að einbeita sér að eiginleikum sem þeir eru að þróa, en losa þá við innviði og CI/CD áhyggjur meðan á innleiðingu stendur. Svo, í hnotskurn, nálgun okkar einblínt á forritara.
Að lokum verður allt um forritið þitt að vera tengt við netið. Undanfarin 20 ár höfum við náð miklum framförum í átt að nettengdri framtíð þar sem netkerfi hafa orðið hraðari og forrit hafa orðið flóknari. Eins og við höfum þegar séð, verður að nota nútímalegt forrit yfir netkerfi af mörgum mismunandi viðskiptavinum. Að beita nethugsun í arkitektúr hefur verulegan ávinning sem passar vel við smæðarreglan og hugmyndina um nálgunina, þróunarmiðuð.
Ef þú hefur þessar meginreglur í huga þegar þú hannar og innleiðir forrit muntu hafa óneitanlega yfirburði í þróun og afhendingu vöru þinnar.
Við skulum skoða þessar þrjár meginreglur nánar.
Smæðareglan
Það er erfitt fyrir mannsheilann að skynja mikið magn upplýsinga á sama tíma. Í sálfræði vísar hugtakið hugrænt álag til heildarmagns andlegrar áreynslu sem þarf til að halda upplýsingum í minni. Að draga úr vitsmunalegu álagi á forritara er forgangsverkefni vegna þess að það gerir þeim kleift að einbeita sér að því að leysa vandamálið í stað þess að halda núverandi flóknu líkani af öllu forritinu og eiginleikum sem verið er að þróa í hausnum á þeim.
Umsóknir brotna niður af eftirfarandi ástæðum:
- Minnkað vitsmunalegt álag á þróunaraðila;
- Hröðun og einföldun prófana;
- Fljótleg afgreiðsla á breytingum á forritinu.
Það eru nokkrar leiðir til að draga úr vitsmunalegu álagi á þróunaraðila, og það er þar sem meginreglan um smæð kemur við sögu.
Svo hér eru þrjár leiðir til að draga úr vitsmunalegu álagi:
- Dragðu úr tímaramma sem þeir þurfa að hafa í huga þegar þeir þróa nýjan eiginleika - því styttri tímarammi, því minni er vitsmunalegt álag.
- Minnka magn kóða sem unnið er með í eitt skipti - minni kóða - minna álag.
- Einfaldaðu ferlið við að gera stigvaxandi breytingar á forriti.
Að stytta þróunartímann
Við skulum hverfa aftur til daganna þegar aðferðafræðin waterfall var staðallinn fyrir þróunarferlið og tímarammar sex mánuðir til tveggja ára til að þróa eða uppfæra forrit voru algengar venjur. Venjulega myndu verkfræðingar fyrst lesa viðeigandi skjöl eins og vörukröfur (PRD), kerfisviðmiðunarskjal (SRD), arkitektúrteikningu og byrja að sameina alla þessa hluti saman í eitt vitræna líkan, samkvæmt því sem þeir kóðaðu. Þar sem kröfurnar og þar af leiðandi arkitektúrinn breyttust þurfti að gera alvarlegt átak til að upplýsa allt teymið um uppfærslur á vitræna líkaninu. Slík nálgun gæti í versta falli einfaldlega lamað verkið.
Stærsta breytingin á þróunarferli forrita var innleiðing á lipurri aðferðafræði. Eitt af megineinkennum aðferðafræðinnar agile er endurtekin þróun. Aftur á móti leiðir þetta til minnkunar á vitrænni álagi á verkfræðinga. Í stað þess að krefjast þess að þróunarteymið innleiði forritið í einni langri lotu, agile nálgun gerir þér kleift að einbeita þér að litlu magni af kóða sem hægt er að prófa fljótt og dreifa á sama tíma og þú færð endurgjöf. Vitsmunalegt álag appsins hefur færst úr sex mánaða til tveggja ára tímaramma með gríðarlegu magni af forskriftum fyrir tveggja vikna viðbót eða eiginleikabreytingu sem miðar að óskýrari skilningi á stóru forriti.
Það er veruleg breyting að færa fókusinn frá gríðarlegu forriti yfir í tiltekna litla eiginleika sem hægt er að klára á tveggja vikna spretti, með ekki meira en einn eiginleika á undan næsta sprett í huga. Þetta gerði okkur kleift að auka framleiðni í þróun og draga úr vitsmunalegu álaginu, sem sveiflaðist stöðugt.
Í aðferðafræði agile Búist er við að lokaumsóknin verði lítillega breytt útgáfa af upprunalegu hugmyndinni, svo lokaþróunarpunkturinn er endilega óljós. Aðeins niðurstöður hvers tiltekins spretts geta verið skýrar og nákvæmar.
Lítil kóðabasar
Næsta skref í að draga úr vitsmunalegu álagi er að minnka kóðagrunninn. Að jafnaði eru nútímaforrit gríðarstór - öflugt fyrirtækisforrit getur samanstendur af þúsundum skráa og hundruð þúsunda kóðalína. Það fer eftir því hvernig skrárnar eru skipulagðar, tenglar og ósjálfstæði milli kóða og skráa geta verið augljós, eða öfugt. Jafnvel framkvæmd kembikóða sjálf getur verið erfið, allt eftir söfnunum sem notuð eru og hversu vel kembiforritin gera greinarmun á söfnum/pakka/einingum og sérsniðnum kóða.
Að byggja upp virkt andlegt líkan af kóða forrits getur tekið glæsilegan tíma og enn og aftur lagt mikla vitræna byrði á þróunaraðilann. Þetta á sérstaklega við um einhæfa kóðagrunna, þar sem mikið magn kóða er, þar sem víxlverkunin milli virkniþáttanna er ekki skýrt skilgreind og aðskilnaður athyglishluta er oft óskýr vegna þess að virknimörk eru ekki virt.
Ein áhrifaríka leiðin til að draga úr vitsmunalegu álagi á verkfræðinga er að fara yfir í örþjónustuarkitektúr. Í örþjónustunálgun leggur hver þjónusta áherslu á eitt sett af eiginleikum; á meðan merking þjónustunnar er venjulega skilgreind og skiljanleg. Mörk þjónustu eru líka skýr - mundu að samskipti við þjónustu fara fram í gegnum API, þannig að gögn sem myndast af einni þjónustu geta auðveldlega borist til annarrar.
Samskipti við aðra þjónustu takmarkast venjulega við nokkrar notendaþjónustur og nokkrar þjónustuveitur sem nota einföld og hrein API símtöl, svo sem notkun REST. Þetta þýðir að vitsmunalegt álag á verkfræðinginn minnkar verulega. Stærsta áskorunin er enn að skilja þjónustusamskiptalíkanið og hvernig hlutir eins og viðskipti gerast í mörgum þjónustum. Fyrir vikið dregur notkun á örþjónustum úr vitsmunalegu álagi með því að minnka magn kóða, skilgreina skýr þjónustumörk og veita skilning á tengslum notenda og veitenda.
Litlar stigvaxandi breytingar
Síðasti þáttur reglunnar smæð er breytingastjórnun. Það er sérstök freisting fyrir forritara að skoða kóðagrunninn (jafnvel kannski sinn eigin eldri kóða) og segja: "Þetta er vitleysa, við þurfum að endurskrifa þetta allt." Stundum er þetta rétt ákvörðun og stundum ekki. Það leggur byrðarnar af alþjóðlegum líkanabreytingum á þróunarteymið, sem aftur leiðir til gríðarlegs vitrænnar álags. Það er betra fyrir verkfræðinga að einbeita sér að þeim breytingum sem þeir geta gert á sprettinum, svo þeir geti útfært nauðsynlega virkni tímanlega, þó smám saman. Lokavaran ætti að líkjast þeirri sem fyrirhuguð var, en með nokkrum breytingum og prófunum til að henta þörfum viðskiptavinarins.
Þegar stór hluti af kóða er endurskrifaður er stundum ekki hægt að skila breytingunni fljótt vegna þess að önnur kerfisháð kemur við sögu. Til að stjórna flæði breytinga geturðu notað lögun felur. Í grundvallaratriðum þýðir þetta að virknin er í framleiðslu, en hún er ekki tiltæk með því að nota umhverfisbreytustillingarnar (env-var) eða einhverja aðra stillingaraðferð. Ef kóðinn hefur staðist öll gæðaeftirlitsferla getur hann endað í framleiðslu í duldu ástandi. Hins vegar virkar þessi aðferð aðeins ef aðgerðin er að lokum virkjað. Annars mun það aðeins rugla kóðanum og bæta við vitrænni álagi sem verktaki þarf að takast á við til að vera afkastamikill. Breytingastjórnun og stigvaxandi breytingar sjálfar hjálpa til við að halda vitrænu álagi þróunaraðila á viðráðanlegu stigi.
Verkfræðingar verða að sigrast á mörgum erfiðleikum, jafnvel með einföldu kynningu á viðbótarvirkni. Af hálfu stjórnenda væri skynsamlegt að draga úr óþarfa álagi á teymið þannig að það geti einbeitt sér að lykilþáttum. Það eru þrjú atriði sem þú getur gert til að hjálpa þróunarteymi þínu:
- Notaðu aðferðafræði
agileað takmarka þann tíma sem teymið verður að einbeita sér að helstu eiginleikum. - Innleiða forritið þitt sem margar örþjónustur. Þetta mun takmarka fjölda eiginleika sem hægt er að útfæra og styrkja mörkin sem halda vitsmunalegu álaginu í vinnunni.
- Kjósið stigvaxandi breytingar fram yfir stóra og ómeðhöndlaða, breyttu litlum kóða. Notaðu að fela eiginleika til að innleiða breytingar jafnvel þótt þær verði ekki sýnilegar strax eftir að þeim hefur verið bætt við.
Ef þú beitir smæðarreglunni í starfi þínu, mun teymið þitt verða miklu ánægðara, einbeita sér betur að því að innleiða nauðsynlega eiginleika og líklegra til að hrinda út eigindlegum breytingum hraðar. En þetta þýðir ekki að verkið geti ekki orðið flóknara, stundum, þvert á móti, krefst innleiðing nýrrar virkni breytingar á nokkrum þjónustum og þetta ferli getur verið erfiðara en svipað í einhæfum arkitektúr. Í öllum tilvikum er ávinningurinn af því að taka smæðaraðferðina þess virði.
Lok fyrri hluta.
Bráðum munum við birta seinni hluta þýðingarinnar og nú bíðum við eftir athugasemdum þínum og bjóðum þér til , sem fer fram í dag klukkan 20.00.
Heimild: www.habr.com