Устаревшие компоненты системы дизайна без разрушения команды разработчиков
Как внедрить критические изменения в системе дизайна в крупных приложениях: объявлять, объявлять устаревшими, мигрировать с помощью модификаций кода и удалять, используя семантическое управление версиями и отслеживание использования.
Главное
Выведите компонент из эксплуатации за четыре шага: объявите об изменении с указанием причины и замены, отметьте старый компонент устаревшим в второстепенной версии с четкими предупреждениями, помогите командам выполнить миграцию с помощью руководств и автоматических модификаций кода и удалите его только в следующей основной версии. Отслеживайте, сколько экранов все еще используют его на каждом этапе, и не удаляйте его, пока использование не станет близким к нулю.
Почему устаревание идет не так
Изменения в системе дизайна терпят неудачу, когда они удивляют продуктовые команды: компонент исчезает при обновлении, сборки ломаются, и команды закрепляют старую версию и прекращают обновление. Как только это произойдет, система потеряет свое главное преимущество — согласованность, поскольку разные части продукта переходят в разные версии.
Четырехэтапный процесс
Семантическое управление версиями дает простой контракт: несовместимые изменения вносятся в основную версию, и когда вы объявляете устаревшей часть API, вам следует обновить документацию и выпустить второстепенную версию с установленной устаревшей версией, прежде чем удалять ее позже.
- Анонсируйте: объясните почему, покажите замену, назовите сроки.
- Устарело: отметьте это в документации и коде с помощью консоли или предупреждения, которое ссылается на руководство.
- Миграция: предоставьте письменное руководство и, для кода, модуль кода, который автоматически обновляет способы использования.
- Удалить: в следующем основном выпуске, когда использование будет близко к нулю.
Автоматизируйте миграцию
Codemods — это скрипты, которые переписывают код в базе кода. Такие инструменты, как jscodeshift, запускают кодовые моды для многих файлов JavaScript или TypeScript одновременно, поэтому переименование реквизита или замену компонентов можно применить за считанные минуты, а не недели. Соедините их с правилами проверки, которые отмечают оставшиеся случаи использования.
Измерение принятия
Вы не можете планировать удаление, не зная, кто по-прежнему использует компонент. Отслеживайте использование в коде (импорт, предупреждения о проверках) и в файлах дизайна (библиотечная аналитика в вашем инструменте дизайна). Публикуйте цифры, чтобы команды могли видеть прогресс, и помогайте последним нескольким командам напрямую, а не навязывайте сроки.
Не забывайте о дизайнерской стороне
Удалите также устаревший компонент в библиотеке дизайна: переименуйте его с префиксом «Устаревший», укажите ссылку на замену и запретите ему появляться в поиске. В противном случае дизайнеры будут продолжать использовать его в новых работах, и миграция никогда не закончится. Поведение движения и взаимодействия должно быть частью примечаний к изменениям, поскольку замена, которая движется по-другому, может показаться сломанной, даже если она выглядит так же.
Ключевые принципы
- Объявить, объявить устаревшим, перенести, удалить: никогда не переходить сразу к удалению
- Устарело в второстепенной версии; удалить в основной версии
- Используйте codemods и правила lint для автоматизации миграции.
- Отслеживайте использование как в файлах кода, так и в файлах дизайна.
- Включите изменения движения и взаимодействия в примечания к выпуску.
Частые вопросы
Источники
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (мета)