Tervezőrendszer-összetevők elavultsága a termékcsapatok megszakítása nélkül
A tervezési rendszer törésszerű változásainak bevezetése nagy alkalmazásokban: bejelentés, elavulás, áttelepítés kódmodellekkel és eltávolítás a szemantikus verziószámmal és a használat követésével.
Core Takeaway
Az összetevők megszüntetése négy lépésben: jelentse be a változást az okokkal és a cserével, jelölje meg a régi összetevőt egy kisebb kiadásban elavultnak egyértelmű figyelmeztetésekkel, segítse a csapatokat az átállásban útmutatókkal és automatizált kódmódokkal, és csak a következő nagyobb kiadásban távolítsa el. Kövesse nyomon, hány képernyő használja még minden lépésnél, és ne távolítsa el, amíg a használat közel nem éri a nullát.
Miért megy rosszul a lejáratás?
A tervezési rendszermódosítások sikertelenek, ha meglepik a termékcsapatokat: egy komponens eltűnik a frissítés során, az összeállítás megszakad, a csapatok pedig rögzítik a régi verziót, és leállítják a frissítést. Ha ez megtörténik, a rendszer elveszíti fő előnyét, a konzisztenciát, mivel a termék különböző részei különböző verziókra sodródnak.
Négy lépésből álló folyamat
A szemantikus verziókezelés egyszerű szerződést ad: az inkompatibilis módosítások egy fő verzióban mennek végbe, és amikor egy API egy részét elavulttá teszi, frissítenie kell a dokumentációt, és el kell küldenie egy kisebb kiadást az elavulás helyén, mielőtt később eltávolítaná.
- Bejelentés: indokolja meg, miért, mutassa meg a cserét, adjon meg egy idővonalat.
- Elavult: jelölje meg a dokumentumokban és a kódban, konzollal vagy szöszfigyelmeztetéssel, amely az útmutatóra hivatkozik.
- Áttelepítés: adjon meg egy írásos útmutatót, és a kódhoz egy kódmódot, amely automatikusan frissíti a használatot.
- Eltávolítás: a következő nagyobb kiadásban, ha a használat közel nulla lesz.
Automatizálja a migrációt
A Codemod olyan szkriptek, amelyek átírják a kódot egy kódbázison keresztül. Az olyan eszközök, mint a jscodeshift, egyszerre több JavaScript vagy TypeScript fájlon futtatják a kódmódokat, így a kellékek átnevezése vagy komponenscseréje hetek helyett percek alatt alkalmazható. Párosítsa őket szöszszabályokkal, amelyek megjelölik a fennmaradó használatokat.
Intézkedések elfogadása
Nem tervezheti meg az eltávolítást anélkül, hogy tudná, ki használ még egy összetevőt. Kövesse nyomon a használatot kódban (importálás, szöszfigyelmeztetés) és tervezési fájlokban (könyvtárelemzés a tervezőeszközben). Tegye közzé a számokat, hogy a csapatok láthassák az előrehaladást, és közvetlenül segítse az utolsó néhány csapatot a határidők kikényszerítése helyett.
Ne felejtsd el a tervezési oldalt
Hagyja elavult az összetevőt a tervezési könyvtárban is: nevezze át "Elavult" előtaggal, hivatkozzon a cserére, és ne jelenjen meg a keresésben. Ellenkező esetben a tervezők folyamatosan használják az új munkákban, és a migráció soha nem ér véget. A mozgás és az interakciós viselkedés része kell, hogy legyen a változási jegyzeteknek, mert a másként mozgó csere akkor is töröttnek érezheti magát, ha ugyanúgy néz ki.
Kulcs Principle, amit meg kell jegyezni
- Bejelentés, hatályon kívül helyezés, áttelepítés, eltávolítás: soha ne ugorjon közvetlenül az eltávolításra
- Elavult egy kisebb kiadásban; távolítsa el egy nagyobb kiadásban
- Használjon kódmódokat és lint-szabályokat a migráció automatizálásához
- Kövesse nyomon a használatot mind a kódban, mind a tervezési fájlokban
- A mozgási és interakciós változásokat belefoglalhatja a kiadási megjegyzésekbe
Gyakran Ismételt Kérdések
Források
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)