Frontendarkitektur i skala for store organisationer

(Daniel Ostapenko) ( 14. okt 2020)

Hej! Jeg vil diskutere med dig, hvordan du styrer Frontend-arkitektur i store organisationer. Det føles for mig, at der ikke er mange artikler om dette emne, og det forklares ikke godt.

Ved stor organisation i denne artikel mener jeg virksomheder, hvor antallet af front-end ingeniører begynder at være større end 15, og virksomheden har mindst flere frontend-projekter.

Jeg vil ikke diskutere ledelsesproblemer eller forretningsdomænespørgsmål, dem der ofte ses i så store virksomheder, men lad os fokusere kun på Frontend-arkitektur i stedet.

Frontend-arkitektur er involveret i for mange områder i dag, så til at begynde med vil jeg foreslå at opdele den i følgende sektioner:

Frontend Architecture scheme

1. Visuel kode

Lad os starte fra det nemmeste emne, efter min mening er det den visuelle kode for vores applikationer.

Mest sandsynligt fordi vi udvikler flere frontend-applikationer hos det samme firma, vi vil have dem at have:

  • brandgenkendelse
  • den samme brugergrænseflade / UX

For at opnå det skal vi have et designsystem. Designteamet skal komme med designsystemet og følge disse designretningslinjer i alle fremtidige produktdesign. Selv dette er allerede en meget kompleks opgave og har brug for en masse diskussioner og justeringer mellem designteamet, ingeniører og produkt.

Fra front-end synspunktet er vi nødt til at give et værktøj til at implementere og til del dette designsystem på tværs af ingeniører. En god løsning til det kan være oprettelsen af ​​npm-pakken, som vil blive repræsenteret visuelt af en Storybook eller et lignende værktøj. Efter min mening er det meget vigtigt at have en dedikeret webressource (med URL) med dokumentation om, hvordan man bruger denne pakke. Denne webressource vil blive brugt af frontingeniører og designere og kan være et godt referencepunkt i samtaler mellem dem.

Visuel kode

Resumé:

På dette tidspunkt har vi et designsystem og dets repræsentation i en pakke og interaktiv dokumentation for den. Vi deler og vedtager denne pakke på tværs af alle vores front-end applikationer.

2. Kodestruktur

Lad os tale en lidt om ingeniørarbejde dagligt. Vi implementerer nye funktioner, retter bugs, refactoring kode, hvis det er nødvendigt. Vi holder af vores codebase og prøver at gøre det pænt og let forståeligt. Men hvad sker der, når vi ikke begynder at have 1, ikke 2, men snesevis af små eller store projekter i virksomheden? Normalt er folk grupperet omkring nogle af projekterne og begynder kun at arbejde med denne gruppe projekter. Af vores menneskelige natur og den begrænsede tid kan vi normalt ikke tage os af mere end 2-3-3 projekter på én gang. Så naturligvis begynder vi at have dem grupper af påvirkninger. Btw, tak til NASA for sådan et fantastisk billede til min analogi 😃

Grupper af påvirkninger

Men vi begynder at have flere og flere tilfælde, når folk har kryds -teams samarbejder, har brug for at kontrollere hinandens kode og løsninger, rette nogle bugs selv i andre applikationer eller tilføje noget, de har brug for i en eller anden ekstern app (ekstern for deres gruppe af indflydelse). Den dårlige nyhed – at denne proces sker i store virksomheder næsten ukontrolleret. Den gode nyhed – vi kan hjælpe med at forbedre den.

Hvordan? Korrekt. Ved at give den samme kodestruktur , retningslinjer for kodning og strukturering for alle projekterne i virksomheden.

