Sådan opnås genanvendelighed med reaktionskomponenter

Genanvendelighed er et af de mest almindelige buzzwords i software engineering i dag. Det loves af en bred vifte af rammer, værktøjer og paradigmer, der hver især ser ud til ikke kun at have sin egen tilgang til opnåelse af genanvendelighed, men også sin egen definition af selve ordet.

Så hvad mener vi med genanvendelighed?

Ægte genanvendelighed er ikke en ad hoc-proces, men en udviklingsstrategi. Genanvendelige komponenter skal bygges fra bunden med genanvendelighed i tankerne, hvilket indebærer omhyggelig planlægning og empatisk API-design. Selvom moderne udviklingsværktøjer og -rammer kan understøtte og tilskynde til genbrug af kode, kan genanvendelse ikke opnås gennem teknologi alene - det kræver processer, der implementeres konsekvent på tværs af teams og engagement på alle organisationsniveauer.

Så når vi diskuterer genanvendelighed, er det ikke kun en teknisk diskussion. Det inkluderer også virksomhedskultur, træning og en række andre overvejelser. Vi vil berøre et par af dem her, men pointen er, at genanvendelighed er en proces, der berører alle faser i udviklingen og hvert niveau i en organisation.

Walmart består af flere mærker, herunder Sam's Club, Asda og regionale filialer som Walmart Canada og Walmart Brazil. På tværs af disse mærker har vi snesevis af front-end applikationer bygget og vedligeholdt af hundreder af udviklere.

Fordi hvert af disse mærker har sin egen online tilstedeværelse, har de udviklere, der arbejder på komponenter, der er fælles for alle Walmarts mærker - for eksempel en billedkarrusel, navigationselementer som brødmuler, flyouts, kreditkortformkomponenter. Kopiering af arbejde, der allerede er afsluttet af et andet team, er spild af tid og penge og skaber også mere overfladeareal for fejl. Ved at fjerne denne duplikering kan udviklere bruge mere tid på projekter, der giver ny værdi for kundeoplevelsen.

På backend er deling af kode på tværs af mærker mere intuitiv: en enkelt tjeneste kan tage anmodninger fra flere forskellige mærker og returnere de relevante data for dette mærke (og der er et par måder at håndtere det på baggrund af dataformen). I forreste ende er situationen mere kompliceret, fordi den involverer at tage dataene, der leveres af backend, og anvende temaer og andre transformationer, der er passende til et specifikt brand og synspunkt. At gøre dette på en måde, der fremmer genbrug, er ikke et helt løst problem.

React Component Reuse at @WalmartLabs

For Walmart.com valgte vi React for vores frontend-ramme, og en af ​​grundene til, at vi valgte det, var, at dens komponentmodel giver et godt udgangspunkt for kodegenbrug - især når det parres med Redux til statsledelse. Der er stadig betydelige udfordringer med at fremsende kode genbrug i en organisation på størrelse med Walmart.

Teknisk kapacitet til at dele kode

Den første udfordring involverer de tekniske midler til deling af kode - komponenter skal versioneres, lette at installere og opgraderes. Vi placerer alle vores React-komponenter i en separat GitHub-organisation. I øjeblikket samles komponenter i repos baseret på de teams, der har oprettet dem, men vi er i færd med at bevæge os hen imod funktionelle repos, f.eks. En "Navigation" -repo, der indeholder brødkrumm, faner og sidenav-linkkomponenter. Derefter offentliggøres komponenter i vores private npm-registreringsdatabase, hvilket betyder, at udviklere let kan installere en bestemt komponentversion, hvilket sikrer, at deres apps ikke pludselig går i stykker ved opgradering.

Da der deles kode på tværs af hold på dette tidspunkt, var vi nødt til at sikre en ensartet struktur og kodningsstandarder på tværs af hundreder af komponenter, selv når afhængigheder opdateres og behovene ændres. Derfor har vi oprettet elektrode-arketyper til komponenter og applikationer. Arketyperne inkluderer konfigurationsfiler til fnug, transpilering og bundling og giver et centralt punkt, hvorfra vi kan styre kerneafhængigheder og opgaver / scripts. At starte fra en fælles struktur og etablere ensartede kodningsstandarder på tværs af alle projekter gør det muligt for os at opretholde moderne bedste praksis i hele organisationen og øger tilliden, som udviklere har til hinandens kode, hvilket forbedrer chancerne for, at genanvendelige komponenter faktisk bliver genbrugt. Denne tillid forbedres yderligere ved et strengt kontinuerligt integrationssystem / kontinuerligt implementeringssystem, herunder regler til fnugkode, målepræstation og test på tværs af flere enheder, browsere og skærmopløsninger. CI-systemet kan omfatte regler for at offentliggøre en betaversion af en komponent, når en PR indsendes og køre funktionelle test af alle applikationer, der bruger denne komponent, for at sikre, at PR'et ikke bryder noget.

Metateamet

I de tidlige dage af dette projekt blev hovedparten af ​​delte komponenter bidraget med kun et par hold, og disse komponenter havde en tendens til at ændre sig meget hurtigt. Til sidst valgte vi et par udviklere med en særlig dyb forståelse af elektroderammen og Walmart internals og skabte en gruppe, vi kalder vores metateam. Disse personer ville bruge et par timer eller en dag hver par uger til at gennemgå koden, der går ind i komponentorganisationen, sikre, at al bedste praksis følges, og generelt hjælpe dem på enhver måde, de kunne. Dette team udviklede også en samlet viden om, hvad der bygges på tværs af organisationen, og fungerede som ambassadører for elektrode-projektet i deres egne teams. Metateammedlemmer tog også information om afventende ændringer af arketype til deres teams og indsamlede feedback for at dele med elektrode-kerneteamet.

