Как да постигнем повторно използване с реагиращи компоненти

Повторната употреба е един от най-разпространените ключови думи в софтуерното инженерство днес. Това е обещано от голямо разнообразие от рамки, инструменти и парадигми, всяка от които изглежда има не само свой подход за постигане на повторна употреба, но и собствена дефиниция на самата дума.

И така, какво имаме предвид под многократна употреба?

Истинската повторна употреба не е ad hoc процес, а стратегия за развитие. Компонентите за многократна употреба трябва да бъдат изградени от основата, като се има предвид повторното използване, което включва внимателно планиране и съпричастен дизайн на API. Освен това, въпреки че съвременните инструменти и рамки за развитие могат да поддържат и насърчават повторното използване на кодове, повторното използване не може да бъде постигнато само чрез технологията - това изисква процеси, реализирани последователно в екипи, и ангажираност на всички нива на организация.

Така че, когато обсъждаме повторното използване, това не е просто техническа дискусия. Той също така включва корпоративна култура, обучение и редица други съображения. Ще засегнем някои от тези тук, но въпросът е, че повторната употреба е процес, който докосва всеки етап на развитие и всяко ниво на организация.

Walmart се състои от няколко марки, включително клуб на Sam, Asda и регионални клонове като Walmart Canada и Walmart Brazil. В тези марки имаме десетки приложения за предни приложения, изградени и поддържани от стотици разработчици.

Тъй като всяка от тези марки има собствено онлайн присъствие, всеки има разработчици, работещи върху компоненти, които са общи за всички марки на Walmart - въртележка за изображения, навигационни елементи като хлебни трохи, флаери, компоненти на формуляри за кредитна карта, например. Дублирането на работа, която вече е завършена от друг екип, е загуба на време и пари, а също така създава повече повърхност за грешки. Елиминирането на това дублиране позволява на разработчиците да отделят повече време за проекти, които носят нова стойност на клиентското изживяване.

От друга страна, споделянето на код между марки е по-интуитивно: една услуга може да приема заявки от множество различни марки и да връща подходящите данни за тази марка (и има няколко начина да се справите с това въз основа на формата на данните). В предния край ситуацията е по-сложна, тъй като включва вземане на данните, предоставени от задния ред и прилагане на теми и други трансформации, подходящи за конкретна марка и изглед. Правенето на това по начин, който насърчава повторното използване не е напълно решен проблем.

Повторно използване на компонента на @WalmartLabs

За Walmart.com избрахме React за нашата рамка на предния край и една от причините, които избрахме, беше, че моделът на компонента му осигурява добра отправна точка за повторна употреба на код - особено когато е сдвоен с Redux за управление на държавата. Все пак има значителни предизвикателства при повторното използване на кода на фронтенда в организация с размерите на Walmart.

Техническа способност за споделяне на код

Първото предизвикателство включва техническите средства за споделяне на код - компонентите трябва да бъдат обособени, лесни за инсталиране и надграждане. Ние поставяме всички наши компоненти на React в отделна организация GitHub. Понастоящем компонентите се групират в repos въз основа на екипите, които са ги създали, но ние сме в процес на преминаване към функционални репозиции, като репо „Навигация“, съдържаща галета, раздели и компоненти на връзката sidenav. След това компонентите се публикуват в нашия частен регистър на npm, което означава, че разработчиците могат лесно да инсталират конкретна версия на компонента, като гарантират, че приложенията им няма да се счупят внезапно при надстройката.

На този етап, тъй като кодът се споделя между екипи, ние трябваше да осигурим последователна структура и стандарти за кодиране в стотици компоненти, дори когато зависимостите се надграждат и се нуждаят от промяна. Ето защо създадохме Electrode Archetypes за компоненти и приложения. Архетипите включват конфигурационни файлове за свързване, транспилация и групиране и предоставят централна точка, от която можем да управляваме основните зависимости и задачи / скриптове. Изхождайки от обща структура и установявайки последователни стандарти за кодиране във всички проекти, ни позволява да поддържаме съвременни най-добри практики в цялата организация и увеличава доверието, което разработчиците имат в кода на другия, като подобрява шансовете за реално използване на компоненти за многократна употреба. Тази увереност се подобрява допълнително от строга система за непрекъсната интеграция / непрекъснато внедряване, включваща правила за кода на кода, измерване на ефективността и тестване на множество устройства, браузъри и разделителни способности на екрана. CI системата може да включва правила за публикуване на бета версия на компонент, когато PR е подаден и изпълнява функционални тестове на всички приложения, използващи този компонент, за да се гарантира, че PR не нарушава нищо.

Мета екипът

В първите дни на този проект, по-голямата част от споделените компоненти бяха допринесени само от няколко екипа и тези компоненти имаха тенденция да се променят много бързо. В крайна сметка избрахме няколко разработчици с особено дълбоко разбиране на рамката на Electrode и вътрешността на Walmart и създадохме група, която наричаме наш мета екип. Тези лица ще отделят по няколко часа или ден на всеки няколко седмици за преглед на кода, влизащ в организацията на компонентите, да гарантират спазването на всички най-добри практики и като цяло да помагат по какъвто начин могат. Този екип също разработи цялостни познания за това какво се изгражда в цялата организация и служи като посланици за проекта Electrode в техните собствени екипи. Членовете на екипа на Meta също взеха информация за предстоящите промени в архетипа на своите екипи и събраха обратна връзка, за да споделят с основния екип на Electrode.

