Hallo freonen. Yn ôfwachting fan de start fan de kursus , tradisjoneel diele mei jo de oersetting fan brûkber materiaal.
Software lost mear en mear deistige taken op, wylst it hieltyd komplekser wurdt. As Marc Andressen ienris sei, it ferbrûkt de wrâld.
As resultaat is de manier wêrop applikaasjes wurde ûntwikkele en levere de ôfrûne jierren dramatysk feroare. Dit wiene ferskowings fan tektoanyske skaal dy't resultearre yn in set fan prinsipes. Dizze prinsipes hawwe bewiisd nuttich te wêzen yn teambou, ûntwerpen, ûntwikkeljen en leverjen fan jo applikaasje oan ein brûkers.
De prinsipes kinne wurde gearfette as folget: de applikaasje moat lyts wêze, web-basearre, en hawwe in ûntwikkelders-sintraal arsjitektuer. Mei dizze trije prinsipes yn gedachten, kinne jo meitsje in robúst, ein-to-ein applikaasje dat kin wurde fluch en feilich levere oan de ein brûker, en is maklik scalable en útwreidzjen.
Elk fan 'e foarstelde prinsipes hat in oantal aspekten dy't wy sille beprate om sjen te litten hoe't elk prinsipe bydraacht oan it úteinlike doel, dat is de rappe levering fan betroubere applikaasjes dy't maklik te ûnderhâlden en te brûken binne. Wy sille nei de prinsipes sjen yn relaasje ta har tsjinstellingen om te ferdúdlikjen wat it betsjut, sis: "Soargje der wis fan dat jo brûke lytsheid prinsipe".
Wy hoopje dat dit artikel jo sil stimulearje om de foarstelde prinsipes te brûken foar it bouwen fan moderne applikaasjes, dy't in unifoarme oanpak foar ûntwerp sille leverje yn 'e kontekst fan in hieltyd groeiende technologystapel.
Troch it tapassen fan dizze prinsipes, jimme sille fine dat jo nimme foardiel fan de nijste trends yn software ûntwikkeling, ynklusyf de oan it ûntwikkeljen en leverjen fan applikaasjes, it brûken fan konteners (bygelyks, ) en kontenerorkestraasjekaders (bygelyks, ), it brûken fan mikrotsjinsten (ynklusyf de Microservice Architecture и foar mikroserviceapplikaasjes.
Wat is in moderne applikaasje?
Moderne applikaasjes? Moderne stapel? Wat betsjut "modern" krekt?
De measte ûntwikkelders hawwe mar in algemien idee fan wêrfan in moderne applikaasje bestiet, dus it is needsaaklik om dit konsept dúdlik te definiearjen.
In moderne app stipet meardere kliïnten, of it no in brûkersynterface fan 'e React JavaScript-bibleteek is, in Android- as iOS mobile app, as in app dy't ferbynt mei in oare API. In moderne applikaasje betsjuttet in ûnbepaald oantal kliïnten wêrfoar it gegevens of tsjinsten leveret.
In moderne applikaasje leveret in API om tagong te krijen ta de frege gegevens en tsjinsten. De API moat ûnferoarlik en konstant wêze, en net spesifyk skreaun foar in spesifyk fersyk fan in spesifike kliïnt. De API is beskikber fia HTTP(S) en jout tagong ta alle funksjonaliteit beskikber yn de GUI of CLI.
De gegevens moatte beskikber wêze yn in algemien akseptearre, ynteroperabel formaat lykas JSON. In API bleatstelt objekten en tsjinsten op in skjinne, organisearre manier, lykas RESTful API of GraphQL jouwe in fatsoenlike ynterface.
Moderne applikaasjes binne boud op 'e moderne stack, en de moderne stack is respektivelik de stack dy't sokke applikaasjes stipet. Dizze stack lit in ûntwikkelder maklik in applikaasje meitsje mei in HTTP-ynterface en dúdlike API-einpunten. De keazen oanpak lit jo applikaasje maklik gegevens ûntfange en ferstjoere yn JSON-formaat. Mei oare wurden, de moderne stack komt oerien mei de eleminten fan de Tolve-Factor Applikaasje foar .
Populêre ferzjes fan dit soarte fan stack binne basearre op , , , , и . Microservice Architecture fertsjintwurdiget in foarbyld fan in moderne stack útfierd yn elk fan de neamde talen.
Tink derom dat wy net pleite foar in eksklusyf mikroservice-oanpak. In protte fan jo wurkje mei monoliten dy't moatte evoluearje, wylst oaren te krijen hawwe mei SOA-applikaasjes dy't útwreidzje en evoluearje om mikroserviceapplikaasjes te wurden. Noch oaren geane nei serverless applikaasjes, en guon implementearje kombinaasjes fan boppesteande. De prinsipes beskreaun yn it artikel binne fan tapassing op elk fan dizze systemen mei mar in pear lytse oanpassings.
Prinsipes
No't wy in mienskiplik begryp hawwe fan wat in moderne applikaasje en moderne stapel binne, is it tiid om te dûken yn 'e arsjitektuer en ûntwikkelingsprinsipes dy't jo goed sille tsjinje by it ûntwikkeljen, ymplemintearjen en ûnderhâlden fan in moderne applikaasje.
Ien fan 'e prinsipes klinkt as "lytse applikaasjes meitsje", litte wy it mar neame lytsheid prinsipe. D'r binne ongelooflijk komplekse applikaasjes dy't besteane út in protte bewegende dielen. Op syn beurt, it bouwen fan in applikaasje út lytse, diskrete komponinten makket it makliker te ûntwerpen, ûnderhâlden, en wurkje mei it as gehiel. (Tink derom dat wy seine "simplifies" net "makket ienfâldich").
It twadde prinsipe is dat wy de produktiviteit fan ûntwikkelders kinne ferheegje troch har te helpen te fokusjen op 'e funksjes dy't se ûntwikkelje, wylst se har befrije fan ynfrastruktuer en CI / CD-soarch by ymplemintaasje. Dus, yn in notedop, ús oanpak rjochte op ûntwikkelders.
Uteinlik moat alles oer jo applikaasje ferbûn wêze mei it netwurk. Yn 'e ôfrûne 20 jier hawwe wy grutte stappen makke nei in netwurkige takomst as netwurken rapper wurde en applikaasjes komplekser. Lykas wy hawwe sjoen, moat in moderne applikaasje wurde brûkt oer in netwurk troch in protte ferskillende kliïnten. It tapassen fan netwurktinken op arsjitektuer hat wichtige foardielen dy't goed mei geane lytsheid prinsipe en it konsept fan 'e oanpak, ûntwikkeler rjochte.
As jo dizze prinsipes yn gedachten hâlde by it ûntwerpen en ymplemintearjen fan in applikaasje, sille jo in ûnbestriden foardiel hawwe yn 'e ûntwikkeling en levering fan jo produkt.
Litte wy nei dizze trije prinsipes yn mear detail sjen.
Kleinheid prinsipe
It is lestich foar it minsklik brein om in grutte hoemannichte ynformaasje tagelyk te waarnimmen. Yn psychology ferwiist de term kognitive load nei it totale bedrach fan mentale ynspanning dy't nedich is om ynformaasje yn it ûnthâld te behâlden. It ferminderjen fan de kognitive lading op ûntwikkelders is in prioriteit, om't it har mooglik makket om te fokusjen op it oplossen fan it probleem ynstee fan it hjoeddeistige komplekse model fan 'e heule applikaasje en de funksjes dy't ûntwikkele wurde yn har holle te hâlden.
Applikaasjes ûntbine om de folgjende redenen:
- Reduzearre kognitive lêst op ûntwikkelders;
- Fersnelling en ferienfâldiging fan testen;
- Snelle levering fan feroaringen yn 'e applikaasje.
D'r binne ferskate manieren om de kognitive lading op ûntwikkelders te ferminderjen, en dit is wêr't it prinsipe fan lytsens yn spiel komt.
Dat hjir binne trije manieren om kognitive lading te ferminderjen:
- Ferminderje it tiidframe dat se moatte beskôgje by it ûntwikkeljen fan in nije funksje - hoe koarter it tiidframe, hoe leger de kognitive lading.
- Ferminderje it bedrach fan koade wêrop ien kear wurk wurdt útfierd - minder koade - minder lading.
- Ienfâldigje it proses fan it meitsjen fan inkrementele wizigingen yn in applikaasje.
It ferminderjen fan it ûntwikkelingstiidframe
Litte wy weromgean nei de dagen doe't de metodyk waterfall wie de standert foar it ûntwikkelingsproses, en tiidframes fan seis moanne oant twa jier foar it ûntwikkeljen of bywurkjen fan in applikaasje wiene gewoane praktyk. Typysk soene yngenieurs earst relevante dokuminten lêze lykas de produkteasken (PRD), systeemferwizingsdokumint (SRD), arsjitektuerblauprint, en begjinne al dizze dingen tegearre te kombinearjen yn ien kognityf model, neffens dêr't se kodearre. As de easken en dêrtroch de arsjitektuer feroare, moast in serieuze poging dien wurde om it hiele team te ynformearjen oer updates fan it kognitive model. Sa'n oanpak koe op syn minst it wurk gewoan ferlamme.
De grutste feroaring yn it proses foar applikaasjeûntwikkeling wie de ynfiering fan 'e agile metodyk. Ien fan 'e wichtichste skaaimerken fan' e metodyk agile is in iterative ûntwikkeling. Op syn beurt liedt dit ta in fermindering fan 'e kognitive lêst op yngenieurs. Ynstee fan it ûntwikkelteam te fereaskje de applikaasje yn ien lange syklus te ymplementearjen, agile oanpak kinne jo rjochtsje op lytse hoemannichten koade dy't kin fluch hifke en ynset, wylst ek ûntfange feedback. De kognitive lading fan 'e app is ferskood fan in tiidframe fan seis moanne nei twa jier mei in enoarme hoemannichte specs foar in twa wiken tafoeging of funksjeferoaring rjochte op in waziger begryp fan in grutte app.
De fokus ferskowe fan in massale applikaasje nei spesifike lytse funksjes dy't kinne wurde foltôge yn in sprint fan twa wiken, mei net mear as ien funksje foar de folgjende sprint yn gedachten, is in wichtige feroaring. Dit liet ús de produktiviteit fan ûntwikkeling ferheegje, wylst de kognitive lading, dy't konstant fluktueare, fermindere.
Yn metodyk agile de definitive applikaasje wurdt ferwachte te wêzen in bytsje feroare ferzje fan it orizjinele konsept, dus it einpunt fan ûntwikkeling is needsaaklikerwize dûbelsinnich. Allinich de resultaten fan elke spesifike sprint kinne dúdlik en presys wêze.
Lytse codebases
De folgjende stap yn it ferminderjen fan kognitive lading is om de koadebasis te ferminderjen. Yn 'e regel binne moderne applikaasjes massaal - in robúste bedriuwsapplikaasje kin bestean út tûzenen bestannen en hûnderttûzenen rigels koade. Ofhinklik fan hoe't de bestannen binne organisearre, kinne keppelings en ôfhinklikens tusken koade en bestannen fanselssprekkend wêze, of oarsom. Sels de útfiering fan debuggen fan koade sels kin problematysk wêze, ôfhinklik fan de brûkte biblioteken en hoe goed de debuggen-ark ûnderskiede tusken biblioteken / pakketten / modules en oanpaste koade.
It bouwen fan in wurkjend mental model fan 'e koade fan in applikaasje kin in yndrukwekkende hoemannichte tiid nimme, en nochris in grutte kognitive lêst op 'e ûntwikkelder pleatse. Dit is benammen wier foar monolithyske koadebasen, wêr't in grutte hoemannichte koade is, wêrfan de ynteraksje tusken de funksjonele komponinten net dúdlik definiearre is, en de skieding fan objekten fan oandacht wurdt faak wazig om't funksjonele grinzen net respekteare wurde.
Ien fan 'e effektive manieren om de kognitive lêst op yngenieurs te ferminderjen is te ferpleatsen nei in mikroservice-arsjitektuer. Yn in mikroservice-oanpak rjochtet elke tsjinst him op ien set funksjes; wylst de betsjutting fan 'e tsjinst is meastal definiearre en begryplik. De grinzen fan in tsjinst binne ek dúdlik - tink derom dat kommunikaasje mei in tsjinst wurdt dien fia in API, sadat gegevens generearre troch de iene tsjinst maklik nei in oare kinne wurde trochjûn.
Ynteraksje mei oare tsjinsten is normaal beheind ta in pear brûkerstsjinsten en in pear tsjinstferlieners dy't ienfâldige en skjinne API-oproppen brûke, lykas it brûken fan REST. Dit betsjut dat de kognitive lêst op 'e yngenieur serieus fermindere wurdt. De grutste útdaging bliuwt it begripen fan it tsjinstynteraksjemodel en hoe't dingen lykas transaksjes barre oer meardere tsjinsten. As gefolch, it brûken fan mikrotsjinsten ferminderet kognitive lading troch it ferminderjen fan it bedrach fan koade, it definiearjen fan dúdlike tsjinst grinzen, en it jaan fan in begryp fan de relaasje tusken brûkers en providers.
Lytse ynkrementele feroarings
It lêste elemint fan it prinsipe lytsens is feroaring behear. It is in bysûndere ferlieding foar ûntwikkelders om te sjen nei de koadebasis (sels miskien har eigen, âldere koade) en sizze: "Dit is crap, wy moatte it allegear opnij skriuwe." Soms is dit it goede beslút, en soms net. It leit de lêst fan wrâldwide modelferoaring op it ûntwikkelteam, wat op syn beurt liedt ta massive kognitive lading. It is better foar yngenieurs om te rjochtsjen op de feroarings dy't se kinne meitsje tidens de sprint, sadat se de nedige funksjonaliteit op 'e tiid, al stadichoan, útrolje kinne. It definitive produkt moat lykje op it foarôf plande, mar mei wat oanpassings en testen om te passen oan 'e behoeften fan' e klant.
By it oerskriuwen fan grutte dielen fan koade is it soms net mooglik om de feroaring fluch te leverjen, om't oare systeemôfhinklikens yn 't spul komme. Om de stream fan feroaringen te kontrolearjen, kinne jo funksje ferbergje brûke. Yn prinsipe betsjut dit dat de funksjonaliteit is yn produksje, mar it is net beskikber mei help fan de omjouwingsfariabele ynstellings (env-var) of in oar konfiguraasje meganisme. As de koade alle prosessen foar kwaliteitskontrôle hat trochjûn, kin it yn in latinte steat yn produksje einigje. Dizze strategy wurket lykwols allinich as de funksje úteinlik ynskeakele is. Oars sil it allinich de koade rommelje en in kognitive lading taheakje dy't de ûntwikkelder sil moatte omgean om produktyf te wêzen. Feroaringsbehear en ynkrementele feroaringen sels helpe de kognitive lading fan ûntwikkelders op in betelber nivo te hâlden.
Yngenieurs moatte in protte swierrichheden oerwinne, sels mei de ienfâldige ynfiering fan ekstra funksjonaliteit. Fan 'e kant fan it behear soe it foarsichtich wêze om de ûnnedige lêst op it team te ferminderjen sadat it kin rjochtsje op wichtige funksjonele eleminten. D'r binne trije dingen dy't jo kinne dwaan om jo ûntwikkelingsteam te helpen:
- Brûk metodyk
agileom it tiidframe te beheinen wêryn it team moat rjochtsje op wichtige funksjes. - Implementearje jo applikaasje as meardere mikrotsjinsten. Dit sil it oantal funksjes beheine dy't kinne wurde ymplementearre en fersterkje de grinzen dy't de kognitive lading oan it wurk hâlde.
- Foarkar inkrementele feroarings boppe grutte en ûnhandich, feroarje lytse stikjes koade. Brûk funksje ferbergjen om wizigingen út te fieren, sels as se net direkt nei it tafoegjen sichtber binne.
As jo it prinsipe fan lytsens tapasse yn jo wurk, sil jo team folle lokkiger wêze, better rjochte op it útfieren fan de nedige funksjes, en mear kâns om kwalitative feroaringen rapper út te rollen. Mar dit betsjuttet net dat it wurk net komplisearre wurde kin, soms, krekt oarsom, de ynfiering fan nije funksjonaliteit fereasket de wiziging fan ferskate tsjinsten, en dit proses kin dreger wêze as ferlykber yn in monolityske arsjitektuer. Yn alle gefallen binne de foardielen fan it nimmen fan 'e oanpak fan lytsens it wurdich.
Ein fan it earste diel.
Meikoarten sille wy it twadde diel fan 'e oersetting publisearje, en no wachtsje wy op jo opmerkingen en noegje jo út , dat hjoed om 20.00 oere plakfynt.
Boarne: www.habr.com