Avvikle designsystemkomponenter uten å bryte produktteam
Slik ruller du ut banebrytende designsystemendringer i store apper: kunngjør, avvikle, migrér med kodemods og fjern, ved hjelp av semantisk versjonering og brukssporing.
Kjerne takeaway
Trekk tilbake en komponent i fire trinn: kunngjør endringen med årsaken og erstatningen, merk den gamle komponenten som er avviklet i en mindre utgivelse med klare advarsler, hjelp teamene med å migrere med guider og automatiserte kodemods, og fjern den bare i neste større utgivelse. Spor hvor mange skjermer som fortsatt bruker den ved hvert trinn, og ikke fjern den før bruken er nær null.
Hvorfor avskrivning går galt
Designsystemendringer mislykkes når de overrasker produktteam: en komponent forsvinner i en oppdatering, bygger bryter, og team fester den gamle versjonen og slutter å oppgradere. Når det skjer, mister systemet sin viktigste fordel, konsistensen, fordi ulike deler av produktet går over i forskjellige versjoner.
En fire-trinns prosess
Semantisk versjonering gir en enkel kontrakt: inkompatible endringer går i en hovedversjon, og når du avskriver en del av en API bør du oppdatere dokumentasjonen og sende en mindre utgivelse med avviklingen på plass, før du fjerner den senere.
- Kunngjør: forklar hvorfor, vis erstatningen, gi en tidslinje.
- Utfase: merk det i dokumenter og i kode, med en konsoll- eller loadvarsel som kobler til veiledningen.
- Migrer: gi en skriftlig veiledning og, for kode, en kodemod som oppdaterer bruk automatisk.
- Fjern: i neste store utgivelse, når bruken er nær null.
Automatiser migreringen
Codemods er skript som omskriver kode på tvers av en kodebase. Verktøy som jscodeshift kjører codemods over mange JavaScript- eller TypeScript-filer samtidig, slik at et nytt navn på propeller eller komponentbytte kan brukes på minutter i stedet for uker. Par dem med loregler som flagger gjenværende bruk.
Tiltaksadopsjon
Du kan ikke planlegge fjerning uten å vite hvem som fortsatt bruker en komponent. Spor bruk i kode (import, loadvarsler) og i designfiler (biblioteksanalyse i designverktøyet ditt). Publiser tallene slik at lagene kan se fremgang, og hjelp de siste lagene direkte i stedet for å tvinge en frist.
Ikke glem designsiden
Avvis komponenten i designbiblioteket også: gi den nytt navn med et "Utviklet" prefiks, lenk til erstatningen og stopp den å vises i søk. Ellers fortsetter designere å bruke det i nytt arbeid, og migreringen tar aldri slutt. Bevegelse og interaksjonsatferd bør være en del av endringsnotatene, fordi en erstatning som beveger seg annerledes kan føles ødelagt selv om den ser lik ut.
Tast Principles å huske
- Kunngjør, avskriv, migrér, fjern: aldri hopp rett til fjerning
- Avskrive i en mindre utgivelse; fjerne i en større utgivelse
- Bruk codemods og lint-regler for å automatisere migrering
- Spor bruk i både kode og designfiler
- Inkluder endringer i bevegelse og interaksjon i utgivelsesnotater
Ofte stilte spørsmål
Kilder
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)