Suunnittelujärjestelmän komponenttien poistaminen rikkomatta tuoteryhmiä
Suunnittelujärjestelmän murtuvien muutosten käyttöönotto suurissa sovelluksissa: ilmoita, poista käytöstä, siirrä koodimodien avulla ja poista käyttämällä semanttista versiointia ja käytön seurantaa.
Core Takeaway
Poista komponentti käytöstä neljässä vaiheessa: ilmoita muutoksesta syyn ja vaihdon yhteydessä, merkitse vanha komponentti vanhentuneeksi pienessä versiossa selkein varoin, auta tiimejä siirtymään oppaiden ja automaattisten koodimodujen avulla ja poista se vasta seuraavassa suuressa julkaisussa. Seuraa kuinka monta näyttöä sitä edelleen käyttää joka vaiheessa, äläkä poista sitä ennen kuin käyttö on lähellä nollaa.
Miksi hylkääminen menee pieleen
Suunnittelujärjestelmän muutokset epäonnistuvat, kun ne yllättävät tuotetiimit: komponentti katoaa päivityksessä, rakennuskatko ja tiimit kiinnittävät vanhan version ja lopettavat päivityksen. Kun näin tapahtuu, järjestelmä menettää päähyötynsä, johdonmukaisuuden, koska tuotteen eri osat ajautuvat eri versioihin.
Nelivaiheinen prosessi
Semanttinen versiointi antaa yksinkertaisen sopimuksen: yhteensopimattomat muutokset menevät pääversioon, ja kun poistat osan API:sta, sinun tulee päivittää dokumentaatio ja lähettää pieni julkaisu, jossa poisto on paikallaan, ennen kuin poistat sen myöhemmin.
- Ilmoita: selitä miksi, näytä korvaava, anna aikajana.
- Poista käytöstä: merkitse se asiakirjoihin ja koodiin konsoli- tai nukkavaroituksella, joka linkittää oppaaseen.
- Siirrä: anna kirjallinen opas ja koodille koodimodi, joka päivittää käytöt automaattisesti.
- Poista: seuraavassa suuressa julkaisussa, kun käyttö on lähellä nollaa.
Automatisoi siirto
Codemodit ovat skriptejä, jotka kirjoittavat koodia uudelleen koodikannan yli. Työkalut, kuten jscodeshift, suorittavat koodimodit useissa JavaScript- tai TypeScript-tiedostoissa kerralla, joten ehdotuksen uudelleennimeäminen tai komponenttien vaihto voidaan suorittaa muutamassa minuutissa viikkojen sijaan. Yhdistä ne nukkasääntöjen kanssa, jotka ilmoittavat jäljellä olevat käyttötavat.
Toimenpiteen hyväksyminen
Et voi suunnitella poistoa tietämättä, kuka edelleen käyttää komponenttia. Seuraa käyttöä koodissa (tuonnit, nukkavaroitukset) ja suunnittelutiedostoissa (kirjaston analytiikka suunnittelutyökalussasi). Julkaise numerot, jotta tiimit näkevät edistymisen, ja auta muutamaa viimeistä joukkuetta suoraan sen sijaan, että pakottaisit määräajan.
Älä unohda suunnittelupuolta
Poista käytöstä myös suunnittelukirjaston komponentti: nimeä se uudelleen "Vähentynyt"-etuliitteellä, linkitä korvaavaan komponenttiin ja lopeta sen näkyminen haussa. Muuten suunnittelijat käyttävät sitä jatkuvasti uusissa töissä, eikä migraatio lopu koskaan. Liike- ja vuorovaikutuskäyttäytymisen tulisi olla osa muutosmuistiinpanoja, koska eri tavalla liikkuva tilalle voi tuntua rikki, vaikka se näyttää samalta.
Avain Principles muistettavat
- Ilmoita, poista käytöstä, siirrä, poista: älä koskaan siirry suoraan poistoon
- Poista käytöstä pienessä julkaisussa; poistaa suuressa julkaisussa
- Käytä codemodeja ja lint-sääntöjä automatisoidaksesi siirron
- Seuraa käyttöä sekä koodi- että suunnittelutiedostoissa
- Sisällytä liikkeen ja vuorovaikutuksen muutokset julkaisutietoihin
Usein kysytyt kysymykset
Lähteet
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)