フィーチャーフラグをハードコードするのは正しい選択だ
It's OK to hardcode feature flags (2025)
フィーチャーフラグ管理ソフトウェアは複雑さとリスクを生む。ハードコードされたフラグはシンプルで信頼性が高く、安全だ。開発ライフサイクルでは非決定的な動作を避け、コードベースを理解しやすくする。セキュリティ面でも攻撃対象を増やさない。多くのチームにとって、JSONファイルでフラグを管理し、通常の開発プロセスで変更するのが十分効果的であり、ランタイムでの大規模な変更が必要になるのは稀なケースだ。
ハードコードされたフィーチャーフラグは、シンプルで信頼性が高く、安全です。最も退屈な方法ですが、だからこそ最良の方法なのです。
HNでの議論
43- jameshart
私の経験では、（設定ベースのフィーチャーフラグとフィーチャーフラグサービス）これらは実際には、たまたま同じ名前を共有しているが、まったく異なる2つの問題を解決する、補完的な2つの能力です。
設定アプローチは、ソフトウェア開発ライフサイクルのツールとしてフィーチャーフラグを使用するために重要です。これは、新しい機能Xの未完成のコードを含むコードベースを管理する方法であり、機能Xをオンにせずにデプロイしてすべてのテストに合格することができます。
このモデルでは、機能Xに取り組んでいる開発者がローカルテスト用にそれを有効にできるようにするメカニズムと、CIシステムがフラグシステムと対話して、アプリケーションがXをオンとオフの両方の状態で機能することをテストできるようにするメカニズムが必要です。
これはトランクベース開発モデルに理想的です。フィーチャーブランチは代替アプローチですが、これから実際には利益を得られません（実際、フィーチャーブランチでの作業に複雑さを追加します）。
一方、フィーチャーフラグサービスは、同じソフトウェアを使用する異なるユーザーが異なる機能をオンにする必要があるという問題を解決するためのものです。これは、内部テスターやベータユーザーと同じくらい単純な場合もあれば、テナントごとに固定の更新ウィンドウで機能をロールアウトするために保持する場合もあり、段階的な露出を通じて機能をロールアウトするリスク管理戦略の一部である場合もあります。
また、フィーチャーフラグシステムをA/Bテストシステムと混同したくなるかもしれません。フィーチャーフラグサービスを使用して、テストコホートに機能を公開し、[…]
- jdwyah
私は2番目のフィーチャーフラグスタートアップに携わっていますが、この意見にもある程度同意します。
すべてのプロジェクトにフラグが必要ですが、多くのプロジェクトは基本機能だけを必要とし、サービスはやり過ぎです。
しかし、独自のJSONをロールすることは避けるべきだと今でも思います。確かに、最初は95%がブール値です。しかし、その後ロールアウトが必要になります。そして、ターゲティングルールが必要になります。そして、非ブール値…おそらくJSONが必要になります。ああ、JSONがスキーマに準拠できればいいのに…そして最終的には、デプロイせずにこれらを変更したいと思うでしょう。または、複数のサービスから同じフラグを読み取りたいと思うでしょう。
私はこの最小公分母をhttps://quonfig.com に組み込もうとしました。SDKとして完全に無料でオープンソースで使用でき、gitで追跡できるJSONをロードするだけです。エージェントはそれを気に入り、ホットリロード、多くの言語のSDKがあります。しかし、独自にロールする場合と比較して、設計には多くの余裕があります。多数のターゲティング演算子。セグメントなど。そして、実際にリアルタイム更新のための素敵なUI/配信ネットワークが必要な場合は、有料版を使用できます。
ローカル使用の説明: https://docs.quonfig.com/docs/how-tos/open-source-local
- avlcodemonkey
C#を使用している場合、Microsoftは.NETで機能管理のファーストクラスサポートを追加しました: https://github.com/microsoft/featuremanagement-dotnet。単純なオン/オフ、ユーザーターゲティング、パーセンテージロールアウト、スケジュールのロジックを提供します。機能管理と`appSettings.json`にハードコードされたフラグを組み合わせて使用することは、よりシンプルなアプリケーションには理にかなっています。
アーキテクチャが成長し、複数のアプリケーション間で設定を同期する必要が生じたり、非技術者がフラグを変更する必要が生じたりした場合は、ハードコーディングを超えて、サービスの構築（または購入）を検討する必要があるでしょう。プロダクトオーナーに`FeatureManagement__NewFeature__EnabledFor__0__Name`のような環境変数を設定させたくはないでしょう。Azureを使用しても構わないのであれば、Azure App Configurationが有力な選択肢です。JSONを扱う代わりに、フラグを編集するための素敵なUIを提供します。または、Azureを避けたい場合は、代替プロバイダーとしてhttps://featureflags.app/ を構築しています。これは、ハードコーディングとLaunchDarklyのような本格的なプラットフォームの中間のようなものです。
- stronglikedan
もちろん、Knight Capitalのような場合は別ですが。https://www.youtube.com/watch?v=UuqSy1jPSUw
- maxidog
私は現在、大規模なエンタープライズアプリをリバースエンジニアリングしていますが、フィーチャーフラグの肥大化は本当に驚くべきものです。私の意見では、過度なフィーチャーフラグの複雑さは、優柔不断で開発者から信頼されていない経営陣の症状です。