Hej kompisar. I väntan på lanseringen av kursen , traditionellt dela med dig översättningen av användbart material.
Programvara löser allt fler vardagliga uppgifter, samtidigt som den blir mer och mer komplex. Som Marc Andressen sa en gång, det förtär världen.
Som ett resultat har hur applikationer utvecklas och levereras förändrats dramatiskt under de senaste åren. Dessa var förändringar av tektonisk skala som resulterade i en uppsättning principer. Dessa principer har visat sig vara till hjälp för att bygga team, designa, utveckla och leverera din applikation till slutanvändare.
Principerna kan sammanfattas enligt följande: applikationen ska vara liten, webbaserad och ha en utvecklarcentrerad arkitektur. Med dessa tre principer i åtanke kan du skapa en robust, heltäckande applikation som snabbt och säkert kan levereras till slutanvändaren, och som är lätt skalbar och utbyggbar.
Var och en av de föreslagna principerna har ett antal aspekter som vi kommer att diskutera för att visa hur varje princip bidrar till det slutliga målet, som är snabb leverans av pålitliga applikationer som är enkla att underhålla och använda. Vi kommer att titta på principerna i förhållande till deras motsatser för att klargöra vad det betyder, säg, "Se till att du använder litenhetsprincipen".
Vi hoppas att den här artikeln kommer att uppmuntra dig att använda de föreslagna principerna för att bygga moderna applikationer, vilket kommer att ge ett enhetligt tillvägagångssätt för design i samband med en ständigt växande teknikstack.
Genom att tillämpa dessa principer kommer du att dra nytta av de senaste trenderna inom mjukvaruutveckling, inklusive till utveckling och leverans av applikationer, användning av behållare (t.ex. ) och containerorkestreringsramar (till exempel, ), användningen av mikrotjänster (inklusive Microservice Architecture и för mikrotjänstapplikationer.
Vad är en modern applikation?
Moderna applikationer? Modern stack? Vad betyder egentligen "modernt"?
De flesta utvecklare har bara en allmän uppfattning om vad en modern applikation består av, så det är nödvändigt att tydligt definiera detta koncept.
En modern app stöder flera klienter, oavsett om det är ett användargränssnitt för React JavaScript-bibliotek, en Android- eller iOS-mobilapp eller en app som ansluter till ett annat API. En modern applikation innebär ett obegränsat antal klienter som den tillhandahåller data eller tjänster för.
En modern applikation tillhandahåller ett API för att komma åt de begärda data och tjänster. API:t ska vara oföränderligt och konstant och inte skrivet specifikt för en specifik begäran från en specifik klient. API:et är tillgängligt över HTTP(S) och ger tillgång till all funktionalitet som finns i GUI eller CLI.
Uppgifterna måste vara tillgängliga i ett allmänt accepterat, interoperabelt format som JSON. Ett API exponerar objekt och tjänster på ett rent, organiserat sätt, som RESTful API eller GraphQL ger ett anständigt gränssnitt.
Moderna applikationer är byggda på den moderna stacken, och den moderna stacken är stacken som stöder sådana applikationer. Denna stack låter en utvecklare enkelt skapa en applikation med ett HTTP-gränssnitt och tydliga API-slutpunkter. Det valda tillvägagångssättet gör att din applikation enkelt kan ta emot och skicka data i JSON-format. Med andra ord motsvarar den moderna stacken elementen i Tolvfaktorapplikationen för .
Populära versioner av denna typ av stack är baserade på , , , , и . Mikroservicearkitektur 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 en exklusivt mikroservicestrategi. Många av er arbetar med monoliter som behöver utvecklas, medan andra har att göra med SOA-applikationer som expanderar och utvecklas till att bli mikrotjänstapplikationer. Ytterligare andra går mot serverlösa applikationer, och vissa implementerar kombinationer av ovanstående. Principerna som beskrivs i artikeln gäller för vart och ett av dessa system med endast ett fåtal mindre ändringar.
Principer
Nu när vi har en gemensam förståelse för vad en modern applikation och modern stack är, är det dags att dyka in i arkitekturen och utvecklingsprinciperna som kommer att tjäna dig väl i att utveckla, implementera och underhålla en modern applikation.
En av principerna låter som "gör små ansökningar", låt oss bara kalla det litenhetsprincipen. Det finns otroligt komplexa applikationer som består av många rörliga delar. Att bygga en applikation från små, diskreta komponenter gör det i sin tur lättare att designa, underhålla och arbeta med den som helhet. (Observera att vi sa "förenklar" inte "gör enkelt").
Den andra principen är att vi kan öka utvecklarnas produktivitet genom att hjälpa dem att fokusera på funktionerna de utvecklar, samtidigt som de befrias från infrastruktur och CI/CD-problem under implementeringen. Så, i ett nötskal, vårt tillvägagångssätt fokuserat på utvecklare.
Slutligen måste allt om din applikation vara anslutet till nätverket. Under de senaste 20 åren har vi tagit stora framsteg mot en nätverksbaserad framtid eftersom nätverk blir snabbare och applikationer mer komplexa. Som vi redan har sett måste en modern applikation användas över ett nätverk av många olika klienter. Att tillämpa nätverkstänkande på arkitektur har betydande fördelar som passar bra med litenhetsprincipen och konceptet för tillvägagångssättet, utvecklarorienterad.
Om du har dessa principer i åtanke när du designar och implementerar en applikation kommer du att ha en obestridlig fördel i utvecklingen och leveransen av din produkt.
Låt oss titta på dessa tre principer mer i detalj.
Litenhetsprincipen
Det är svårt för den mänskliga hjärnan att uppfatta en stor mängd information samtidigt. Inom psykologi hänvisar termen kognitiv belastning till den totala mängden mental ansträngning som krävs för att behålla information i minnet. Att minska den kognitiva belastningen på utvecklare är en prioritet eftersom det gör att de kan fokusera på att lösa problemet istället för att behålla den nuvarande komplexa modellen av hela applikationen och funktionerna som utvecklas i huvudet.
Applikationer sönderfaller av följande skäl:
- Minskad kognitiv belastning på utvecklare;
- Acceleration och förenkling av testning;
- Snabb leverans av ändringar i applikationen.
Det finns flera sätt att minska den kognitiva belastningen på utvecklare, och det är här principen om litenhet kommer in i bilden.
Så här är tre sätt att minska kognitiv belastning:
- Minska tidsramen de måste tänka på när de utvecklar en ny funktion – ju kortare tidsram, desto lägre kognitiv belastning.
- Minska mängden kod som engångsarbete utförs på - mindre kod - mindre belastning.
- Förenkla processen att göra stegvisa ändringar i en applikation.
Att minska utvecklingstiden
Låt oss gå tillbaka till de dagar då metodiken waterfall var standarden för utvecklingsprocessen, och tidsramar på sex månader till två år för att utveckla eller uppdatera en applikation var vanlig praxis. Vanligtvis skulle ingenjörer först läsa relevanta dokument som produktkrav (PRD), systemreferensdokument (SRD), arkitekturritning och börja kombinera alla dessa saker till en kognitiv modell, enligt vilken de kodade. Eftersom kraven och, följaktligen, arkitekturen förändrades, måste en seriös ansträngning göras för att informera hela teamet om uppdateringar av den kognitiva modellen. Ett sådant tillvägagångssätt skulle i värsta fall helt enkelt kunna förlama arbetet.
Den största förändringen i applikationsutvecklingsprocessen var införandet av den agila metodiken. En av huvuddragen i metodiken agile är en iterativ utveckling. Detta leder i sin tur till en minskning av den kognitiva belastningen på ingenjörer. Istället för att kräva att utvecklingsteamet ska implementera applikationen i en lång cykel, agile tillvägagångssätt låter dig fokusera på små mängder kod som snabbt kan testas och distribueras, samtidigt som du får feedback. Appens kognitiva belastning har skiftat från en tidsram på sex månader till två år med en enorm mängd specifikationer för en två veckor lång tillägg eller funktionsändring som riktar in sig på en mer suddig förståelse av en stor app.
Att flytta fokus från en massiv applikation till specifika små funktioner som kan slutföras i en tvåveckorssprint, med inte mer än en funktion före nästa sprint i åtanke, är en betydande förändring. Detta gjorde att vi kunde öka utvecklingsproduktiviteten samtidigt som vi minskade den kognitiva belastningen, som ständigt fluktuerade.
I metodik agile den slutliga applikationen förväntas vara en något modifierad version av det ursprungliga konceptet, så slutpunkten för utvecklingen är nödvändigtvis tvetydig. Endast resultaten av varje specifik sprint kan vara tydliga och exakta.
Små kodbaser
Nästa steg för att minska kognitiv belastning är att minska kodbasen. Som regel är moderna applikationer enorma - en robust företagsapplikation kan bestå av tusentals filer och hundratusentals rader kod. Beroende på hur filerna är organiserade kan länkar och beroenden mellan kod och filer vara uppenbara, eller vice versa. Även själva körningen av felsökningskod kan vara problematisk, beroende på vilka bibliotek som används och hur väl felsökningsverktygen skiljer mellan bibliotek/paket/moduler och anpassad kod.
Att bygga en fungerande mental modell av en applikations kod kan ta imponerande lång tid och återigen lägga en stor kognitiv börda på utvecklaren. Detta gäller särskilt för monolitiska kodbaser, där det finns en stor mängd kod, vars interaktion mellan de funktionella komponenterna inte är tydligt definierade och separationen av uppmärksamhetsobjekt ofta är suddig eftersom funktionella gränser inte respekteras.
Ett av de effektiva sätten att minska den kognitiva belastningen på ingenjörer är att gå över till en mikrotjänstarkitektur. I ett mikrotjänstesätt fokuserar varje tjänst på en uppsättning funktioner; medan innebörden av tjänsten vanligtvis är definierad och begriplig. Gränserna för en tjänst är också tydliga – kom ihåg att kommunikation med en tjänst sker via ett API, så data som genereras av en tjänst kan enkelt skickas till en annan.
Interaktion med andra tjänster är vanligtvis begränsad till ett fåtal användartjänster och ett fåtal leverantörstjänster som använder enkla och rena API-anrop, som att använda REST. Detta innebär att den kognitiva belastningen på ingenjören minskar rejält. Den största utmaningen är fortfarande att förstå tjänsteinteraktionsmodellen och hur saker som transaktioner sker över flera tjänster. Som ett resultat minskar användningen av mikrotjänster den kognitiva belastningen genom att minska mängden kod, definiera tydliga tjänstegränser och ge en förståelse för relationen mellan användare och leverantörer.
Små inkrementella förändringar
Den sista delen av principen litenhet är förändringsledning. Det är en speciell frestelse för utvecklare att titta på kodbasen (även kanske deras egen, äldre kod) och säga, "Det här är skit, vi måste skriva om allt." Ibland är detta rätt beslut, och ibland inte. Det lägger bördan av global modellförändring på utvecklingsteamet, vilket i sin tur leder till enorm kognitiv belastning. Det är bättre för ingenjörer att fokusera på de förändringar de kan göra under sprinten, så att de kan rulla ut nödvändig funktionalitet i tid, om än gradvis. Slutprodukten ska likna den förplanerade, men med vissa modifieringar och testning för att passa kundens behov.
Vid omskrivning av stora delar av koden är det ibland inte möjligt att snabbt leverera ändringen eftersom andra systemberoenden spelar in. För att kontrollera flödet av ändringar kan du använda funktionsdöljning. I princip betyder detta att funktionaliteten är i produktion, men den är inte tillgänglig med hjälp av miljövariabelinställningarna (env-var) eller någon annan konfigurationsmekanism. Om koden har klarat alla kvalitetskontrollprocesser kan den hamna i produktion i ett latent tillstånd. Den här strategin fungerar dock bara om funktionen så småningom aktiveras. Annars kommer det bara att belamra koden och lägga till en kognitiv belastning som utvecklaren måste hantera för att vara produktiv. Förändringshantering och inkrementella förändringar hjälper i sig att hålla utvecklarnas kognitiva belastning på en överkomlig nivå.
Ingenjörer måste övervinna många svårigheter även med det enkla införandet av ytterligare funktionalitet. Från ledningens sida skulle det vara klokt att minska den onödiga bördan på teamet så att det kan fokusera på viktiga funktionella element. Det finns tre saker du kan göra för att hjälpa ditt utvecklingsteam:
- Använd metodik
agileatt begränsa tidsramen inom vilken teamet måste fokusera på nyckelfunktioner. - Implementera din applikation som flera mikrotjänster. Detta kommer att begränsa antalet funktioner som kan implementeras och förstärka gränserna som håller den kognitiva belastningen på jobbet.
- Föredrar inkrementella ändringar framför stora och svårhanterliga, ändra små bitar av kod. Använd funktionsdöljning för att implementera ändringar även om de inte kommer att synas direkt efter att du har lagt till dem.
Om du tillämpar principen om litenhet i ditt arbete kommer ditt team att bli mycket gladare, bättre fokuserat på att implementera de nödvändiga funktionerna och mer sannolikt att rulla ut kvalitativa förändringar snabbare. Men detta betyder inte att arbetet inte kan bli mer komplicerat, ibland, tvärtom, kräver införandet av ny funktionalitet modifiering av flera tjänster, och denna process kan vara svårare än liknande i en monolitisk arkitektur. I vilket fall som helst är fördelarna med att ta tillvägagångssättet med litenhet värt det.
Slutet på första delen.
Snart kommer vi att publicera den andra delen av översättningen, och nu väntar vi på dina kommentarer och bjuder in dig till , som äger rum idag kl 20.00.
Källa: will.com