Jak dosáhnout opakovatelnosti s komponentami React

Opětovné použití je dnes jedním z nejčastějších hesel v softwarovém inženýrství. Slibuje to celá řada rámců, nástrojů a paradigmat, z nichž každý má nejen svůj vlastní přístup k dosažení opětovného použití, ale také svou vlastní definici samotného slova.

Co tedy myslíme opakovaným použitím?

Skutečná opakovaná použitelnost není procesem ad hoc, ale rozvojovou strategií. Opakovaně použitelné komponenty musí být vytvořeny od základů s ohledem na opětovné použití, což vyžaduje pečlivé plánování a návrh empatického API. Ačkoli moderní vývojové nástroje a rámce mohou podporovat a povzbuzovat opakované použití kódu, opětného použití nelze dosáhnout pouze technologií - vyžaduje procesy důsledně implementované napříč týmy a závazek na všech úrovních organizace.

Takže když diskutujeme o opakovaném použití, nejedná se pouze o technickou diskusi. Zahrnuje také firemní kulturu, školení a řadu dalších úvah. Dotkneme se několika z nich zde, ale jde o to, že opětovné použití je proces, který se dotýká každé fáze vývoje a každé úrovně organizace.

Walmart se skládá z několika značek, včetně Sam's Club, Asda a regionálních poboček, jako je Walmart Canada a Walmart Brazil. V těchto značkách máme desítky front-end aplikací vytvořených a udržovaných stovkami vývojářů.

Protože každá z těchto značek má svou vlastní online přítomnost, každá z nich má vývojáře pracující na součástech, které jsou společné všem značkám Walmartu - karuselu obrazu, navigační prvky, jako jsou drobky, plovoucí výplně, součásti formulářů kreditních karet. Duplikování práce, kterou již dokončil jiný tým, je ztráta času a peněz a také vytváří větší plochu pro chyby. Eliminace této duplikace umožňuje vývojářům trávit více času na projektech, které přinášejí zákazníkům novou hodnotu.

Na druhé straně je sdílení kódu napříč značkami intuitivnější: jedna služba může přijímat žádosti od více různých značek a vracet příslušná data pro tuto značku (a existuje několik způsobů, jak to zvládnout na základě tvaru dat). V první řadě je situace složitější, protože zahrnuje převzetí údajů poskytnutých backendem a použití témat a dalších transformací vhodných pro konkrétní značku a pohled. Dělat to způsobem, který podporuje opětovné použití, není úplně vyřešen problém.

React Reuse Reuse Reuse at @WalmartLabs

Pro Walmart.com jsme vybrali React pro náš front-end framework a jedním z důvodů, proč jsme si vybrali, bylo to, že jeho model komponenty poskytuje dobrý výchozí bod pro opětovné použití kódu - zejména když je spárován s Redux pro správu státu. Stále však existují významné výzvy, jak zabránit opětovnému použití kódu v organizaci velikosti Walmartu.

Technická schopnost sdílet kód

První výzva zahrnuje technické prostředky sdílení kódu - komponenty musí být verzovány, snadno instalovatelné a upgradovatelné. Všechny naše komponenty React jsme vložili do samostatné organizace GitHub. V současné době jsou komponenty seskupeny do repozitářů na základě týmů, které je vytvořily, ale právě se pohybujeme směrem k funkčním repozitářům, jako je repo navigace, která obsahuje stručnou složku, karty a komponenty sidenav odkazů. Komponenty jsou poté zveřejněny v našem soukromém registru npm, což znamená, že vývojáři mohou snadno nainstalovat konkrétní verzi komponenty a zajistit, aby se jejich aplikace náhle nerozpadly při upgradu.

