Отхвърляне на компонентите на системата за проектиране без нарушаване на продуктовите екипи

Защо амортизацията се обърка

Промените в системата за проектиране се провалят, когато изненадват продуктовите екипи: компонент изчезва при актуализация, компилациите се прекъсват и екипите фиксират старата версия и спират надграждането. След като това се случи, системата губи основното си предимство, последователността, защото различни части на продукта преминават към различни версии.

Процес в четири стъпки

Семантичното управление на версиите дава прост договор: несъвместимите промени влизат в основна версия и когато отхвърлите част от API, трябва да актуализирате документацията и да изпратите второстепенна версия с оттеглянето на място, преди да го премахнете по-късно.

• Обявете: обяснете защо, покажете замяната, дайте график.
• Отхвърлено: маркирайте го в документи и в код, с предупреждение за конзола или мъх, което препраща към ръководството.
• Мигриране: осигурете писмено ръководство и, за код, codemod, който актуализира автоматично употребата.
• Премахване: в следващото основно издание, след като използването е почти нула.

Автоматизирайте миграцията

Codemods са скриптове, които пренаписват код в кодова база. Инструменти като jscodeshift изпълняват codemods върху много JavaScript или TypeScript файлове наведнъж, така че преименуване на проп или размяна на компоненти може да се приложи за минути вместо за седмици. Сдвоете ги с правила за мъх, които маркират оставащите употреби.

Измерете приемането

Не можете да планирате премахване, без да знаете кой все още използва компонент. Проследявайте употребата в код (импортиране, предупреждения за мъх) и в дизайнерски файлове (библиотечен анализ във вашия инструмент за проектиране). Публикувайте числата, така че екипите да могат да видят напредъка, и помогнете директно на последните няколко отбора, вместо да налагате краен срок.

Не забравяйте дизайнерската страна

Оттеглете компонента и в библиотеката за дизайн: преименувайте го с префикс „Отхвърлен“, свържете към замяната и спрете да се показва при търсене. В противен случай дизайнерите продължават да го използват в нова работа и миграцията никога не свършва. Движението и поведението на взаимодействие трябва да бъдат част от бележките за промяната, защото заместител, който се движи по различен начин, може да се почувства счупен, дори ако изглежда по същия начин.