開発戦略
Future Flagsを使用した新機能の段階的な採用
私たちのソフトウェア開発アプローチでは、メジャーバージョンに関して以下の目標を掲げています:
- 段階的な機能採用:開発者は、現在のメジャーバージョンで利用可能になった新機能や変更を、一つずつ柔軟に選択して統合できます。これは、すべての変更を単一の新しいメジャーバージョンにバンドルする従来のアプローチとは異なります。
- シームレスなバージョンアップグレード:新機能を事前に選択的に統合することで、開発者は既存のアプリケーションコードを変更することなく、新しいメジャーバージョンにスムーズに移行できます。
不安定なAPIとFuture Flags
新機能はunstable_someFeature
のようなFuture Flagsを使用して現在のバージョンに導入されます。これらのフラグは、vite.config.ts
ファイルのRemix ViteプラグインのFutureオプションで指定できます:
remix.config.js
のfuture
オプションでFuture Flagsを提供できます
-
不安定な機能が安定状態に達すると、特別なプレフィックスを削除し、次のマイナーバージョンにその機能を含めます。この時点で、APIの構造は後続のマイナーバージョンで一貫性を保ちます。
-
このアプローチにより、アーリーアダプターと協力してAPIを改善し、すべてのユーザーに影響を与えることなく、不安定な段階で必要な変更を取り入れることができます。安定版は、その後これらの改善から中断することなく恩恵を受けます。
-
unstable_*
フラグの付いた機能を使用している場合は、各マイナーバージョンのリリースノートを必ず確認してください。これは、これらの機能の動作や構造が変更される可能性があるためです。この段階でのフィードバックは、最終リリース前に機能を強化する上で非常に価値があります!
Future Flagsを使用した破壊的変更の管理
破壊的変更を導入する際、現在のメジャーバージョンのコンテキストで行い、Future Flagsの背後に隠します。例えば、v2
にいる場合、破壊的変更はv3_somethingDifferent
のようなFuture Flagの下に配置される可能性があります。
- 既存の
v2
の動作と新しいv3_somethingDifferent
の動作が共存します。 - アプリケーションは、次のメジャーバージョンで多くの変更に一度に適応する必要がなく、一度に1つずつ変更を採用できます。
- すべての
v3_*
Future Flagsが有効になっている場合、v3
への移行は理想的にはコードベースに変更を加える必要がありません。 - 破壊的変更をもたらすFuture Flagsの一部は、最初は
unstable_*
フラグとして始まります。これらはマイナーバージョン中に変更される可能性があります。v3_*
Future Flagsになると、対応するAPIが設定され、それ以上の変更は行われません。
まとめ
私たちの開発戦略は、機能の段階的な採用とメジャーバージョンのシームレスなアップグレードに重点を置いています。これにより、開発者は新機能を選択的に統合し、バージョン移行時の大規模なコード調整を避けることができます。unstable_*
フラグを通じて機能を導入することで、アーリーアダプターと協力してAPIを改善し、安定版が機能強化の恩恵を受けることを確実にします。v3_*
フラグを使用して破壊的変更を慎重に管理することで、変更を段階的に採用する柔軟性を提供し、メジャーバージョン間のよりスムーズな移行を促進します。これによりRemixフレームワークの開発の複雑さは増しますが、この開発者中心のアプローチは、Remixを使用したアプリケーション開発を大幅に簡素化し、最終的にソフトウェアの品質と(願わくば!)開発者の満足度を向上させます。