Déprécier les composants du système de conception sans rompre les équipes produit
Comment déployer des modifications majeures du système de conception dans les grandes applications : annoncer, déprécier, migrer avec des codemods et supprimer, à l'aide du contrôle de version sémantique et du suivi de l'utilisation.
À retenir
Retirez un composant en quatre étapes : annoncez le changement avec la raison et le remplacement, marquez l'ancien composant comme obsolète dans une version mineure avec des avertissements clairs, aidez les équipes à migrer avec des guides et des codemods automatisés, et supprimez-le uniquement dans la prochaine version majeure. Suivez le nombre d'écrans qui l'utilisent encore à chaque étape et ne le supprimez pas tant que son utilisation n'est pas proche de zéro.
Pourquoi la dépréciation tourne mal
Les modifications du système de conception échouent lorsqu'elles surprennent les équipes produit : un composant disparaît dans une mise à jour, les builds s'interrompent et les équipes épinglent l'ancienne version et arrêtent la mise à niveau. Une fois que cela se produit, le système perd son principal avantage, la cohérence, car différentes parties du produit dérivent vers des versions différentes.
Un processus en quatre étapes
Le versioning sémantique donne un contrat simple : les modifications incompatibles sont transférées dans une version majeure, et lorsque vous dépréciez une partie d'une API, vous devez mettre à jour la documentation et expédier une version mineure avec la dépréciation en place, avant de la supprimer ultérieurement.
- Annoncer : expliquer pourquoi, montrer le remplaçant, donner un calendrier.
- Obsolète : marquez-le dans la documentation et dans le code, avec un avertissement de console ou de charpie qui renvoie au guide.
- Migrer : fournir un guide écrit et, pour le code, un codemod qui met automatiquement à jour les usages.
- Supprimer : dans la prochaine version majeure, une fois que l'utilisation est proche de zéro.
Automatisez la migration
Les Codemods sont des scripts qui réécrivent le code sur une base de code. Des outils tels que jscodeshift exécutent des codemods sur plusieurs fichiers JavaScript ou TypeScript à la fois, de sorte qu'un changement de nom d'accessoire ou un échange de composants peut être appliqué en quelques minutes au lieu de semaines. Associez-les à des règles de charpie qui signalent les utilisations restantes.
Mesurer l’adoption
Vous ne pouvez pas planifier une suppression sans savoir qui utilise encore un composant. Suivez l'utilisation dans le code (importations, avertissements de charpie) et dans les fichiers de conception (analyses de bibliothèque dans votre outil de conception). Publiez les chiffres afin que les équipes puissent voir les progrès et aidez directement les dernières équipes plutôt que de forcer une date limite.
N'oubliez pas le côté design
Dépréciez également le composant dans la bibliothèque de conception : renommez-le avec un préfixe "Obsolète", créez un lien vers le remplacement et empêchez-le d'apparaître dans la recherche. Sinon, les concepteurs continuent de l'utiliser dans de nouveaux travaux et la migration ne se termine jamais. Le comportement de mouvement et d'interaction doit faire partie des notes de modification, car un remplacement qui se déplace différemment peut sembler cassé même s'il semble identique.
Principes clés à retenir
- Annoncer, déprécier, migrer, supprimer : ne passez jamais directement à la suppression
- Déprécié dans une version mineure ; supprimer dans une version majeure
- Utilisez des codemods et des règles de charpie pour automatiser la migration
- Suivez l'utilisation dans les fichiers de code et de conception
- Inclure les modifications de mouvement et d'interaction dans les notes de version
Questions fréquentes
Sources
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (méta)