V tomto okamžiku, protože se kód sdílí napříč týmy, jsme potřebovali zajistit konzistentní strukturu a standardy kódování napříč stovkami komponent, a to i v případě, že jsou závislosti aktualizovány a potřeby se mění. Proto jsme vytvořili elektrodové archetypy pro komponenty a aplikace. Archetypy zahrnují konfigurační soubory pro linkování, transplantaci a sdružování a poskytují centrální bod, ze kterého můžeme spravovat základní závislosti a úkoly / skripty. Počínaje společnou strukturou a stanovením jednotných standardů kódování napříč všemi projekty nám umožňuje udržovat moderní osvědčené postupy v celé organizaci a zvyšovat důvěru, kterou mají vývojáři ve vzájemný kód, čímž se zvyšuje šance, že opakovaně použitelné komponenty budou skutečně znovu použity. Tuto důvěru dále zvyšuje přísný systém nepřetržité integrace / nepřetržitého nasazení, včetně pravidel pro rozdělování kódu, měření rozměru a testování na více zařízeních, prohlížečích a rozlišení obrazovky. Systém CI může zahrnovat pravidla pro publikování beta verze komponenty při odeslání PR a spuštění funkčních testů všech aplikací používajících tuto komponentu, aby bylo zajištěno, že PR nic nenaruší.

Tým Meta

V počátečních dnech tohoto projektu přispělo k většině sdílených složek jen několik týmů a tyto složky se velmi rychle změnily. Nakonec jsme vybrali několik vývojářů se zvláště hlubokým porozuměním rámce Electrode a interních Walmartů a vytvořili skupinu, kterou nazýváme náš meta tým. Tito jednotlivci by věnovali několik hodin nebo den každých několik týdnů revizi kódu, který jde do organizace součástí, zajistili dodržování všech osvědčených postupů a obecně pomohli jakýmkoli způsobem. Tento tým také získal celkovou znalost toho, co se buduje v celé organizaci, a sloužil jako vyslanci projektu Electrode ve svých vlastních týmech. Členové týmu Meta také vzali informace o čekajících změnách archetypů v jejich týmech a shromáždili zpětnou vazbu, aby je mohli sdílet s jádrovým týmem společnosti Electrode.

Tyto kroky byly skvělým začátkem, ale stále jsme viděli další příležitosti ke zlepšení opětovného použití kódu jako organizace.

Objevitelnost problému stovek komponent

Začali jsme si všimnout spoustu zpráv na našich Slack kanálech podle sdíleného tématu. Vývojáři chtěli vědět, zda komponenta již byla pro určitý úkol vytvořena. Týmy UX chtěly vidět, jaké komponenty jsou k dispozici. Projektoví manažeři chtěli vidět, jaké komponenty vytvářejí jiné týmy. Společným vláknem všech těchto zpráv byla zjistitelnost. Potřebovali jsme rychlý a jednoduchý způsob, jak zjistit, jaké komponenty byly k dispozici, vidět, jak jsou používány a jak s nimi interagovat, a dozvědět se o jejich implementaci, konfiguraci a závislostech.

