Hej, vÀnner. I införandet av kursen , delar vi traditionellt med oss av en översÀttning av nytt material.
Programvaran löser allt fler vardagliga uppgifter, samtidigt som den blir mer och mer komplex. Som Mark Andreessen en gÄng sa, den konsumerar vÀrlden.
Som ett resultat har angreppssÀtten för utveckling och leverans av applikationer förÀndrats avsevÀrt under de senaste Ären. Det har skett tektoniska skift som har lett till en uppsÀttning principer. Dessa principer har visat sig vara anvÀndbara för att forma team, designa, utveckla och leverera din applikation till slutanvÀndarna.
Principerna kan sammanfattas pÄ följande sÀtt: applikationen ska vara liten, nÀtverksbaserad och ha en utvecklarfokuserad arkitektur.Genom att basera er pÄ dessa tre principer kan ni skapa en pÄlitlig, omfattande applikation som snabbt och sÀkert kan levereras till slutanvÀndaren, samt enkelt skalas och utvidgas.
Varje föreslagen princip har ett antal aspekter som vi kommer att diskutera för att visa hur varje princip bidrar till det slutgiltiga mÄlet, vilket Àr snabb leverans av pÄlitliga applikationer som Àr enkla att underhÄlla och anvÀnda. Vi kommer att betrakta principerna i jÀmförelse med sina motsatser, för att klargöra vad som menas med, till exempel, "Se till att du anvÀnder principen om litenhet.».
Vi hoppas att denna artikel inspirerar er att tillÀmpa de föreslagna principerna för att bygga moderna applikationer som sÀkerstÀller en enhetlig designansats i sammanhanget av en stÀndigt vÀxande teknikstack.
Genom att tillÀmpa dessa principer kommer ni att upptÀcka att ni följer de senaste trenderna inom programvaruutveckling, inklusive angreppssÀttet för utveckling och leverans av applikationer, anvÀndning av containrar (t.ex. ), och ramverk för orkestrering av containrar (t.ex. ), anvÀndning av mikrotjÀnster (inklusive MikrotjÀnstarkitektur och för mikrotjÀnstapplikationer.
Vad Àr en modern applikation?
Moderna applikationer? Modern teknikstack? Vad innebÀr egentligen "modern"?
De flesta utvecklare har bara en allmÀn uppfattning om vad som utgör en modern applikation, sÄ det Àr viktigt att ge en tydlig definition av detta begrepp.
En modern applikation stöder flera klienter, oavsett om det Àr ett anvÀndargrÀnssnitt med JavaScript-biblioteket React, en mobilapplikation för Android eller iOS, eller en applikation som ansluter till en annan via API. En modern applikation innebÀr att det finns ett obestÀmt antal klienter som den tillhandahÄller data eller tjÀnster för.
En modern applikation tillhandahÄller ett API för att fÄ Ätkomst till de begÀrda uppgifterna och tjÀnsterna. API:t bör vara oförÀndrat och konstant, snarare Àn skrivet specifikt för en viss förfrÄgan frÄn en specifik klient. API:t Àr tillgÀngligt via HTTP(S) och ger Ätkomst till all funktionalitet som finns i GUI eller CLI.
Data bör vara tillgÀngliga i ett allmÀnt accepterat, kompatibelt format, som JSON. API:t erbjuder objekt och tjÀnster i ett förstÄeligt, organiserat format, till exempel RESTful API eller GraphQL som ger ett anstÀndigt grÀnssnitt.
Moderna applikationer byggs pÄ en modern stack, och en modern stack Àr den som stöder sÄdana applikationer. Denna stack gör det möjligt för utvecklaren att enkelt skapa en applikation med HTTP-grÀnssnitt och tydliga API-slutpunkter. Den valda tillvÀgagÄngssÀtt gör att din applikation enkelt kan ta emot och skicka data i JSON-format. Med andra ord motsvarar den moderna stacken elementen i Twelve-Factor-applikationen för .
PopulÀra versioner av denna typ av stack baseras pÄ , , , , och . MikrotjÀnstarkitektur representerar ett exempel pÄ en modern stack, implementerad pÄ vart och ett av de nÀmnda sprÄken.
Observera att vi inte föresprÄkar enbart en mikrotjÀnstansats. MÄnga av er arbetar med monoliter som mÄste utvecklas, medan andra hanterar SOA-applikationer som utvidgas och utvecklas till att bli mikrotjÀnstapplikationer. Tredje gruppen rör sig mot att tillÀmpa serverlösa applikationer, medan vissa implementerar kombinationer av ovanstÄende. Principerna som beskrivs i artikeln Àr tillÀmpliga pÄ var och en av dessa system med vissa mindre justeringar.
Principerna
Nu nÀr vi har uppnÄtt en gemensam förstÄelse för vad moderna applikationer och moderna stackar Àr, Àr det dags att dyka ner i de arkitektur- och utvecklingsprinciper som kommer att vara till stor nytta för er i utvecklingen, implementeringen och underhÄllet av moderna applikationer.
En av principerna lÄter som "skapa smÄ applikationer", lÄt oss kalla den principen om litenhet. Det finns enormt komplexa applikationer som bestÄr av mÄnga rörliga komponenter. Att bygga en applikation av smÄ diskreta komponenter förenklar dess design, underhÄll och arbete överlag. (Notera att vi sa "förenklar" och inte "gör enkelt").
Den andra principen Àr att vi kan öka utvecklarnas produktivitet genom att hjÀlpa dem att koncentrera sig pÄ de funktioner de utvecklar, samtidigt som vi frigör dem frÄn oro över infrastruktur och CI/CD under implementeringen. SÄ, sammanfattningsvis, vÄr metod Àr utvecklarorienterad.
Slutligen, allt som rör din applikation bör vara kopplat till nÀtverket. Under de senaste 20 Ären har vi gjort stora framsteg mot en nÀtverksframtid eftersom nÀtverken har blivit snabbare och applikationerna mer komplexa. Som vi redan har konstaterat, bör moderna applikationer anvÀndas över nÀtverket av mÄnga olika klienter. Att tillÀmpa ett nÀtverksinriktat tÀnkande i arkitekturen har betydande fördelar som passar bra med principen om litenhet och konceptet av utvecklarorienterad.
Om du hÄller dessa principer i minnet vid utveckling och implementering av en applikation, kommer du att ha en oemotstÄndlig fördel i utvecklingen och leveransen av din produkt.
LÄt oss titta pÄ dessa tre principer mer i detalj.
Principen om litenhet
Det mÀnskliga sinnet har svÄrt att ta in stora mÀngder information samtidigt. Inom psykologi hÀnvisar termen kognitiv belastning till den totala mÀngden mentala insatser som krÀvs för att hÄlla information i minnet. Att minska den kognitiva belastningen hos utvecklare Àr en prioritet eftersom de dÄ kan fokusera pÄ att lösa problem istÀllet för att hÄlla en komplex modell av hela applikationen och de funktioner som utvecklas i huvudet.
Applikationer dekomponeras av följande skÀl:
- Minska den kognitiva belastningen pÄ utvecklarna;
- Snabbare och enklare testning;
- Snabb leverans av Àndringar i applikationen.
Det finns flera sÀtt att minska den kognitiva belastningen pÄ utvecklarna, och hÀr kommer principen om smÄskalighet in i bilden.
SÄ, tre sÀtt att minska den kognitiva belastningen:
- Minska tidsramarna som de mĂ„ste ta hĂ€nsyn till vid utvecklingen av en ny funktion â ju kortare tidsram, desto lĂ€gre kognitiv belastning.
- Minska mĂ€ngden kod som hanteras samtidigt â mindre kod = mindre belastning.
- Förenkla processen att göra inkrementella Àndringar i applikationen.
Minskning av utvecklingens tidsramar
LÄt oss ÄtervÀnda till en tid nÀr metodologin waterfall var standard i utvecklingsprocessen, och tidsramar pÄ mellan sex mÄnader och tvÄ Är för att utveckla eller uppdatera en applikation var vanligt. Generellt sett lÀste ingenjörerna först de relevanta dokumenten, sÄsom produktkrav (PRD), systemreferensdokument (SRD), arkitekturplanen och började sammanfoga alla dessa saker i en kognitiv modell som de skrev kod efter. Allteftersom kraven och dÀrmed arkitekturen förÀndrades, krÀvdes stora insatser för att informera hela teamet om uppdateringarna av den kognitiva modellen. Ett sÄdant tillvÀgagÄngssÀtt kunde i vÀrsta fall helt paralysera arbetet.
Den största förÀndringen i utvecklingsprocessen för applikationer var införandet av agile-metodologin. En av de frÀmsta egenskaperna hos agile -metodologin Àr iterativ utveckling. Detta i sin tur leder till att den kognitiva belastningen pÄ ingenjörerna minskar. IstÀllet för att krÀva att utvecklarteamet genomför applikationen under en lÄng cykel, agile möjliggör tillvÀgagÄngssÀttet att fokusera pÄ smÄ kodmÀngder som snabbt kan testas och implementeras, samtidigt som man fÄr feedback. Den kognitiva belastningen för applikationen har flyttats frÄn tidsramar pÄ sex mÄnader till tvÄ Är i samband med ett stort antal specifikationer till en tvÄveckors tillsats eller Àndring av funktioner, med fokus pÄ en mer diffus förstÄelse för en stor applikation.
Fokusförflyttning frÄn en massiv applikation till specifika smÄ funktioner som kan slutföras under en tvÄveckors sprint, med endast en funktion frÄn nÀsta sprint i Ätanke, Àr en betydande förÀndring. Detta har möjliggjort ökad utvecklingsproduktivitet samtidigt som den kognitiva belastningen har minskat, som stÀndigt har varierat.
I metodologin agile antagas den slutliga applikationen vara en nÄgot modifierad version av det ursprungliga konceptet, sÄ den slutgiltiga utvecklingspunkten Àr nödvÀndigtvis oklar. Endast resultaten frÄn varje specifik sprint kan vara tydliga och klara.
SmÄ kodbaser
NÀsta steg i att minska den kognitiva belastningen Àr att minska kodbasen. Vanligtvis Àr moderna applikationer massiva - en pÄlitlig företagsapplikation kan bestÄ av tusentals filer och hundratusentals rader kod. Beroende pÄ hur filerna Àr organiserade kan relationerna och beroenden mellan kod och filer vara uppenbara eller tvÀrtom. Till och med felsökning av sjÀlva kodens körning kan skapa problem beroende pÄ de anvÀnda biblioteken och hur vÀl felsökningsverktygen avgrÀnsar bibliotek/paket/moduler och anvÀndarkod.
Att bygga en mental arbetsmodell av applikationens kod kan ta en avsevÀrd mÀngd tid och Äterigen belasta utvecklaren med stor kognitiv belastning. Detta Àr sÀrskilt typiskt för monolitiska kodbaser dÀr det finns mycket kod vars interaktion mellan funktionella komponenter inte Àr tydligt definierad, och grÀnserna för uppmÀrksamhetsobjekten ofta Àr diffusa, dÄ de funktionella grÀnserna inte respekteras.
Ett effektivt sÀtt att minska den kognitiva belastningen pÄ ingenjörerna Àr att övergÄ till en mikrotjÀnstarkitektur. I mikrotjÀnstmetoden fokuserar varje tjÀnst pÄ ett specifikt funktionsset; innebörden av tjÀnsten Àr vanligtvis definierad och tydlig. GrÀnserna för tjÀnsten Àr ocksÄ klara - kom ihÄg att kommunikationen med tjÀnsten sker via API, sÄ data som genereras av en tjÀnst kan enkelt överföras till en annan.
Interaktionen med andra tjÀnster Àr vanligtvis begrÀnsade till nÄgra anvÀndartjÀnster och nÄgra av leverantörens tjÀnster som anvÀnder enkla och rena API-anrop, till exempel via REST. Detta minskar den kognitiva belastningen pÄ ingenjören avsevÀrt. Den mest utmanande uppgiften kvarstÄr att förstÄ modellen för interaktion mellan tjÀnster och hur saker som transaktioner sker över flera tjÀnster. Sammanfattningsvis minskar anvÀndningen av mikrotjÀnster den kognitiva belastningen genom att minska mÀngden kod, ange tydliga grÀnser för tjÀnster samt sÀkerstÀlla en förstÄelse för relationerna mellan anvÀndare och leverantörer.
SmÄ inkrementella förÀndringar
Det sista elementet av principen smĂ„ detaljer â Ă€r förĂ€ndringshantering. En sĂ€rskild frestelse för utvecklare Ă€r att titta pĂ„ kodbasen (Ă€ven kanske sin egen Ă€ldre kod) och sĂ€ga: "Det hĂ€r Ă€r skrĂ€p, vi mĂ„ste skriva om allt det hĂ€r." Ibland Ă€r det rĂ€tt beslut, och ibland Ă€r det inte det. Det lĂ€gger en tyngd pĂ„ utvecklarteamet som behöver göra en global förĂ€ndring av modellen, vilket i sin tur leder till en stor kognitiv belastning. Det Ă€r bĂ€ttre att ingenjörer fokuserar pĂ„ de förĂ€ndringar de kan göra under sprinten, sĂ„ att de kan lansera nödvĂ€ndig funktionalitet i tid, om Ă€n gradvis. Den slutliga produkten ska likna det som först planerades, men med vissa förĂ€ndringar och tester för att möta kundens behov.
NÀr stora delar av koden skrivs om kan det ibland vara omöjligt att snabbt leverera förÀndringar, eftersom andra systemberoenden kommer in i bilden. För att kontrollera förÀndringsflödet kan man anvÀnda funktionell dölja (feature hiding). I princip innebÀr detta att funktionen finns i produktionen, men den Àr otillgÀnglig genom miljövariabler (env-var) eller nÄgot annat konfigurationssystem. Om koden har genomgÄtt alla kvalitetskontroller kan den finnas i produktionen i ett dolt tillstÄnd. Denna strategi fungerar dock endast om funktionen sÄ smÄningom kommer att aktiveras. Annars kommer den bara att överbelasta koden och öka den kognitiva belastningen som utvecklaren mÄste hantera för att kunna arbeta produktivt. Hantering av förÀndringar och inkrementella förÀndringar hjÀlper sjÀlva till att hÄlla utvecklarnas kognitiva belastning pÄ en hanterbar nivÄ.
Ingenjörer mÄste övervinna mÄnga svÄrigheter Àven vid enkel implementering av ytterligare funktionalitet. Ur ledningens perspektiv Àr det klokt att minska den onödiga belastningen pÄ teamet sÄ att de kan fokusera pÄ de viktigaste funktionerna. Det finns tre saker du kan göra för att hjÀlpa ditt utvecklarteam:
- AnvÀnda en metodologi
agile, för att begrÀnsa tidsramarna inom vilka teamet ska fokusera pÄ nyckelfunktionerna. - Genomföra din applikation som flera mikrotjÀnster. Detta begrÀnsar antalet som implementeras funktioner och förstÀrker grÀnserna som hÄller den kognitiva belastningen under arbetet.
- Föredra inkrementella förÀndringar framför stora och skrymmande, förÀndra smÄ kodbitar. AnvÀnd funktionell dölja för att genomföra förÀndringar Àven om de inte kommer att synas direkt efter att de har lagts till.
Om du tillÀmpar principen om smÄthingar i ditt arbete, kommer ditt team att bli mycket lyckligare, bÀttre fokusera pÄ att genomföra nödvÀndiga funktioner och med större sannolikhet snabbt kunna lansera kvalitativa förÀndringar. Men det betyder inte att arbetet inte kan bli mer komplicerat; ibland kan det tvÀrtom, implementering av nya funktioner krÀva modifiering av flera tjÀnster och denna process kan vara mer komplicerad Àn motsvarande i en monolitisk arkitektur. I vilket fall som helst, fördelarna med att tillÀmpa smÄthingar Àr vÀrda det.
Slutet av första delen.
Snart publicerar vi den andra delen av översÀttningen, men just nu vÀntar vi pÄ era kommentarer och bjuder in er till , som Àger rum idag klockan 20.00.
KĂ€lla: habr.com
