Udfasning og pensionering af komponenter

Efterhånden som et designsystem skalerer, bliver nogle komponenter forældede, overflødige eller erstattet af bedre versioner. Hvis du beholder dem for evigt, gør de systemet unødigt stort.

Denne lektion handler om udfasning – om at pensionere komponenter på en ordentlig måde uden at ødelægge dem, der bruger dem.

Slet aldrig en komponent uden videre, mens hold stadig bruger den. Udfasning er en proces i flere trin: markér den, advar, tilbyd en vej videre, og fjern den derefter.

En pludselig fjernelse ødelægger builds og tilliden til systemet. Tålmodighed er afgørende her.

Markér komponenten i koden og dokumentationen, så brugen af den udløser en advarsel. Uddraget viser en enkel wrapper, der udsender en advarsel under kørsel.

En udfasningsmeddelelse skal besvare tre spørgsmål: hvorfor den forsvinder, hvad der skal bruges i stedet, og hvornår den fjernes.

Uden en tydelig erstatning kan hold ikke migrere og vil blot ignorere advarslen.

Dokumentér før og efter udskiftningen. Når API'erne er forskellige, skal du vise, hvordan de gamle egenskaber svarer til de nye.

Codemods – automatiserede migreringsscripts – kan omskrive brugen mekanisk og fjerne næsten alle migreringsproblemer i store kodebaser.

Hold har deres egne køreplaner. En fjernelse, der er planlagt til næste uge, er fjendtlig; en fjernelse, der ligger en eller flere hovedversioner ude i fremtiden, er rimelig.

Annoncér udfasningen i en mindre version, og fjern den først i en senere hovedversion i overensstemmelse med semantisk versionsstyring.

Mål, hvor mange apps der stadig bruger den udfasede komponent. Brugsanalyse eller kodesøgning viser den faktiske fremgang.

Fjern den ikke, før brugen nærmer sig nul, eller alle hold har bekræftet migreringen. Tidsplanen skal styres af data, ikke antagelser.

Én linje i ændringsloggen er ikke nok. Annoncér det i versionsnoter, holdkanaler og ved åbne træffetider. Gentag det, når datoen for fjernelsen nærmer sig.

Folk overser beskeder; det er langt billigere at kommunikere for meget om udfasninger end at håndtere et build, der pludselig er gået i stykker.

Når brugen er ophørt, og fristen er nået, skal du fjerne komponenten i en hovedversion. Beskriv tydeligt fjernelsen i ændringsloggen.

Lad migreringsvejledningen være tilgængelig bagefter for dem, der stadig bruger gamle versioner.

En del overflod skyldes, at man tilføjer komponenter for hurtigt. En stærk modtagelsesproces og viljen til at sige nej holder systemet slankt fra begyndelsen.

Udfasning rydder op; styring forebygger rodet.

Et designsystem, der aldrig fjerner noget, modnes ikke – det ophober gæld. Gennemtænkt udfasning er et tegn på et sundt system i udvikling.

Beskær med omtanke, så forbliver systemet skarpt, mens det skalerer.

Du har lært at udfase komponenter på en ordentlig måde:

• Udfas i flere trin – slet aldrig pludseligt.
• Forklar hvorfor, hvad der skal bruges, og hvornår, med en migreringsvejledning og codemods.
• Giv generøse tidsrammer knyttet til hovedversioner, og følg udbredelsen.
• Kommunikér for meget hellere end for lidt, og fjern først komponenten, når den ikke længere bruges.

Gennemtænkt beskæring holder et skalerende designsystem slankt og sundt.