Udfasning af designsystemkomponenter uden at bryde produktteams
Sådan udrulles bryder designsystemændringer i store apps: annoncerer, udfaser, migrerer med codemods og fjerner ved hjælp af semantisk versionering og brugssporing.
Core Takeaway
Træk en komponent tilbage i fire trin: Annoncer ændringen med årsagen og erstatningen, markér den gamle komponent forældet i en mindre udgivelse med klare advarsler, hjælp teams med at migrere med guider og automatiserede codemods, og fjern den kun i den næste større udgivelse. Spor, hvor mange skærme der stadig bruger det ved hvert trin, og fjern det ikke, før brugen er tæt på nul.
Hvorfor afskrivning går galt
Designsystemændringer mislykkes, når de overrasker produktteams: en komponent forsvinder i en opdatering, bygger pauser, og teams fastholder den gamle version og stopper med at opgradere. Når det sker, mister systemet sin vigtigste fordel, konsistens, fordi forskellige dele af produktet glider over i forskellige versioner.
En fire-trins proces
Semantisk versionering giver en simpel kontrakt: Inkompatible ændringer går i en større version, og når du forælder en del af en API, bør du opdatere dokumentationen og sende en mindre udgivelse med udfasningen på plads, før du fjerner den senere.
- Annoncer: forklar hvorfor, vis erstatningen, giv en tidslinje.
- Udgå: Marker det i dokumenter og i kode med en konsol- eller fnug-advarsel, der linker til vejledningen.
- Migrer: Giv en skriftlig vejledning og, for kode, en kodemod, der opdaterer brug automatisk.
- Fjern: i den næste større udgivelse, når brugen er tæt på nul.
Automatiser migreringen
Codemods er scripts, der omskriver kode på tværs af en kodebase. Værktøjer såsom jscodeshift kører codemods over mange JavaScript- eller TypeScript-filer på én gang, så en propomdøbning eller komponentbytning kan anvendes på få minutter i stedet for uger. Par dem med fnugregler, der markerer resterende brug.
Foranstaltningsvedtagelse
Du kan ikke planlægge fjernelse uden at vide, hvem der stadig bruger en komponent. Spor brug i kode (import, fnug-advarsler) og i designfiler (biblioteksanalyse i dit designværktøj). Offentliggør tallene, så hold kan se fremskridt, og hjælp de sidste par hold direkte i stedet for at tvinge en deadline.
Glem ikke designsiden
Afvis også komponenten i designbiblioteket: omdøb den med et "Forældet" præfiks, link til erstatningen, og stop den med at blive vist i søgning. Ellers bliver designere ved med at bruge det i nyt arbejde, og migreringen slutter aldrig. Bevægelses- og interaktionsadfærd bør være en del af forandringsnoterne, fordi en erstatning, der bevæger sig anderledes, kan føles ødelagt, selvom den ser ens ud.
Tast Principles for at huske
- Annoncer, afskriv, migrér, fjern: Spring aldrig direkte til fjernelse
- Afvise i en mindre udgivelse; fjernes i en større udgivelse
- Brug codemods og lint-regler til at automatisere migrering
- Spor brug i både kode og designfiler
- Inkluder bevægelses- og interaktionsændringer i udgivelsesnoter
Ofte stillede spørgsmål
Kilder
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)