Naše odpověď na tento problém je Electrode Explorer, o které jsem hovořil v předchozím příspěvku. Průzkumník umožňuje našim vývojářům procházet stovky komponent dostupných v @ WalmartLabs, číst jejich dokumentaci a vidět, jak vypadají, a dokonce procházet jejich historii verzí a sledovat, jak se v průběhu času měnili. Protože Electrode Explorer poskytuje webové rozhraní pro všechny komponenty React v organizaci, vývojáři nemusí komponentu `npm instalovat ', aby ji mohli vidět a pracovat s ní.

Duplikace rozlití trhlinami

Ale i se všemi těmito nástroji a procesy, které usnadňují opakované použití kódu, jsme stále viděli problémy. Jedním problémem bylo, že týmy často vyvíjely nové komponenty, aniž by si uvědomovaly, že by mohly být užitečné pro další týmy. Komponenty nelze znovu použít, pokud nejsou zahrnuty do opakovaně použitelného ekosystému. Dokonce i v rámci sdíleného systému komponent jsme viděli mnoho duplikátů nebo komponent, které se k velmi podobným problémům chovaly poněkud odlišně. Uvědomili jsme si, že technologická řešení nestačí - je třeba změnit myšlení v celé společnosti, přičemž zúčastněné strany na všech úrovních přistupují k opětovnému použití. To zahrnuje věnování času na generalizaci součástí, aby bylo jejich opětovné použití snazší, rozšiřování stávajících komponent, spíše než počínaje od nuly, a vědomé vyhledávání příležitostí ke sdílení kódu, kdykoli je to možné.

Abychom této změně myšlení pomohli, vytvořili jsme proces návrhu součásti. V tomto systému vývojáři diskutují o nových komponentách, než na nich začnou pracovat. To poskytuje příležitost vývojářům v jiných týmech navrhovat stávající řešení nebo alternativní přístupy a ostatním v organizaci umožňuje vědět, co se děje.

Návrhový systém spolu s meta procesem pomáhá, aby se zdvojení nedostalo skrz praskliny.

Význam CI / CD

Velkým problémem, na který jsme narazili, bylo to, že jeden tým by pracoval na komponentě a přerušil aplikaci jiného týmu. Pokud jste nezablokovali svou verzi komponenty, vaše CI / CD by mohlo selhat kvůli úpravě komponenty jiným týmem - je to hrozný pocit, a to vede k tomu, že mnoho týmů blokuje komponenty do velmi specifické verze, kde možná ani nepřijímají nové verze oprav.

To je místo, kde CI / CD přichází do hry. Při aktualizaci verze součásti by automatizace měla zkontrolovat, zda v této hlavní verzi nenaruší náročné aplikace - měla by to zkontrolovat i v případě, že aplikace uzamkne její verze součástí. Pokud nedojde k žádné přestávce, chceme, aby systém CI / CD odeslal žádost o PR, která aktualizuje uzamčenou verzi na novou verzi, která neporušila aplikaci. Pokud dojde k přestávce, měly by být oba týmy upozorněny, aby zjistily, o jaký problém jde.

Innersource

Základem našeho přístupu k opakovanému použití je naše přijetí filozofie otevřeného zdroje / vnitřního zdroje, jak popisuje Laurent Desegur v předchozím příspěvku. @WalmartLabs byl uživatelem a přispívá k otevřenému zdroji let, jak ukazují projekty jako Hapi, OneOps a Electrode. Méně zřejmé z vnější strany společnosti je náš závazek k vnitřnímu zdroji, což je interní aplikace modelu otevřeného zdroje. V přístupu vnitřních zdrojů žádný tým nebo vývojář „nevlastní“ komponentu - všechny komponenty jsou sdíleny v celé organizaci. To eliminuje úzká místa a umožňuje vývojářům vylepšovat stávající komponenty.

Tyto zásady výrazně zvyšují příležitosti k opětovnému použití - ale co je důležitější, signalizují vývojářům náš závazek společnosti jako filozofie spolupráce a spolupráce. Umožňují vývojářům, aby využívali svůj čas a odborné znalosti tam, kde je to nejpotřebnější, a ne čekali, až se odstraní úzká místa, a prospívají společnosti skutečnými, měřitelnými způsoby.

Závěr

Opětovné použití není jen technické rozhodnutí, ale také filozofické rozhodnutí, které vyžaduje organizační závazek a má dalekosáhlé důsledky. Ve společnosti @WalmartLabs jsme viděli výhody, které to může přinést - právě teď přesouváme SamsClub.com na platformu Electrode a naši vývojáři opakovaně používají stovky komponent z webu Walmart.com s tématem, aby odpovídali značce Sam's Club.

Řekněte nám svůj příběh o opakovaném použití - s jakými překážkami jste se setkali? Jak jste je vyřešili? Jaké příležitosti vidíte pro další vylepšení?