Wycofywanie komponentów systemu projektowego bez przerywania pracy zespołów produktowych
Jak wdrożyć przełomowe zmiany w systemie projektowania w dużych aplikacjach: ogłaszać, wycofywać, migrować za pomocą modów kodów i usuwać, korzystając z wersjonowania semantycznego i śledzenia użycia.
Rdzeń na wynos
Wycofaj komponent w czterech krokach: ogłoś zmianę, podając przyczynę i zamiennik, oznacz stary komponent jako przestarzały w wersji pomocniczej jasnymi ostrzeżeniami, pomóż zespołom w migracji za pomocą przewodników i automatycznych modów kodów oraz usuń go dopiero w następnej wersji głównej. Na każdym kroku śledź, na ilu ekranach nadal z niego korzystasz, i nie usuwaj go, dopóki użycie nie będzie bliskie zeru.
Dlaczego amortyzacja idzie źle
Zmiany w systemie projektowym kończą się niepowodzeniem, gdy zaskakują zespoły zajmujące się produktem: komponent znika w aktualizacji, kompilacja zostaje przerwana, a zespoły przypinają starą wersję i przestają aktualizować. Kiedy to nastąpi, system traci swoją główną zaletę, czyli spójność, ponieważ różne części produktu zmieniają się w różne wersje.
Proces czteroetapowy
Wersjonowanie semantyczne zapewnia prostą umowę: niekompatybilne zmiany trafiają do wersji głównej, a kiedy zdezaktualizujesz część interfejsu API, powinieneś zaktualizować dokumentację i dostarczyć wersję pomocniczą z już wycofaną wersją, przed jej późniejszym usunięciem.
- Ogłoś: wyjaśnij dlaczego, pokaż zamiennik, podaj harmonogram.
- Przestarzałe: zaznacz to w dokumentach i kodzie za pomocą konsoli lub ostrzeżenia o lintach z linkiem do przewodnika.
- Migruj: zapewnij pisemny przewodnik i, w przypadku kodu, mod kodujący, który automatycznie aktualizuje użycie.
- Usuń: w następnej głównej wersji, gdy użycie będzie bliskie zeru.
Zautomatyzuj migrację
Codemods to skrypty, które przepisują kod w bazie kodu. Narzędzia takie jak jscodeshift uruchamiają codemods na wielu plikach JavaScript lub TypeScript jednocześnie, więc zmianę nazwy właściwości lub zamianę komponentów można zastosować w ciągu kilku minut, a nie tygodni. Połącz je z regułami lint, które oznaczają pozostałe użycia.
Przyjęcie środków
Nie możesz zaplanować usunięcia, nie wiedząc, kto nadal używa komponentu. Śledź użycie w kodzie (importy, ostrzeżenia o lintach) i plikach projektu (analiza biblioteczna w narzędziu do projektowania). Opublikuj liczby, aby zespoły mogły zobaczyć postępy i pomóż bezpośrednio kilku ostatnim zespołom, zamiast narzucać termin.
Nie zapomnij o stronie projektowej
Usuń także komponent z biblioteki projektu: zmień jego nazwę, dodając przedrostek „Przestarzałe”, podaj link do zamiennika i przestań pojawiać się w wyszukiwaniu. W przeciwnym razie projektanci będą nadal używać go w nowych pracach, a migracja nigdy się nie skończy. Ruch i zachowanie interakcji powinny być częścią notatek o zmianach, ponieważ zamiennik, który porusza się inaczej, może sprawiać wrażenie uszkodzonego, nawet jeśli wygląda tak samo.
Klucz Principles do zapamiętania
- Ogłaszaj, wycofuj, migruj, usuwaj: nigdy nie przechodź od razu do usuwania
- Przestarzałe w wersji pomocniczej; usunąć w wersji głównej
- Użyj modów kodowych i reguł lint, aby zautomatyzować migrację
- Śledź użycie zarówno w kodzie, jak i plikach projektu
- Uwzględnij zmiany dotyczące ruchu i interakcji w informacjach o wersji
Często zadawane pytania
Źródła
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (Meta)