Designsystemkomponenten verwerfen, ohne Produktteams zu zerstören
So führen Sie bahnbrechende Designsystemänderungen in großen Apps ein: Ankündigung, Veraltung, Migration mit Codemods und Entfernung mithilfe semantischer Versionierung und Nutzungsverfolgung.
Kernaussage
Nehmen Sie eine Komponente in vier Schritten außer Betrieb: Geben Sie die Änderung mit dem Grund und dem Ersatz an, kennzeichnen Sie die alte Komponente in einer Nebenversion mit klaren Warnungen als veraltet, unterstützen Sie Teams bei der Migration mit Anleitungen und automatisierten Codemods und entfernen Sie sie erst in der nächsten Hauptversion. Verfolgen Sie bei jedem Schritt, wie viele Bildschirme es noch nutzen, und entfernen Sie es erst, wenn die Nutzung nahezu Null ist.
Warum die Abwertung schief geht
Designsystemänderungen schlagen fehl, wenn sie Produktteams überraschen: Eine Komponente verschwindet in einem Update, Builds brechen ab und Teams fixieren die alte Version und beenden das Upgrade. Sobald dies geschieht, verliert das System seinen Hauptvorteil, die Konsistenz, da verschiedene Teile des Produkts auf unterschiedliche Versionen abdriften.
Ein vierstufiger Prozess
Durch die semantische Versionierung ergibt sich ein einfacher Vertrag: Inkompatible Änderungen werden in einer Hauptversion übernommen. Wenn Sie einen Teil einer API als veraltet bezeichnen, sollten Sie die Dokumentation aktualisieren und eine Nebenversion mit der veralteten Version ausliefern, bevor Sie diese später entfernen.
- Ankündigung: Erklären Sie, warum, zeigen Sie den Ersatz, geben Sie einen Zeitplan an.
- Veraltet: Markieren Sie es in Dokumenten und im Code mit einer Konsolen- oder Lint-Warnung, die auf die Anleitung verweist.
- Migrieren: Stellen Sie eine schriftliche Anleitung und für Code einen Codemod bereit, der die Verwendungen automatisch aktualisiert.
- Entfernen: in der nächsten Hauptversion, sobald die Nutzung nahezu Null ist.
Automatisieren Sie die Migration
Codemods sind Skripte, die Code in einer Codebasis neu schreiben. Tools wie jscodeshift führen Codemods über viele JavaScript- oder TypeScript-Dateien gleichzeitig aus, sodass eine Prop-Umbenennung oder ein Komponentenaustausch innerhalb von Minuten statt Wochen durchgeführt werden kann. Kombinieren Sie sie mit Lint-Regeln, die verbleibende Verwendungen kennzeichnen.
Maßnahmenakzeptanz
Sie können den Ausbau nicht planen, ohne zu wissen, wer eine Komponente noch nutzt. Verfolgen Sie die Nutzung im Code (Importe, Lint-Warnungen) und in Designdateien (Bibliotheksanalysen in Ihrem Design-Tool). Veröffentlichen Sie die Zahlen, damit die Teams den Fortschritt sehen können, und helfen Sie den letzten Teams direkt, anstatt eine Frist zu erzwingen.
Vergessen Sie nicht die Designseite
Verwerfen Sie die Komponente auch in der Designbibliothek: Benennen Sie sie mit dem Präfix „Veraltet“ um, verknüpfen Sie sie mit dem Ersatz und verhindern Sie, dass sie in der Suche angezeigt wird. Andernfalls verwenden Designer es weiterhin in neuen Arbeiten und die Migration endet nie. Bewegungs- und Interaktionsverhalten sollten Teil der Änderungsnotizen sein, da sich ein Ersatz, der sich anders bewegt, kaputt anfühlen kann, auch wenn er gleich aussieht.
Wichtige Prinzipien
- Ankündigen, verwerfen, migrieren, entfernen: Springen Sie niemals direkt zur Entfernung
- In einer Nebenversion veraltet; in einer Hauptversion entfernen
- Verwenden Sie Codemods und Lint-Regeln, um die Migration zu automatisieren
- Verfolgen Sie die Verwendung sowohl in Code- als auch in Designdateien
- Nehmen Sie Bewegungs- und Interaktionsänderungen in die Versionshinweise auf
Häufige Fragen
Quellen
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)