Lad os grave dybere ned i, hvad vi mener med kodestruktur:

  • Mappestrukturen i projektet
    Når ingeniører hopper ind i et nyt projekt første gang – med samme mappestruktur som i deres projekt, hvor de ved, at alt hjælper meget med at navigere og søge.
  • Konfigurations- eller understøttende filer
    Filer som package.json, .gitignore, .editorconfig, webpack.config osv. De skal altid være på samme sted i hvert projekt. Det samme er forbundet til testkonfigurationsfiler eller CI-filer, hvis det er nødvendigt.
  • Fast placering af filtyperne
    Hvis placeringen af ​​de samme filtyper følger altid den samme struktur fungerer det også godt. For eksempel, hvis komponentmappen altid har en style.css -fil:
/Component
--/Component.tsx
--/style.css
--/index.ts
  • Komponenternes interne struktur
    Strukturen i filerne skal være den samme: importrækkefølge, eksport, offentlig funktion , typer osv. I hver filtype skal du vide, hvad du kan forvente.
  • Navngivningskonventioner
    Dette inkluderer navne på mapper, filer, variabler, funktioner, klasser, typer osv.
  • Kodningskonventioner
    Generelt vil jeg sige, at kodningskonventioner er et meget bredt afsnit, men her vil jeg bare medtage ting, der ikke passede ind i resten af ​​sektionerne, såsom ; eller not ; 😁 og lignende .

Den samme kodestruktur og projektværktøjssættet er i praksis meget tæt sammen er og hjælpe hinanden med at eksistere. Med værktøjssæt mener jeg CLI-værktøjer (projekt bootstrapping, linting, test osv.), IDE-udvidelser osv. Vi diskuterer emnet for værktøjssættet i de næste sektioner.

Kodestruktur

Oversigt:

Efter at have anvendt dette afsnit og vedtaget det, skal vi have alle projekter på tværs af organisationen med samme mappestruktur, navngivningsretningslinjer, filstruktur osv. Hver udvikler ideelt set kan hoppe ind i ethvert andet projekt og ikke gå helt tabt der. Denne “helt tabte” er også meget forbundet med den teknologiestak, der bruges inde i projektet, så lad os tale om det.

3. Tech Stack

Svarende til det foregående sektion, vi ønsker at have en samlet teknisk stak på tværs af organisationens projekter. Begrundelsen for dette er meget ens – vi ønsker, at vores ingeniører skal have det godt med alle projekterne på tværs af virksomheden.

I Frontend-projekter kan komponenterne i tech stack være: framework, baseret på projektet er bygget, hovedsproget, styles processor, datalag (f.eks. Apollo), tilstandsstyring, tests, kodeforing, build-system og andre.

Selvfølgelig er der undtagelser i alle regler. Og i dette emne vil jeg også lave en bemærkning om, at nogle gange nogle teknologier yderst passer til nogle specifikke projekter, selvom disse teknologier ikke er en del af den globale virksomhedsdækkende teknologistak. Men stadig hver gang denne idé kommer til at bevæge sig væk fra com pany tech stack skal du tænke to gange, fordi omkostningerne ved at støtte sådanne ting er meget høje, så fordelene skal være dramatiske.

Lad os nævne her en generisk tech stack, der nu passer til de fleste projekter ( selvfølgelig dækker det kun en del af den ægte tech stack, men kan være et godt udgangspunkt for nogen 🤷):

Stack

Efter at vi definerede tech stack i vores virksomhed og blev enige om det, er der også andre meget vigtige søjler for succes .

Først skal vi skriv ned tech stack til dokumentet. Dokumentet som godt og let skal deles mellem ingeniører , så de altid kan give et link til hinanden som bevis.

For det andet – vi skal igen skrive ned og dele dokument med den måde hvordan de nye projekter skal startes og bootstrapped ved hjælp af den definerede tech stack .

Tech Stack

Resumé:

Når vi har implementeret og vedtaget alt det, vi har nævnt ovenfor, skal du har alle dine projekter i organisationen til at dele den samme tech stack. Ideelt set uden forskelle. Ikke ideelt – med ubetydelige forskelle. Hvis vi også tilføjer det foregående afsnit, skal koden, mapperne, filstrukturen også være næsten identisk i dine projekter.Så at navigere på tværs af ethvert projekt bør være en meget let opgave. Godt 😊

