Deprecierea componentelor sistemului de proiectare fără a rupe echipele de produse
Cum să implementați modificări ale sistemului de design în aplicații mari: anunțați, depreciați, migrați cu codemod-uri și eliminați, folosind versiunea semantică și urmărirea utilizării.
Core Takeaway
Retrageți o componentă în patru pași: anunțați schimbarea cu motivul și înlocuirea, marcați componenta veche ca fiind depreciată într-o versiune minoră cu avertismente clare, ajutați echipele să migreze cu ghiduri și module de codare automate și eliminați-o doar în următoarea versiune majoră. Urmăriți câte ecrane încă îl folosesc la fiecare pas și nu îl eliminați până când utilizarea este aproape de zero.
De ce deprecierea merge prost
Modificările sistemului de proiectare eșuează atunci când surprind echipele de produs: o componentă dispare într-o actualizare, se întrerupe construcția, iar echipele fixează versiunea veche și opresc actualizarea. Odată ce se întâmplă acest lucru, sistemul își pierde principalul beneficiu, consistența, deoarece diferite părți ale produsului se deplasează pe versiuni diferite.
Un proces în patru etape
Versiunile semantice oferă un contract simplu: modificările incompatibile apar într-o versiune majoră, iar atunci când renunțați la o parte a unui API, ar trebui să actualizați documentația și să trimiteți o versiune minoră cu deprecierea în vigoare, înainte de a o elimina mai târziu.
- Anunțați: explicați de ce, arătați înlocuitorul, oferiți o cronologie.
- Depreciere: marcați-l în documente și în cod, cu un avertisment de consolă sau scame care trimite la ghid.
- Migrare: furnizați un ghid scris și, pentru cod, un codemod care actualizează automat utilizările.
- Eliminați: în următoarea versiune majoră, odată ce utilizarea este aproape de zero.
Automatizați migrarea
Codemod-urile sunt scripturi care rescriu codul într-o bază de cod. Instrumente precum jscodeshift rulează codemod-uri peste mai multe fișiere JavaScript sau TypeScript simultan, astfel încât o redenumire a elementelor sau o schimbare a componentelor pot fi aplicate în câteva minute în loc de săptămâni. Asociați-le cu reguli de scame care semnalează utilizările rămase.
Măsura adoptarea
Nu puteți planifica eliminarea fără a ști cine mai folosește o componentă. Urmăriți utilizarea în cod (importuri, avertismente privind scame) și în fișierele de proiectare (analitica bibliotecii în instrumentul dvs. de proiectare). Publicați numerele astfel încât echipele să poată vedea progresul și ajutați ultimele echipe direct, în loc să forțați un termen limită.
Nu uitați de partea de design
Depreciați componenta și în biblioteca de design: redenumiți-o cu un prefix „Depreciat”, conectați la înlocuitor și opriți-l să apară în căutare. În caz contrar, designerii îl folosesc în continuare în lucrări noi, iar migrarea nu se termină niciodată. Mișcarea și comportamentul de interacțiune ar trebui să facă parte din notele de modificare, deoarece un înlocuitor care se mișcă diferit se poate simți rupt chiar dacă arată la fel.
Cheie Principles de reținut
- Anunțați, depreciați, migrați, eliminați: nu treceți niciodată direct la eliminare
- Depreciere într-o versiune minoră; elimina într-o versiune majoră
- Utilizați codemods și reguli lint pentru a automatiza migrarea
- Urmăriți utilizarea atât în fișierele de cod, cât și de proiectare
- Includeți modificările de mișcare și interacțiune în notele de lansare
Întrebări frecvente
Surse
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)