Avveckling och utfasning av komponenter

När ett designsystem skalas blir vissa komponenter föråldrade, överflödiga eller ersatta av bättre versioner. Att behålla dem för alltid gör systemet onödigt stort.

Den här lektionen behandlar utfasning – hur komponenter tas ur bruk på ett smidigt sätt utan att konsumenter går sönder.

Radera aldrig en komponent utan förvarning för teamen. Utfasning är en process i flera steg: markera den, varna, visa en väg framåt och ta sedan bort den.

Ett plötsligt borttagande förstör byggen och förtroendet för systemet. Tålamod är hela poängen här.

Markera komponenten i kod och dokumentation så att användning av den visar en varning. Kodavsnittet visar en enkel wrapper för en varning vid körning.

Ett meddelande om utfasning måste besvara tre frågor: varför den tas bort, vad som ska användas i stället och när den tas bort.

Utan en tydlig ersättare kan teamen inte migrera och kommer helt enkelt att ignorera varningen.

Dokumentera före och efter bytet. Om API:erna skiljer sig åt ska du visa hur gamla props motsvarar de nya.

Codemods – automatiserade migreringsskript – kan skriva om användningar mekaniskt och undanröja nästan all migreringsfriktion i stora kodbaser.

Team har egna färdplaner. Ett borttagande som planeras till nästa vecka är fientligt; ett som ligger en eller flera majorversioner bort är rimligt.

Meddela utfasningen i en minorversion och ta bort den först i en framtida majorversion, i enlighet med semantisk versionshantering.

Mät hur många appar som fortfarande använder den föråldrade komponenten. Användningsanalys eller kodsökning visar den verkliga utvecklingen.

Ta inte bort komponenten förrän användningen närmar sig noll eller alla team har bekräftat migreringen. Data, inte antaganden, ska styra tidsplanen.

En enda rad i ändringsloggen räcker inte. Meddela i versionsanteckningar, teamkanaler och öppna frågestunder. Upprepa informationen när datumet för borttagandet närmar sig.

Människor missar meddelanden; det är mycket billigare att överkommunicera utfasningar än att överraska någon med ett trasigt bygge.

När användningen har upphört och tidsfristen har nåtts tar du bort komponenten i en majorversion. Dokumentera borttagandet tydligt i ändringsloggen.

Håll migreringsguiden tillgänglig även efteråt för eventuella eftersläntrare på gamla versioner.

En del svällning beror på att komponenter läggs till för ivrigt. En stark process för inkommande bidrag och viljan att säga nej håller systemet slimmat från början.

Utfasning städar upp; styrning förebygger röran.

Ett designsystem som aldrig tar bort något mognar inte – det samlar på sig skuld. Genomtänkt utfasning är ett tecken på ett sunt system i utveckling.

Gallra varsamt så förblir systemet skarpt när det skalas.

Du har lärt dig att fasa ut komponenter på ett smidigt sätt:

• Fasa ut i flera steg – radera aldrig plötsligt.
• Kommunicera varför, vad som ska användas och när, med en migreringsguide och codemods.
• Ge generösa tidsramar kopplade till majorversioner och följ hur ersättaren tas i bruk.
• Överkommunicera och ta bara bort komponenten när användningen har upphört.

Genomtänkt gallring håller ett växande designsystem slimmat och sunt.