Deprecare i componenti del sistema di progettazione senza interrompere i team di prodotto
Come implementare modifiche rivoluzionarie al sistema di progettazione in app di grandi dimensioni: annunciare, deprecare, migrare con codemod e rimuovere, utilizzando il controllo delle versioni semantico e il monitoraggio dell'utilizzo.
Punto chiave
Ritirare un componente in quattro passaggi: annunciare la modifica con il motivo e la sostituzione, contrassegnare il vecchio componente come deprecato in una versione minore con avvisi chiari, aiutare i team a migrare con guide e codemod automatizzate e rimuoverlo solo nella successiva versione principale. Tieni traccia di quanti schermi lo utilizzano ancora in ogni passaggio e non rimuoverlo finché l'utilizzo non è vicino allo zero.
Perché la deprecazione va storta
Le modifiche al sistema di progettazione falliscono quando sorprendono i team di prodotto: un componente scompare in un aggiornamento, le build si interrompono e i team bloccano la vecchia versione e interrompono l'aggiornamento. Una volta che ciò accade, il sistema perde il suo vantaggio principale, la coerenza, perché parti diverse del prodotto si spostano su versioni diverse.
Un processo in quattro fasi
Il controllo delle versioni semantico fornisce un contratto semplice: le modifiche incompatibili vanno in una versione principale e quando si depreca parte di un'API è necessario aggiornare la documentazione e fornire una versione minore con la deprecazione in atto, prima di rimuoverla in seguito.
- Annunciare: spiegare perché, mostrare la sostituzione, fornire una sequenza temporale.
- Deprecato: contrassegnalo nei documenti e nel codice, con un avviso di console o di lanugine che si collega alla guida.
- Migrazione: fornire una guida scritta e, per il codice, un codemod che aggiorna automaticamente gli utilizzi.
- Rimuovi: nella prossima versione principale, una volta che l'utilizzo è vicino allo zero.
Automatizza la migrazione
I codemod sono script che riscrivono il codice su una codebase. Strumenti come jscodeshift eseguono codemod su molti file JavaScript o TypeScript contemporaneamente, quindi è possibile applicare una ridenominazione dell'elica o uno scambio di componenti in pochi minuti anziché in settimane. Abbinateli a regole di lanugine che segnalano gli utilizzi rimanenti.
Misurare l'adozione
Non è possibile pianificare la rimozione senza sapere chi utilizza ancora un componente. Tieni traccia dell'utilizzo nel codice (importazioni, avvisi di lanugine) e nei file di progettazione (analisi della libreria nel tuo strumento di progettazione). Pubblica i numeri in modo che i team possano vedere i progressi e aiuta direttamente gli ultimi team invece di forzare una scadenza.
Non dimenticare il lato del design
Deprecato il componente anche nella libreria di progettazione: rinominalo con il prefisso "Deprecato", collegalo alla sostituzione e interrompi la sua visualizzazione nella ricerca. Altrimenti i designer continueranno a usarlo in nuovi lavori e la migrazione non finirà mai. Il comportamento di movimento e interazione dovrebbe far parte delle note di modifica, perché una sostituzione che si muove in modo diverso può sembrare rotta anche se sembra la stessa.
Principi chiave da ricordare
- Annunciare, deprecare, migrare, rimuovere: non passare mai direttamente alla rimozione
- Deprecato in una versione minore; rimuovere in una versione principale
- Utilizza codemod e regole lint per automatizzare la migrazione
- Tieni traccia dell'utilizzo nei file di codice e di progettazione
- Includere modifiche al movimento e all'interazione nelle note di rilascio
Domande frequenti
Fonti
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)