Hej venner. I forventning om lanceringen af kurset , traditionelt deler oversættelsen af nyttigt materiale med dig.
Software løser flere og flere hverdagsopgaver, samtidig med at den bliver mere og mere kompleks. Som Marc Andressen engang sagde, det fortærer verden.
Som følge heraf har den måde, applikationer udvikles og leveres på, ændret sig dramatisk i løbet af de sidste par år. Disse var skift af tektonisk skala, der resulterede i et sæt principper. Disse principper har vist sig at være nyttige i teambuilding, design, udvikling og levering af din applikation til slutbrugere.
Principperne kan opsummeres som følger: applikationen skal være lille, webbaseret og have en udviklercentreret arkitektur. Med disse tre principper i tankerne kan du skabe en robust, end-to-end-applikation, der hurtigt og sikkert kan leveres til slutbrugeren, og som nemt kan skaleres og udvides.
Hvert af de foreslåede principper har en række aspekter, som vi vil diskutere for at vise, hvordan hvert princip bidrager til det ultimative mål, som er hurtig levering af pålidelige applikationer, der er nemme at vedligeholde og bruge. Vi vil se på principperne i forhold til deres modsætninger for at afklare, hvad det betyder, siger: "Sørg for at bruge lillehedsprincippet'.
Vi håber, at denne artikel vil opmuntre dig til at bruge de foreslåede principper til at bygge moderne applikationer, som vil give en samlet tilgang til design i sammenhæng med en stadigt voksende teknologistak.
Ved at anvende disse principper vil du finde dig selv at drage fordel af de seneste trends inden for softwareudvikling, herunder til udvikling og levering af applikationer, brug af containere (f.eks. ) og containerorkestreringsrammer (f.eks. ), brugen af mikrotjenester (inklusive mikroservicearkitekturen и til mikroserviceapplikationer.
Hvad er en moderne applikation?
Moderne applikationer? Moderne stak? Hvad betyder "moderne" helt præcist?
De fleste udviklere har kun en generel idé om, hvad en moderne applikation består af, så det er nødvendigt at klart definere dette koncept.
En moderne app understøtter flere klienter, uanset om det er en brugergrænseflade til et React JavaScript-bibliotek, en Android- eller iOS-mobilapp eller en app, der opretter forbindelse til en anden API. En moderne applikation indebærer et ubestemt antal klienter, som den leverer data eller tjenester til.
En moderne applikation giver en API til at få adgang til de ønskede data og tjenester. API'en skal være uforanderlig og konstant og ikke skrevet specifikt til en specifik anmodning fra en specifik klient. API'en er tilgængelig over HTTP(S) og giver adgang til al den funktionalitet, der er tilgængelig i GUI eller CLI.
Dataene skal være tilgængelige i et almindeligt accepteret, interoperabelt format såsom JSON. En API eksponerer objekter og tjenester på en ren, organiseret måde, som RESTful API eller GraphQL giver en anstændig grænseflade.
Moderne applikationer er bygget på den moderne stack, og den moderne stack er den stack, der henholdsvis understøtter sådanne applikationer. Denne stak giver en udvikler mulighed for nemt at oprette en applikation med en HTTP-grænseflade og klare API-endepunkter. Den valgte tilgang giver din applikation mulighed for nemt at modtage og sende data i JSON-format. Med andre ord svarer den moderne stak til elementerne i Tolv-Factor Application for .
Populære versioner af denne type stak er baseret på , , , , и . Mikroservice arkitektur repræsenterer et eksempel på en moderne stak implementeret på hvert af de nævnte sprog.
Bemærk venligst, at vi ikke går ind for en udelukkende mikroservicetilgang. Mange af jer arbejder med monolitter, der skal udvikle sig, mens andre beskæftiger sig med SOA-applikationer, der udvider og udvikler sig til at blive mikroserviceapplikationer. Atter andre bevæger sig mod serverløse applikationer, og nogle implementerer kombinationer af ovenstående. Principperne skitseret i artiklen gælder for hvert af disse systemer med kun få mindre ændringer.
Principper
Nu hvor vi har en fælles forståelse af, hvad en moderne applikation og moderne stack er, er det tid til at dykke ned i arkitekturen og udviklingsprincipperne, der vil tjene dig godt i udvikling, implementering og vedligeholdelse af en moderne applikation.
Et af principperne lyder som "lav små ansøgninger", lad os bare kalde det lillehedsprincippet. Der er utroligt komplekse applikationer, der består af mange bevægelige dele. Til gengæld gør opbygning af en applikation fra små, diskrete komponenter det nemmere at designe, vedligeholde og arbejde med det som helhed. (Bemærk, at vi sagde "forenkler" ikke "gør enkelt").
Det andet princip er, at vi kan øge udviklerproduktiviteten ved at hjælpe dem med at fokusere på de funktioner, de udvikler, og samtidig frigøre dem fra infrastruktur og CI/CD-problemer under implementeringen. Så i en nøddeskal, vores tilgang fokuseret på udviklere.
Endelig skal alt om din applikation være tilsluttet netværket. I løbet af de sidste 20 år har vi gjort store fremskridt mod en netværksbaseret fremtid, efterhånden som netværk bliver hurtigere og applikationer mere komplekse. Som vi har set, skal en moderne applikation bruges over et netværk af mange forskellige klienter. At anvende netværkstænkning på arkitektur har betydelige fordele, som passer godt sammen lillehedsprincippet og konceptet med tilgangen, udvikler orienteret.
Hvis du holder disse principper for øje, når du designer og implementerer en applikation, vil du have en ubestridelig fordel i udviklingen og leveringen af dit produkt.
Lad os se på disse tre principper mere detaljeret.
Lillehedsprincippet
Det er svært for den menneskelige hjerne at opfatte en stor mængde information på samme tid. I psykologi refererer udtrykket kognitiv belastning til den samlede mængde mental indsats, der kræves for at bevare information i hukommelsen. At reducere den kognitive belastning på udviklere er en prioritet, fordi det giver dem mulighed for at fokusere på at løse problemet i stedet for at beholde den nuværende komplekse model af hele applikationen og de funktioner, der udvikles, i deres hoved.
Applikationer nedbrydes af følgende årsager:
- Reduceret kognitiv belastning på udviklere;
- Acceleration og forenkling af testning;
- Hurtig levering af ændringer i applikationen.
Der er flere måder at reducere den kognitive belastning på udviklere, og det er her, princippet om lillehed kommer i spil.
Så her er tre måder at reducere kognitiv belastning på:
- Reducer den tidsramme, de skal overveje, når de udvikler en ny funktion – jo kortere tidsrammen, desto lavere er den kognitive belastning.
- Reducer mængden af kode, som engangsarbejde udføres på - mindre kode - mindre belastning.
- Forenkle processen med at foretage trinvise ændringer af en applikation.
Reduktion af udviklingstidsrammen
Lad os gå tilbage til de dage, hvor metoden waterfall var standarden for udviklingsprocessen, og tidsrammer på seks måneder til to år for udvikling eller opdatering af en applikation var almindelig praksis. Typisk ville ingeniører først læse relevante dokumenter såsom produktkravene (PRD), systemreferencedokumentet (SRD), arkitekturplanen og begynde at kombinere alle disse ting sammen i én kognitiv model, som de kodede efter. Da kravene og dermed arkitekturen ændrede sig, måtte der gøres en seriøs indsats for at informere hele teamet om opdateringer til den kognitive model. Sådan en tilgang kunne i værste fald simpelthen lamme arbejdet.
Den største ændring i applikationsudviklingsprocessen var introduktionen af den agile metodologi. Et af hovedtrækkene i metoden agile er en iterativ udvikling. Til gengæld fører dette til en reduktion i den kognitive belastning på ingeniører. I stedet for at kræve, at udviklingsteamet implementerer applikationen i én lang cyklus, agile tilgang giver dig mulighed for at fokusere på små mængder kode, der hurtigt kan testes og implementeres, samtidig med at du modtager feedback. Appens kognitive belastning er skiftet fra en seks-måneders til to-årig tidsramme med en enorm mængde specifikationer for en to-ugers tilføjelse eller funktionsændring rettet mod en mere sløret forståelse af en stor app.
At flytte fokus fra en massiv applikation til specifikke små funktioner, der kan gennemføres i en to-ugers sprint, med ikke mere end én funktion forud for næste sprint i tankerne, er en væsentlig ændring. Dette gjorde det muligt for os at øge udviklingsproduktiviteten og samtidig reducere den kognitive belastning, som konstant svingede.
I metode agile den endelige applikation forventes at være en let modificeret version af det originale koncept, så slutpunktet for udviklingen er nødvendigvis tvetydigt. Kun resultaterne af hver specifik sprint kan være klare og præcise.
Små kodebaser
Det næste skridt i at reducere kognitiv belastning er at reducere kodebasen. Som regel er moderne applikationer massive - en robust virksomhedsapplikation kan bestå af tusindvis af filer og hundredtusindvis af kodelinjer. Afhængigt af hvordan filerne er organiseret, kan links og afhængigheder mellem kode og filer være indlysende, eller omvendt. Selv udførelse af fejlfindingskode kan være problematisk, afhængigt af de anvendte biblioteker og hvor godt fejlfindingsværktøjerne skelner mellem biblioteker/pakker/moduler og brugerdefineret kode.
Opbygning af en fungerende mental model af en applikations kode kan tage imponerende lang tid og igen lægge en stor kognitiv byrde på udvikleren. Dette gælder især for monolitiske kodebaser, hvor der er en stor mængde kode, hvis interaktion mellem de funktionelle komponenter ikke er klart defineret, og adskillelsen af opmærksomhedsobjekter ofte er sløret, fordi funktionelle grænser ikke respekteres.
En af de effektive måder at reducere den kognitive belastning på ingeniører er at gå over til en mikroservicearkitektur. I en mikroservicetilgang fokuserer hver service på ét sæt funktioner; mens betydningen af tjenesten normalt er defineret og forståelig. Grænserne for en service er også klare – husk at kommunikation med en service foregår via et API, så data genereret af en service nemt kan videregives til en anden.
Interaktion med andre tjenester er normalt begrænset til nogle få brugertjenester og nogle få udbydertjenester, der bruger enkle og rene API-kald, såsom brug af REST. Det betyder, at den kognitive belastning af ingeniøren reduceres alvorligt. Den største udfordring er fortsat at forstå serviceinteraktionsmodellen og hvordan ting som transaktioner sker på tværs af flere tjenester. Som et resultat heraf reducerer brugen af mikrotjenester den kognitive belastning ved at reducere mængden af kode, definere klare servicegrænser og give en forståelse af forholdet mellem brugere og udbydere.
Små trinvise ændringer
Det sidste element i princippet lillehed er forandringsledelse. Det er en særlig fristelse for udviklere at se på kodebasen (selv måske deres egen, ældre kode) og sige: "Det her er noget lort, vi er nødt til at omskrive det hele." Nogle gange er dette den rigtige beslutning, og nogle gange ikke. Det lægger byrden af global modelændring på udviklingsteamet, hvilket igen fører til massiv kognitiv belastning. Det er bedre for ingeniører at fokusere på de ændringer, de kan foretage i løbet af spurten, så de kan udrulle den nødvendige funktionalitet rettidigt, omend gradvist. Det endelige produkt skal ligne det forud planlagte, men med nogle modifikationer og test, så det passer til kundens behov.
Når du omskriver store dele af kode, er det nogle gange ikke muligt hurtigt at levere ændringen, fordi andre systemafhængigheder spiller ind. For at kontrollere strømmen af ændringer kan du bruge funktionsskjul. I princippet betyder det, at funktionaliteten er i produktion, men den er ikke tilgængelig ved brug af miljøvariableindstillingerne (env-var) eller en anden konfigurationsmekanisme. Hvis koden har bestået alle kvalitetskontrolprocesser, kan den ende i produktionen i en latent tilstand. Denne strategi virker dog kun, hvis funktionen til sidst aktiveres. Ellers vil det kun rode op i koden og tilføje en kognitiv belastning, som udvikleren bliver nødt til at håndtere for at være produktiv. Forandringsstyring og trinvise ændringer hjælper i sig selv med at holde udviklernes kognitive belastning på et overkommeligt niveau.
Ingeniører er nødt til at overvinde mange vanskeligheder selv med den simple introduktion af yderligere funktionalitet. Fra ledelsens side vil det være fornuftigt at reducere den unødvendige byrde på teamet, så det kan fokusere på centrale funktionelle elementer. Der er tre ting, du kan gøre for at hjælpe dit udviklingsteam:
- Brug metode
agileat begrænse den tidsramme, hvor teamet skal fokusere på nøglefunktioner. - Implementer din applikation som flere mikrotjenester. Dette vil begrænse antallet af funktioner, der kan implementeres, og forstærke de grænser, der holder den kognitive belastning på arbejde.
- Foretrækker trinvise ændringer frem for store og uhåndterlige, skift små stykker kode. Brug funktionsskjul til at implementere ændringer, selvom de ikke vil være synlige umiddelbart efter tilføjelse af dem.
Hvis du anvender princippet om lillehed i dit arbejde, vil dit team blive meget gladere, mere fokuseret på at implementere de nødvendige funktioner og mere tilbøjelige til at udrulle kvalitative ændringer hurtigere. Men det betyder ikke, at arbejdet ikke kan blive mere kompliceret, nogle gange, tværtimod, kræver introduktionen af ny funktionalitet modifikation af flere tjenester, og denne proces kan være sværere end tilsvarende i en monolitisk arkitektur. Under alle omstændigheder er fordelene ved at tage smallness-tilgangen det værd.
Slut på første del.
Snart vil vi udgive anden del af oversættelsen, og nu venter vi på dine kommentarer og inviterer dig til , som finder sted i dag klokken 20.00.
Kilde: www.habr.com