Disse trin var en god start, men vi så stadig flere muligheder for at forbedre kodegenbrug som organisation.

Opdagbarhed Problem med hundreder af komponenter

Vi begyndte at bemærke en masse beskeder i vores Slack-kanaler langs et delt tema. Udviklere ønskede at vide, om en komponent allerede var oprettet til en bestemt opgave eller ej. UX-hold ville være i stand til at se, hvilke komponenter der var tilgængelige. Projektledere ønskede at se, hvilke komponenter der blev bygget af andre teams. Den fælles tråd blandt alle disse meddelelser var synlighed. Vi havde brug for en hurtig, enkel måde at finde ud af, hvilke komponenter der var tilgængelige, at se dem i brug og interagere med dem og lære om deres implementering, konfiguration og afhængigheder.

Vores svar på dette problem er Electrode Explorer, som jeg drøftede i et tidligere indlæg. Explorer giver vores udviklere mulighed for at gennemse de hundredvis af komponenter, der er tilgængelige i @WalmartLabs, læse deres dokumentation og se, hvordan de ser ud, og endda gå gennem deres versionhistorik for at se, hvordan de har ændret sig over tid. Da Electrode Explorer leverer en webgrænseflade til alle React-komponenter i en organisation, behøver udviklere ikke at "npm installere" en komponent for at se den og interagere med den.

Kopiering, der spildes gennem revnerne

Men selv med alle disse værktøjer og processer for at lette genbrug af koder, så vi stadig problemer. Et spørgsmål var, at hold ofte udviklede nye komponenter uden at erkende, at de kunne være nyttige for andre teams. Komponenter kan ikke genbruges, hvis de ikke er inkluderet i det genanvendelige økosystem. Selv inden for det delte komponentsystem så vi en masse duplikering eller komponenter, der tog lidt forskellige fremgangsmåder til meget lignende problemer. Det, vi indså, er, at teknologiske løsninger ikke er nok - der skal ske en virksomhedsomfattende tænkning, hvor interessenter på alle niveauer tager en genanvendelses-første tilgang. Dette inkluderer at tage sig tid til at generalisere komponenter, så genanvendelse er lettere, udvide eksisterende komponenter i stedet for at starte fra bunden og bevidst søge muligheder for at dele kode, når det er muligt.

For at hjælpe denne ændring i tankegang oprettede vi en komponentforslagsproces. Under dette system diskuterer udviklere nye komponenter, inden de begynder at arbejde på dem. Dette giver udviklere på andre hold mulighed for at foreslå eksisterende løsninger eller alternative tilgange og lader andre i organisationen vide, hvad der sker.

Forslagssystemet sammen med metaprocessen hjælper ikke med at få dobbeltarbejde gennem revnerne.

Betydningen af ​​CI / CD

Et stort problem, vi løb ind i, var, at et team ville arbejde på en komponent og ødelægge et andet teams anvendelse. Hvis du ikke låste din komponentversion ned, kan din CI / CD muligvis mislykkes på grund af, at en komponent blev ændret af et andet team - det er en frygtelig følelse, og det fører til, at en masse hold låser komponenter til en meget specifik version, hvor de tager måske ikke engang nye patch-versioner.

Det er her CI / CD kommer ind. Når en komponentversion opdateres, skal automatisering kontrollere, om den ødelægger nogen indtagende applikationer på den store version - den skal kontrollere dette, selvom applikationen låser dens komponentversioner. Hvis der ikke er nogen pause, ønsker vi, at CI / CD-systemet sender en PR-anmodning, der opdaterer den låste version til den nye, der ikke har brudt applikationen. Hvis der er en pause, skal begge hold informeres om at tale, hvad problemet er.

Innersource

Grundlaget for vores tilgang til genanvendelighed er vores omfavnelse af open source / inner source filosofi, som beskrevet af Laurent Desegur i et tidligere indlæg. @WalmartLabs har været en bruger af og bidragyder til open source i årevis, som demonstreret af projekter som Hapi, OneOps og Elektrode. Mindre indlysende uden for virksomheden er vores engagement i indre kilde, som er den interne anvendelse af open source-modellen. I den indre kildetilgang "ejer" ingen team eller udvikler en komponent - alle komponenter deles i hele organisationen. Dette eliminerer flaskehalse og giver udviklere mulighed for at forbedre eksisterende komponenter.

Disse politikker øger mulighederne for genbrug i høj grad - men det er vigtigere, at de signaliserer udviklerne vores engagement som virksomhed til en filosofi om samarbejde og samarbejde. De giver udviklere mulighed for at bruge deres tid og ekspertise, hvor det er mest nødvendigt, snarere end at vente på, at flaskehalse ryddes, og de drager fordel af virksomheden på reelle, målbare måder.

Konklusion

Genanvendelighed er ikke kun en teknisk beslutning, men også en filosofisk, der kræver organisatorisk engagement og har vidtrækkende konsekvenser. På @WalmartLabs har vi set fordelene, det kan medføre - lige nu flytter vi SamsClub.com til elektrode-platformen, og vores udviklere genbruger hundredvis af komponenter fra Walmart.com med temaer, der passer til Sam's Club-mærket.

Fortæl os din historie om genanvendelse - hvilke hindringer har du stødt på? Hvordan har du løst dem? Hvilke muligheder for yderligere forbedringer ser du?