Disainisüsteemi loomine kolmeliikmelises meeskonnas

Kui olete kolmeliikmeline meeskond, kes haldab korraga mitut kliendiprojekti, muutub ebakonsistentsus teie kõige kallimaks probleemiks. Panime tähele sama mustri kordumist meie veebidisaini projektides GRADAX-is: nupp oli kujundatud erinevalt avalehel, hindade lehel ja juhtpaneelis. Iga kõrvalekalle maksis meile aega kvaliteedikontrollis, tõi kaasa visuaalseid vigu ja kahandas poliitset ilmet, mida kliendid ootasid. Midagi pidi muutuma.

Otsus investeerida disainisüsteemi ei olnud ajendatud ambitsioonist ega trendide jälitamisest. See oli ajendatud valust. Kulutasime umbes 30% igast uuest projektist komponentide taasloomisele, mis olid juba kuskil meie koodibaasis olemas. Disainisüsteem võimaldaks meil oma otsused üks kord kodifitseerida ja neid kõikjal uuesti kasutada, muutes korduva töö konkurentsieeliseks.

Aga disainisüsteemide kirjanduses domineerivad lood ettevõtetest, kus on pühendatud platvormimeeskondi kakskümmend või enam inseneri. Me vajame pragmaatilist lähenemist, mida saaks luua, hallata ja tegelikult kasutada kolmeliikmeline meeskond, ilma et funktsionaalsuse arendus peatuks. Järgnevalt on raamistik, millele jõudsime pärast kuueteistkümnekuulist iteratsiooni.

Igas disainisüsteemi õppeprogrammis öeldakse, et tuleb alustada tokenitest, ja sellel on hea põhjus. Disaintokenid on aatomväärtused, värvid, vahe, tüüpograafia skaalad, nurgaraadiused, millest kõik muu on ehitatud. Need on iga ühtse brändi identiteedi alus, tagades visuaalse konsistentsuse igas puutepunktis. Määrasime need CSS-i kohandatud omadustena ühes failis, kaardistatuna semantiliste nimedega nagu --color-primary, --color-muted-foreground ja --radius-lg. See tähendas, et iga komponent, mis viitab nendele tokenitele, kohanes automaatselt, kui muutsime alusväärtusi.

Väikese meeskonna peamine vaade on hoida tokenite komplekt range väiksena. Alustasime vähem kui neljakümne tokeniga, mis kandsid värve, vahe, tüpograafiat ja varje. Suured organisatsioonid võivad vajada sadu, aga leidsime, et kompaktne komplekt sundis konsistentsusele, mitte ei võimaldanud tuhandeid peeneid variatsioone. Kui arendaja otsib vaheväärtust ja tal on vaid kaheksa varianti, satub ta loomulikult õigele.

Kehtestasime varajase nimetuskonventsiooni, kus semantika oli prioriteet kirjeldava ees. Kasutasime --blue-600 või --spacing-16 asemel --color-primary ja --space-md. See eraldas kavatsuse rakendusest ja tegi tulevikus ümberehitused triviaalseks. Kui klient soovis nihkuda siniselt violetsile, muutsime kuus rida tokenifailis ja kogu süsteem uuendus.

Tokenite olemasolul pöördusime komponentide poole. Võtsime aluseks shadcn/ui, mis andis meile ilusti loodud, ligipääsetavad primitiivid, mis on ehitatud Radix UI-le. Mitte et ehitada kõike nullist, laiendasime neid primitiive oma tokenikihi ja projektipõhiste variantidega. Nupp näiteks päris shadcn-ilt ligipääsetavuse ja klaviatuurikäitlemise, kasutades samal ajal meie tokenipõhist värvipaletti ja vahe.

Meie komponendi arhitektuur järgib ranget hierarhiat. Alumisel tasemel asuvad UI-primitiivid, nupud, sisendväljad, märgid, vihjed, millel pole äriloogikat ja mis aktsepteerivad stiile propside ja className ühendamise kaudu cn() abifunktsiooni kaudu. Nende kohal asuvad koostatud komponendid, otsinguribad, andmetabeli tööriistaribad, statistika kaardid, mis kombineerivad mitu primitiivi korduvkasutatavateks musteriteks. Ülemisel tasemel asuvad lehekülje tasemel sektsioonid, mis on spetsiifilised ühele vaatele ja paiknevad kõrvuti lehega, mida nad kasutavad.

See kolmetasemeline mudel väldib kahte kõige levinumat disainisüsteemi ebaedu: liiga abstraktseid komponente, mis ei ole kasulikud, ja liiga konkreetseid komponente, mida ei saa korduvkasutada. Kui arendajal on vaja ehitada uus funktsionaalsus, koostab ta selle keskmisest tasemest. Kui keskmine tase ei paku vajalikku, koostab ta selle primitiividest ja kui see osutub korduvkasutatavaks, tõstab ta selle taseme.

Dokumentatsioon on koht, kuhu enamik väikeste meeskondade disainisüsteeme sureb. Meeskond loob ilusaid komponente, kuid ei dokumentiigi nende kasutamist, nii et uued kaastöötajad (või isegi algse autorid kolm kuud hiljem) leiavad uuesti välja juba olemasolevad mustrid. Lahendasime selle probleemi, muutes dokumentatsiooni arenduse kõrvalsaaduseks, mitte eraldi ülesandeks.

