フィーチャーフラグのハードコーディングは問題ない（2025年）

フィーチャーフラグ（またはトグル）は、製品の新機能の可視性を制御するためによく使用されます。それらを実装するにはいくつかの方法がありますが、最も話題になりマーケティングされているのは、フィーチャーフラグ管理ソフトウェアを使用することです。もちろん、最も簡単な方法はそれらをハードコーディングすることですが、それについては最も書かれていません。フィーチャーフラグ管理ソフトウェアは強力である可能性がありますが、それらは複雑さとリスクの源でもあります。それらの背後にあるブログスパムマーケティングは非常に強力であるため、それらが不要であることを認めることは、技術的な無力感を告白するようなものです。私たちは、いくつかのフィーチャーフラグだけでなく、数千のフィーチャーフラグにスケールする必要があると確信しています。それだけでなく、実行時に機能を変更する必要があり、デプロイ、再起動、キャッシュフラッシュ、データベースマイグレーション、レビュー、テストなしでそれを行う必要があります。なぜなら、ビジネスが炎上しており、それを消す唯一の方法は、ホームページのボタンの色を変更することだからです。そのようなシステムの機能がもたらすべき唯一のフラグは、#ff0000のバリエーションです。アーキテクチャの観点から、それらは独立したプロセスで管理される、飾り立てられたif文にすぎません。多くの場合、独自のインフラストラクチャ、ホスティング、監視、およびそれに伴うすべての責任が必要です。開発ライフサイクルの観点から、それらは非決定的な動作を導入し、コードの推論をより困難にします。長期間存続するフィーチャーフラグは、当初は意図されていたとしても、コードベースを硬化させる技術的負債につながります。このリスクはハードコーディングされたフラグでも存在しますが、はるかに見やすく管理しやすいです。セキュリティの観点から、それらは脆弱であり、攻撃または脆弱性の表面積が増加しました。いずれにせよ、ソフトウェアシステムにさらに多くの可動部品を追加することは、それが実際に必要かどうか、およびそれがもたらすリスクが解決される問題に見合うかどうかを常に精査する必要があります。ハードコーディングされたフィーチャーフラグは、これらの問題の多くを解消します。それらはシンプルで、信頼性が高く、安全です。それらは最も退屈な方法であり、だからこそ最良の方法なのです。単純なJSONファイルから始め、アプリケーション起動時にそれを読み込み、機能の可視性を制御するために使用します。フラグを最新の状態に保ち、不要になったら削除します。それらが長すぎると、実際の動作にしてフラグを削除します。通常の開発プロセスを通じて値を変更し、レビュー、テスト、デプロイを行います。ほとんどのチームと製品にとって、これはしばしば十分であり、多くの価値をもたらすでしょう。チームが実際に大規模な実行時機能変更の必要性に達したとき、SPAの状態管理と同様に、それが必要であることを知るでしょう。時期尚早な最適化は正しい道ではありません。それは悪い設計であり、悪いエンジニアリングであり、技術会議でセールススピーカーが誰か使用しているかと尋ねたときに、短い自己満足の瞬間によく役立つだけです。