Utfasning av designsystemkomponenter utan att bryta produktteam
Så här rullar du ut brytande designsystemförändringar i stora appar: tillkännage, fasa ut, migrera med codemods och ta bort, med hjälp av semantisk versionshantering och användningsspårning.
Core Takeaway
Ta bort en komponent i fyra steg: tillkännage ändringen med anledningen och ersättningen, markera den gamla komponenten utfasad i en mindre version med tydliga varningar, hjälp team att migrera med guider och automatiserade codemods och ta bort den först i nästa större version. Spåra hur många skärmar som fortfarande använder den vid varje steg, och ta inte bort den förrän användningen är nära noll.
Varför avskrivning går fel
Designsystemändringar misslyckas när de överraskar produktteam: en komponent försvinner i en uppdatering, bygger paus och team fäster den gamla versionen och slutar uppgradera. När det väl händer förlorar systemet sin huvudsakliga fördel, konsistens, eftersom olika delar av produkten går över i olika versioner.
En process i fyra steg
Semantisk versionering ger ett enkelt kontrakt: inkompatibla ändringar går i en större version, och när du fasar ut en del av ett API bör du uppdatera dokumentationen och skicka en mindre version med utfasningen på plats, innan du tar bort den senare.
- Meddela: förklara varför, visa ersättaren, ge en tidslinje.
- Utfasas: markera det i dokument och kod, med en konsol- eller lintvarning som länkar till guiden.
- Migrera: tillhandahåll en skriftlig guide och, för kod, en codemod som uppdaterar användningar automatiskt.
- Ta bort: i nästa stora version, när användningen är nära noll.
Automatisera migreringen
Codemods är skript som skriver om kod över en kodbas. Verktyg som jscodeshift kör codemods över många JavaScript- eller TypeScript-filer samtidigt, så ett rekvisitbyte eller komponentbyte kan tillämpas på några minuter istället för veckor. Para ihop dem med luddregler som flaggar kvarvarande användningsområden.
Åtgärd antagande
Du kan inte planera borttagning utan att veta vem som fortfarande använder en komponent. Spåra användning i kod (import, luddvarningar) och i designfiler (biblioteksanalys i ditt designverktyg). Publicera siffrorna så att teamen kan se framstegen och hjälp de senaste teamen direkt istället för att tvinga fram en deadline.
Glöm inte designsidan
Utfasa komponenten i designbiblioteket också: byt namn på den med ett "Föråldrat" prefix, länka till ersättningen och sluta att den visas i sökningar. Annars fortsätter designers att använda det i nytt arbete och migreringen tar aldrig slut. Rörelse- och interaktionsbeteende bör vara en del av förändringsnoterna, eftersom en ersättare som rör sig annorlunda kan kännas trasig även om den ser likadan ut.
Nyckel Principles att komma ihåg
- Tillkännage, fasa ut, migrera, ta bort: hoppa aldrig direkt till borttagning
- Avskaffa i en mindre version; ta bort i en större release
- Använd codemods och lint-regler för att automatisera migreringen
- Spåra användning i både kod och designfiler
- Inkludera rörelse- och interaktionsändringar i releasenotes
Vanliga frågor
Källor
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)