Iga komponendi faili lisame JSDoc bloki, mis kirjeldab selle eesmärki, propside liideset ja kasutusnäidet. Lisaks hoiame üleval elavat Storybook'i eksemplari, kus iga komponent renderdatakse isoleeritult koos oma variatsioonidega. Kriitiline reegel on see, et pull request'i ei liideta ilma vastava story'uta. See võib kõlada range, kuid võtab aega vähem kui viis minutit komponendi kohta ning säästab tunde tulevast segadust.

Hoiame ka kergekaalulist otsuste logi, lihtsat markdown-faili, mis salvestab põhjused, miks tegime kindlaid valikuid. Miks valisime baasraadiuseks 0.5rem? Miks kasutab meie primaarne värv oklch-tähistust hexi asemel? Need märkmed on hindamatu väärtusega otsuste läbi mõtlemisel poolteist aastat hiljem ning aitavad kaasata vabakutselisi või lepingulisi töötajaid, kes liituvad ajutiselt.

Funktsionaalsed testid näitavad, kas nupp käivitab oma onClick-haneri. Visuaalsed regressioonitestid näitavad, kas see ikka õigesti välja näeb. Disainisüsteemi puhul on viimane sama oluline kui esimene. Integreerisime Playwright'i screenshot-võrdlused oma CI pipeline'i, nii et igal pull request'il genereeritakse visual diff mõjutatud komponentide jaoks.

Seadistus oli lihtsam, kui ootasime. Iga Storybook'i story saabub samal ajal ka visuaalse testjuhtumina. Meie CI töö käivitab headless brauseri, teeb screenshotsid igast story'st ja võrdleb neid commititud baaslinnustega. Kui komponendi välimus muutub, isegi ühe piksli võrra, märgitakse PR ülevaatamiseks. See tabas kümneid peenikesi regressioone, mis oleksid tootmisse jõudnud märkamata, nagu piiri värvi muutumine, sest keegi uuendas tokenit, teadmata selle allaheluvat mõju.

Käivitame visuaalseid teste nii heledas kui ka tumedas režiimis. Kuna meie tokenid määratlevad eraldiseisvad väärtused mõlema režiimi jaoks, võib heledas režiimis korras olev muutus täielikult rikkuda tumeda režiimi. Automaatsed screenshotsid mõlemas režiimis elimineerisid kogu veaklassi, mis varem tootmisse jõudis.

Pärast kuuekuulist kasutust üle kümnese kliendiprojekti oli meie disainisüsteem kasvanud neljakümnest tokenist ja kahekümnest komponendist ligikaudu kaheksakümne tokenini ja neljakümne viiele komponendile. Küsimus ei olnud enam selles, kas skaleerida, vaid kuidas skaleerida, säilitamata lihtsust, mis tegi süsteemi esialgu väärtuslikuks.

Sellesime sisestamise kontrollnimekirja, mida iga uus komponent peab läbima enne raamatukoguga liitumist: see peab kasutama ainult olemasolevaid tokeneid, olema koheselt ligipääsetav, sisaldama vähemalt ühte Storybook'i lugu ja toimima nii heledas kui ka tumedas režiimis. Komponendid, mis ei vasta ühelegi kriteeriumile, jäävad projektipõhisesse koodibaasi, kuni nad on piisavalt tugevdatud. See hoiab jagatud raamatukogu usaldusväärne.

Alustasime ka süsteemi versioonide haldamist semantiliste väljalasetega. Tokeni või komponendi propi murdvad muutused ilmnevad major versiooninumbrina, nii et projektid, mis on lukustatud vanemale versioonile, ei katke ootamatult. See oli algselt üleliigne kolmeliikmelise meeskonna jaoks, kuid tasus end ära, kui hakkasime süsteemi jagama vabakutseliste koostööpartneritega ja pühendatud arendusmeeskondadega, kes vajavad stabiilsuse garantiisid.

Ainsaim kõige olulisem õppetund on see, et disainisüsteem ei pea olema hiiglaslik, et olla väärtuslik. Meie süsteem on ettevõtete standardite järgi väike, kuid see säästab meil hinnanguliselt kümme tundi projekti kohta vähenenud duplitseerimise, vähemate visuaalsete vigade ja kiirema sisselõikumise tõttu. Kolmeliikmelisele meeskonnale, kes arveldab projekti lõikes, tõlgenduvad need tunnid otse kasumlikkuseni.

Teine õppetund on optimeerida adopteerimise, mitte täielikkuse nimel. Disainisüsteem, mida teie meeskond ei kasuta, on halvem kui üldse mitte mingi disainisüsteem, sest see loob konsistentsuse illusiooni, samal ajal kui koodibaas hajub. Iga meie tehtud otsus, shadcn/ui baasena kasutamisest Storybook'i lugude kohustuslikkuseni, oli suunatud sellele, et süsteemist saaks vähima takistusega tee, mitte lisakoormus.

Lõpuks käsitlege oma disainisüsteemi tootena, millel on oma roadmap, isegi kui ainuke kasutaja on teie enda meeskond. Prioriseerige komponendid ja tokenid, mis elimineerivad enim duplitseerimist. Jälgi, milliseid komponente kasutatakse enim, ja investeerige nende kvaliteeti. Disainisüsteem ei ole kunagi valmis, kuid õigete prioriteetidega suudab isegi väike meeskond hoida üht, mis lööb oma kaalu juures palju kõrgemat klassi. Kui kaalute disainisüsteemi loomist oma toote jaoks ja soovite juhiseid, kust alustada, võtke meiega ühendust, oleme protsessi läbinud ja saame aidata teil vältida kõige levinumaid trappe.