Тези стъпки бяха чудесно начало, но все още виждахме допълнителни възможности за подобряване на повторната употреба на код като организация.

Проблем с откриваемост на стотици компоненти

Започнахме да забелязваме много съобщения в нашите Slack канали по споделена тема. Разработчиците искаха да знаят дали компонент вече е създаден за определена задача. Екипите на UX искаха да могат да видят какви компоненти са налични. Ръководителите на проекти искаха да видят какви компоненти се изграждат от други екипи. Общата нишка сред всички тези съобщения беше откриваемостта. Трябваше ни бърз и прост начин да открием какви компоненти са налични, да ги видим в употреба и да взаимодействат с тях и да научим за тяхното прилагане, конфигурация и зависимости.

Нашият отговор на този проблем е Electrode Explorer, който обсъдих в предишна публикация. Explorer дава възможност на нашите разработчици да разгледат стотиците компоненти, налични в @WalmartLabs, да прочетат документацията им и да видят как изглеждат и дори да разгледат историите на версиите си, за да видят как са се променили с времето. Тъй като Electrode Explorer предоставя уеб интерфейс за всички компоненти на React в дадена организация, разработчиците не се нуждаят от „npm install“ компонент, за да го видят и да взаимодействат с него.

Дупликация, разливаща се през пукнатините

Но дори и с всички тези инструменти и процеси за улесняване на повторното използване на кода, все още видяхме проблеми. Един от въпросите беше, че екипите често разработват нови компоненти, без да признават, че могат да бъдат полезни за други екипи. Компонентите не могат да бъдат използвани повторно, ако не са включени в екосистемата за многократна употреба. Дори и в системата на споделените компоненти видяхме много дублиране или компоненти, които взеха малко по-различни подходи към много подобни проблеми. Това, което разбрахме, е, че технологичните решения не са достатъчни - трябва да има промяна в мисленето за цялата компания, при което заинтересованите страни на всички нива използват подход за повторно използване. Това включва отделяне на време за генерализиране на компоненти, така че повторната им употреба да бъде по-лесна, разширяване на съществуващите компоненти, а не започване от нулата и съзнателно търсене на възможности за споделяне на код, когато е възможно.

За да подпомогнем тази промяна в мисленето, създадохме процес на компонентно предложение. В тази система разработчиците обсъждат нови компоненти, преди да започнат работа върху тях. Това предоставя възможност на разработчиците в други екипи да предложат съществуващи решения или алтернативни подходи и дава възможност на другите в организацията да знаят какво се случва.

Системата за предложения заедно с мета процеса помага да няма дублиране да премине през пукнатините.

Значение на CI / CD

Голям проблем, с който се сблъскахме, беше, че един екип ще работи върху компонент и ще разбие приложението на друг екип. Ако не сте заключили компонентната си версия, вашият CI / CD може да се провали поради промяна на компонент от друг екип - това е ужасно усещане и това води до много екипи, които заключват компоненти до много специфична версия, където може дори да не вземат нови версии на кръпките.

Тук CI / CD влиза в игра. Когато версия на компонент е актуализирана, автоматизацията трябва да провери дали тя нарушава някои консумиращи приложения в тази основна версия - тя трябва да провери това, дори ако приложението заключва своите версии на компонентите. Ако няма прекъсване, искаме системата CI / CD да изпрати PR заявка, която актуализира заключената версия до новата, която не е нарушила приложението. Ако има почивка, и двата екипа трябва да бъдат уведомени, за да говорят какъв е проблемът.

Innersource

Основата на нашия подход към повторната употреба е прегръщането ни на философията с отворен код / ​​вътрешен източник, както е описано от Лоран Десегур в предишен пост. @WalmartLabs от години е потребител и допринася за отворен код, както демонстрират проекти като Hapi, OneOps и Electrode. По-малко очевидно отвън е нашата ангажираност към вътрешния източник, който е вътрешното приложение на модела с отворен код. При подхода на вътрешния източник никой екип или разработчик не притежава компонент - всички компоненти се споделят в организацията. Това елиминира тесните места и дава възможност на разработчиците да подобрят съществуващите компоненти.

Тези политики значително увеличават възможностите за повторна употреба - но по-важното е, че те сигнализират на разработчиците ни за ангажираност като компания към философия на сътрудничество и сътрудничество. Те оправомощават разработчиците да използват своето време и опит там, където това е най-необходимо, вместо да чакат да се изчистят затрудненията и те ползват компанията по реални, измерими начини.

заключение

Повторното използване не е само техническо решение, но и философско, което изисква организационен ангажимент и има далечни последици. В @WalmartLabs видяхме ползите, които може да донесе - в момента преместваме SamsClub.com към платформата Electrode, а нашите разработчици използват повторно стотици компоненти от Walmart.com с тях, за да съответстват на марката на Sam's Club.

Разкажете ни историята си за многократна употреба - с какви пречки сте се сблъскали? Как ги решихте? Какви възможности за по-нататъшно усъвършенстване виждате?