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