Ontwerpsysteemcomponenten afschaffen zonder productteams te breken
Hoe u baanbrekende ontwerpsysteemwijzigingen in grote apps kunt implementeren: aankondigen, afschaffen, migreren met codemods en verwijderen, met behulp van semantisch versiebeheer en gebruiksregistratie.
Kern afhaalmaaltijd
Een component buiten gebruik stellen in vier stappen: kondig de wijziging aan met de reden en de vervanging, markeer de oude component als verouderd in een kleine release met duidelijke waarschuwingen, help teams te migreren met handleidingen en geautomatiseerde codemods, en verwijder deze pas in de volgende grote release. Houd bij elke stap bij hoeveel schermen er nog steeds gebruik van maken en verwijder het pas als het gebruik bijna nul is.
Waarom afschrijving misgaat
Veranderingen in het ontwerpsysteem mislukken wanneer ze productteams verrassen: een component verdwijnt in een update, builds breken en teams houden de oude versie vast en stoppen met upgraden. Zodra dat gebeurt, verliest het systeem zijn belangrijkste voordeel: consistentie, omdat verschillende delen van het product naar verschillende versies overgaan.
Een proces in vier stappen
Semantisch versiebeheer biedt een eenvoudig contract: incompatibele wijzigingen worden doorgevoerd in een hoofdversie, en als u een deel van een API beëindigt, moet u de documentatie bijwerken en een kleine release verzenden met de afschaffing ervan, voordat u deze later verwijdert.
- Aankondigen: leg uit waarom, toon de vervanging, geef een tijdlijn.
- Afkeuren: markeer het in documenten en in code, met een console- of lintwaarschuwing die naar de handleiding linkt.
- Migreren: zorg voor een geschreven handleiding en, voor code, een codemod die het gebruik automatisch bijwerkt.
- Verwijderen: in de volgende grote release, zodra het gebruik bijna nul is.
Automatiseer de migratie
Codemods zijn scripts die code in een codebase herschrijven. Tools zoals jscodeshift voeren codemods uit over veel JavaScript- of TypeScript-bestanden tegelijk, zodat een prop-hernoeming of componentwissel binnen enkele minuten in plaats van weken kan worden toegepast. Koppel ze aan lintregels die het resterende gebruik markeren.
Meet de adoptie
U kunt geen verwijdering plannen zonder te weten wie een component nog gebruikt. Houd het gebruik bij in code (imports, lintwaarschuwingen) en in ontwerpbestanden (bibliotheekanalyses in uw ontwerptool). Publiceer de cijfers zodat teams de voortgang kunnen zien en help de laatste paar teams direct in plaats van een deadline te forceren.
Vergeet de designkant niet
Beëindig de component ook in de ontwerpbibliotheek: hernoem hem met het voorvoegsel 'Verouderd', link naar de vervanging en zorg ervoor dat deze niet meer in de zoekresultaten verschijnt. Anders blijven ontwerpers het gebruiken in nieuw werk en eindigt de migratie nooit. Bewegings- en interactiegedrag moeten deel uitmaken van de wijzigingsnotities, omdat een vervanging die anders beweegt, gebroken kan aanvoelen, zelfs als deze er hetzelfde uitziet.
Toets Principles in om te onthouden
- Aankondigen, afschaffen, migreren, verwijderen: ga nooit meteen over tot verwijdering
- Beëindigen in een kleine release; verwijderen in een grote release
- Gebruik codemods en lintregels om de migratie te automatiseren
- Volg het gebruik in zowel code- als ontwerpbestanden
- Neem bewegings- en interactiewijzigingen op in de release-opmerkingen
Veelgestelde vragen
Bronnen
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (meta)