製品チームを分断せずに設計システムコンポーネントを非推奨にする

なぜ非推奨がうまくいかないのか

設計システムの変更は、製品チームを驚かせると失敗します。アップデートでコンポーネントが消え、ビルドが中断され、チームは古いバージョンを固定してアップグレードを停止します。それが起こると、製品の異なる部分が異なるバージョンに移行するため、システムの主な利点である一貫性が失われます。

4 段階のプロセス

セマンティック バージョニングは単純な契約を提供します。互換性のない変更はメジャー バージョンに組み込まれ、API の一部を非推奨にする場合は、後で削除する前にドキュメントを更新し、非推奨を適用したマイナー リリースを出荷する必要があります。

• 発表: 理由を説明し、代わりのものを示し、スケジュールを示します。
• 非推奨: ガイドにリンクするコンソールまたは lint 警告を使用して、ドキュメントおよびコード内で非推奨としてマークします。
• 移行: 文書によるガイドと、コードの場合は使用方法を自動的に更新する codemod を提供します。
• 削除: 次のメジャー リリースでは、使用量がゼロに近くなったら削除します。

移行を自動化する

Codemod は、コードベース全体でコードを書き換えるスクリプトです。 jscodeshift などのツールは、多くの JavaScript または TypeScript ファイルに対して codemod を一度に実行するため、プロパティの名前変更やコンポーネントの交換を数週間ではなく数分で適用できます。これらを、残りの使用状況にフラグを立てる lint ルールと組み合わせます。

対策導入

コンポーネントをまだ誰が使用しているのかが分からなければ、削除を計画することはできません。コード (インポート、lint 警告) およびデザイン ファイル (デザイン ツールのライブラリ分析) での使用状況を追跡します。チームが進捗状況を確認できるように数字を公開し、期限を強制するのではなく、最後の数チームを直接支援します。

デザイン面も忘れずに

デザイン ライブラリ内のコンポーネントも非推奨にします。「非推奨」というプレフィックスを付けて名前を変更し、代替コンポーネントにリンクし、検索に表示されないようにしてください。そうしないと、デザイナーは新しい作業でそれを使用し続け、移行は終わりません。動作とインタラクションの動作は変更メモの一部である必要があります。動作が異なる代替品は、見た目が同じであっても壊れているように感じる可能性があるためです。