4. Værktøj

Dette emne er meget vigtigt. Vi bruger nogle ekstra værktøjer nu næsten overalt nu – til linting, opbygning af vores apps, CI, komponentgeneratorer og meget mere. Så det er derfor, jeg ser, om vi kan vælge det rigtige værktøj til vores projekter – det er afgørende. Godt værktøj vs dårligt værktøj (eller slet ikke noget værktøj), det er det samme som en sammenligning mellem automatisering og manuel test .

Vi talte lige før i tidligere afsnit om tech stack og kodestruktur og nævnte, at vi har brug for at skrive en masse dokumentation for at få folk til at følge dem. Men det rigtige værktøjssæt kan give dig mulighed for at automatisere efter retningslinjerne i din virksomhed .

For for eksempel, hvis du har en specificeret kodestil – kan du give folk linting-værktøjssættet, som som standard følger disse regler. Hvis du har den definerede tech stack, så giver et godt CLI-værktøj dig mulighed for at starte et nyt projekt med de specifikke teknologier fra din tech stack på plads.

Lad os prøve at diskutere hvilke dele af din frontend-arkitektur kan dækkes af værktøjer:

  • Kodestil og struktur
    Som vi tidligere har diskuteret, kan dette let automatiseres med værktøjer
  • Projekt bootstrapping
    Du don ” behøver ikke at komme med en ny projektstruktur, manuelt installere alle pakker, der er nødvendige osv.
  • Generering af komponenter
    Det meste af tiden indeholder en komponent i din applikation ikke en enkelt fil, selv så oprettelse af filer, sammenkædning / import af dem kan tage tid, så dette kan automatiseres.
  • Start og opbyg
    Selvfølgelig er den mest oplagte ting at auto kompis – hvordan du opbygger eller starter din applikation.
  • Tests
    Processen med at opbygge din app til test og faktisk kørsel af alle typer tests – enhed, integration osv.
  • Afhængighedsstyring
    Som vi ved, er omkring 80\% af vores kode nu afhængigheder. Så vi er nødt til at holde dem opdaterede, og det er ikke let at gøre det i en enorm virksomhed at administrere det.
  • Tværprojektafhængigheder
    Sandsynligvis fungerer vores projekter ikke isoleret og kan afhænge af andre projekter eller være afhængige af et andet projekt, så vi har muligvis brug for nogle værktøjer til at gøre processen med at forbinde dem lettere. udvikler sig i en kombination af flere projekter (f.eks. Bit osv.
  • CI
    CI er en vigtig del af vores daglige værktøjssæt, og automatisering og forening af det kan være et meget gavnligt arbejde for din organisation.

Hvis du ikke vil udvikle nyt eget værktøjssæt, kan jeg anbefale NX-værktøjssæt , som en af ​​de mest interessante kandidater. , det ser ud til, at skaberne af Babel laver en lignende løsning, som du måske vil tjekke ud – Rom . Disse værktøjer dækker ikke alt, men en stor del af det, vi talte om, så det kan være et godt udgangspunkt.

Tooling

Resumé:

Forestil dig, hvor stor vores arkitektur kan blive, når vi har gjort alle sektioner og vedtaget 🧙

Hvert projekt er det samme og vedligeholdes og administreres af det samlede værktøjssæt. Hvert projekt kan starte og bygge på samme måde. Nye komponenter genereres samme sted og med de samme retningslinjer for navngivning.

Men er det så “sødt” eller har ulemper? Som med enhver løsning er har ulemper. En af dem – det har brug for noget tid for at få nye ingeniører til din virksomhed. Men hvis alt gøres på en meget naturlig måde (som folk allerede har vænnet sig til i andre eksisterende værktøjer) og dokumenteret, bliver dette ikke et stort problem, når man sammenligner det med fordelene ved udviklingshastighed, en mulighed for ingeniører at arbejde med enhver kodebase let osv.

5. Produktion

Om denne del af frontendarkitekturen plejer ingeniører mindst.Måske fordi det ikke er forbundet med selve kodningen for det meste🤷 og sandsynligvis ikke så spændende, men ikke mindst vigtigt ☝️

I produktionen er vi normalt nødt til at tage os af de næste ting:

  • Analytics
    Alle former for forskellige sporingshændelser osv. Ting som Google Analytics , Segment , HotJar osv.
  • Statusovervågning
    Dette inkluderer ting som helbredskontrol, der kan selv test, der køres på produktion, fejlrapportering (som Sentry ) osv.
  • Ydeevne
    Dette svarer til det forrige emne, men mere orienteret om ydeevne. Dette inkluderer måling af responstid, første meningsfuld maling osv. (Sandsynligvis værktøj nr. 1 – Fyr )
  • A / B-test
    Alle slags A / B-testløsninger eller funktionsflag.
  • Caching
    Sådanne værktøjer som Lak , Cloudflare .

Alle kan forenes på tværs af dine front-end applikationer i virksomheden, hvilket forenkler dine ingeniørers levetid . For eksempel ved at tilføje pakker med de indledende konfigurationer foruddefineret og tilføje disse pakker til dit bootstrapping-projekt.

Et andet stykke af produktionen er kodeforberedelsen, såsom:

  • Minificering
    Justificering af kode 😄
  • Kildekortlægning Kildekort kan muligvis også være nødvendige for nogle andre værktøjer som Sentry.
  • Forberedelse af aktiver
    Forberedelse til skærme med forskellige opløsninger, beskæring af billeder osv.

Det er gode kandidater, der skal føjes til det værktøjssæt, vi har til styring af frontend-applikationer, som vi talte om i afsnittet Værktøj.

Produktion

Resumé:

Ideelt set skal alle disse være tilføjet til hvert frontend-projekt som standard i bootstrapping-fasen. Og ingeniører vil kun passe på at tilføje korrekte API-nøgler de rigtige steder til værktøjerne.

6. Udvikling

CLI-værktøj

Delvist diskuterede vi allerede udviklingserfaring i værktøjssektionen, da vi rørte ved frontend-CLI-værktøjet. Unified tooling er en stor del af ingeniører “dagligt, men ikke alt.

API

Behagelig API til at arbejde med lokalt er den anden fantastiske ting, vi kan gøre for at forbedre udvikleren erfaring og udviklingshastighed. Det er normalt ikke en triviel proces at betjene API lokalt til front-end ingeniører: dette kan omfatte installation af værktøjer eller rammer, som de ikke kender. Selvom opsætningen er dockeriseret, kan dette tage en enorm mængde computing ressourcer fra udviklerens maskiner (hvis det ikke er – dette kan betragtes som en opsætning). Hvad kan være en løsning i dette tilfælde – eksternt serveret API. Dette kan være en enkelt server for alle ingeniører eller en eller anden mekanisme til bootstrap let din egen dedikerede server til udvikling.

CI

CI er den tredje store del. Jeg antager måske, at din virksomhed allerede har valgt et CI-værktøj til frontend og bruger dette enkelt værktøj (f.eks. Cirkel CI ,

Concourse CI eller andre). Hvis ikke – skal du samle det.

CI-konfiguration af det bestemte projekt skal efter min mening være en del af teamets job, der arbejder på projektet. Dette giver chancer for CI at være stabil, fordi der er mennesker, der er interesserede i CI, der skal arbejde, bruger det hver dag og har styrken og færdighederne til at rette, konfigurere og forbedre det.

Dog ikke alt arbejde skal udføres af teamet. For front-end-applikationer findes en temmelig specifik flok job, som potentielt kan være nødvendige. Især hvis vi kunne klare at samle mappe / kodestruktur, tech stack osv. Så efter et stykke tid i din virksomhed kan det komme, når du vil være i stand til at opdage disse mønstre for faser af dit CI-værktøj, implementere disse faser som en slags “byggesten” og give dine ingeniører mulighed for bare at konstruere deres CI-rørledninger ud fra de samlede “byggesten”.

Demomiljøer

Og endelig den sidste – verifikation af den implementerede funktion.Når ingeniører har gjort alt og implementeret – har de næsten altid brug for på en eller anden måde at kontrollere, hvordan det ser ud, og hvordan det fungerer, og dele dette med andre ingeniører, designere eller andre interessenter. Til sådanne behov fungerer det super godt den midlertidige implementerede version af din applikation til den specifikke PR med den angivne URL.

App midlertidigt implementeret
App implementeret midlertidigt

Denne løsning fremskynder kommunikationen mellem forskellige teams og mennesker meget, og jeg tror, ​​det er bare en må have. Denne midlertidigt implementerede version skal dog være så tæt på produktionen som muligt, fordi det også kan være et godt værktøj til kontrol af overfladefejl eller bugs.

Dette kan let føjes til dine projekter og automatiseres, hvis din frontend applikationsopbygning og implementeringsprocesrørledninger er samlet. Sådanne eller lignende værktøjer som Kubernetes og Helm kan også hjælpe meget med implementeringen.

Udvikling

Resume:

Komfortabel og effektiv udviklingsstrøm med et enkelt CI-værktøj med byggesten til at gøre CI-pipeline med samlet CLI-frontendværktøj og demomiljøer. Alle disse skal gøre vores udviklingsproces så glat som muligt. Multiplicer dette med antallet af ingeniører, du har i virksomheden, og du vil forstå, hvor gavnligt det er.

7. Modularitet

Dette emne er meget stort og kan tage en separat artikel at tale om, men jeg vil kort prøve at gå igennem det.

I store organisationer er enorme kodebaser ikke sjældne ting. Med alle de kendte problemer, der kommer sammen med dem, som langsomme CI-rørledninger, problemer med samarbejdsarbejde, langsomme tests osv. Så det store stykke af frontendarkitekturen er en beslutning om, hvor detaljeret vi vil se uafhængige frontend-applikationer / moduler.

Der er 3 hovedmodeller, vi har nu:

  • Monolit
    Et stort lager med et enkelt projekt og al koden der, alle holdene arbejder på dette lager sammen på samme tid.
  • Monorepo
    Mange projekter, men stadig et stort lager ( monorepo i wiki ). Alle holdene arbejder stadig i samme arkiv, men med forskellige projekter. Der er allerede muligheder for at løse nogle problemer, som vi har med en monolit-tilgang, ved kun at køre rørledninger til specifikke projekter, projekter har mindre testpakker osv. Sådanne værktøjer som Lerna kan gøre dit liv langt lettere, hvis du vælger denne tilgang.
  • Repo pr. projekt
    Hvert projekt har sit eget arkiv og alle de understøttende ting, såsom CI-rørledninger, implementeringer osv.

I alle disse modeller kan projektet betyde en uafhængig frontend-applikation, side, uafhængigt frontend-modul osv. Dette afhænger af, hvor detaljeret du vil beslutte at opdele dine front-end applikationer. I de fleste tilfælde skal denne opdeling være synkroniseret med den ønskede organisationsstruktur og personaleadministration.

Det andet store emne, efter at du har besluttet, hvordan du skal opdele din ansøgning, er, hvordan man forbinder disse stykker sammen (hvis du besluttede for at opdele din ansøgning).

Og her har vi de næste tilgange:

  • Byggetidskomposition
    Dine projekter kan kun være npm-pakker, installeret og sammensat i løbet af byggetiden.
  • Server- sidesammensætning
    Denne fremgangsmåde inkluderer normalt Server Side Rendering og sammensætningen sker på en server. Sådanne værktøjer som Hypernova kan hjælpe med at organisere det bedre.
  • Komposition på klientsiden
    Sammensætning af projekterne i browseren. I Martin Fowlers blog er der en ret god forklaring på nogle tilgange – her . Også meget vigtigt at nævne Module Federation , en ny tilgang introduceret i Webpack 5 .
  • Rutesammensætning
    Super simpelt – bare hvert projekt har sin egen URL og på et “Nginx-niveau” beslutter vi, hvor brugerne skal omdirigeres.(undskyld, for en sådan forklaring 😄 men jeg troede, det ville være den nemmeste at forstå)

Som jeg sagde før, er det super svært at dække dette emne i et så lille format, men jeg håber, at du i det mindste har fundet nogle interessante ideer til dig selv og vil grave i emnerne selv 🙏🏻 .

Modularitet

Resume:

Vi fandt en måde at gøre vores teams glade og produktive ved at organisere arkiverne, opdele vores projekter i mindre stykker (sandsynligvis), ved at gøre holdene mere uafhængige af hinanden.

Velkommen til paradis 😁

8. Testning

Der er så mange ressourcer til rådighed om testning til front-end-applikationer, så jeg vil prøve ikke at komme i detaljer, som du kan easi find, men fokuser mere på store organisationers spørgsmål og hvordan vi kan løse dem.

Den første af dem – hver ingeniør forstår testteknik forskelligt, også hvilken teknik der skal anvendes i hvilken situation, hvordan man skriver “ gode ”tests osv. Så det giver meget mening at dokumentere nøjagtigt alle nuancer og retningslinjer for de testniveauer, der anvendes i virksomheden og retningslinjer for hver af dem.

Mulige testniveauer, du vil har i din teststrategi:

  • Enhedstest
  • Integrationstest
  • E2E-test
  • … og andre

Som et andet trin er vi desuden nødt til at samle dem på tværs af forskellige frontend-applikationer hos virksomheden, så folk ikke har spørgsmål om, hvordan og hvad de skal teste, når de flyttes til et andet projekt.

Hvis det lykkedes dig at forene testniveauer og fremgangsmåder, kan du automatisk hjælpe med at løse det andet problem – test af infrastrukturopsætning. Hvert projekt på sit eget behov for at oprette og konfigurere det lokalt og på CI nogle testinfrastrukturer. For eksempel besluttede vi, at vi bruger Cypress, og det skal køres inde i et dockerbillede. Dette har brug for noget tid for at blive konfigureret lokalt og på CI. Hvis vi multiplicerer det med antallet af projekter, vi har – det er en enorm tid. Så løsningen – at samle det igen og give nogle værktøjer til projekterne. Det lyder let, men det tager en enorm tid at gennemføre.

Tidstest uden udvikling

Jeg ville også røre ved en anden måde at teste dine applikationer på efter funktioner, der allerede er implementeret og implementeret. Og ja, overvågning er selvfølgelig en del af det 😁.

Vi har allerede nævnt i tidligere afsnit fejl- og ydeevneovervågning for frontend-applikationer, overvågning af oppetid, svaret fra forskellige placeringer.

Det er også godt at have Lighthouse -tests køres på dit websted (kan medtages i CI-rørledningerne). For at finde lettere præstationsflaskehalse, tilgængelighedsproblemer og generelt forbedre websides kvalitet.

Og sidst – produktionstest på de vigtigste forretningsstrømme. Mest sandsynligt fungerer de bedst, hvis du kører dem direkte på produktet på miljø, men det kan også være muligt at ændre, når vi kan køre sådanne tests på et iscenesættelses- / testmiljø, som er meget tæt på produktionen eller endda spejler det. Der er en meget flot artikel om dette emne – (her).

Testning

Resumé:

Vi har klare testretningslinjer med definerede nødvendige testniveauer for hver frontend-applikation. Vi har en enkelt CI-pipeline til hver applikation, og vi har et enkelt CLI-værktøj, der hjælper med at køre tests lokalt.

Sidste ord

Jeg håber virkelig, at I har fundet noget interessant i dette artikel. Jeg er meget ked af, at jeg i de fleste emner bare har ridset overfladen af ​​problemerne. Og vil gerne diskutere dem mere, så lad dine spørgsmål være i kommentarerne eller ping mig direkte på twitter – @denieler .