機能フラグがコードベースを台無しにしている

マーティン・ファウラー 言う 彼の記事の中で:

では、機能フラグの何が問題なのでしょうか? とりわけ：

1. 彼らはPMに次のような言い訳を与える 難しい決断をしない機能を完全に削除するなど。

2. コードベースはより複雑になり、 維持するのが難しい。

3. テストが難しくなる（そして品質が低下する） – 機能フラグのどの組み合わせをサポートする必要があるかを判断します。

先に進む前に、いつもの免責事項を述べておきます。これは、私自身の経験に基づいた、一人の男の意見にすぎません。

毎週のニュースレターに新しいセクション「Leading Developers」求人掲示板が追加されました。 最後までスクロールして、エンジニアリングのリーダーシップの役割を確認してください:)

これは、機能リリースをコードのデプロイメントから分離する方法として始まりました。 開発者は、顧客に影響を与えることなく、未完成または未テストのコードを main/master/trunk ブランチにプッシュできます。 後で、準備ができたら、設定を切り替えて機能を有効にすることができます。

非常に簡略化したバージョンでは、次のようになります。

if (isNewUIFeatureFlagEnabled) {
    return newUIComponent;
} else {
    return oldUIComponent;
}

ピート・ホジソン 書きました 素晴らしい テクニカル Martin Fowler の Web サイトにある機能フラグに関する記事。 以下の引用はその記事からのものです。

私は機能フラグと言うことに慣れているため、フラグとトグルという用語を同じ意味で使用しますが、機能の切り替えも一般的です。

これまで見てきたように、機能フラグの最も簡単な使用法は次のとおりです。 トグルを解放する – トグルの後ろに隠れているコードを「オン」にします。

このままシンプルになればいいのに。 機能フラグ機能を導入すると、PM はそれを使用するための他のアイデアを思いつきます。

• なぜ構成変更を開発者に頼らなければならないのでしょうか? PM がアクセスできる場所に移動しましょう。そうすれば、誰にも迷惑をかけずに実行できるようになります。

• ついでに、ユーザーごとに調整できるようにしましょう。 そうすることで、PM は数人のユーザーがフィードバックを収集して自分たちでテストできるように機能を安全にリリースし、その後で全員にリリースすることができます。

  これは次のようなものです カナリアリリース。 両者の違いは、カナリア リリース機能はランダムに選択されたユーザー コホートに公開されるのに対し、ここでは機能は特定のユーザー セットに公開されることです。

• そして、なぜ機能を有効にするためにそれを使用することに限定するのでしょうか? 最もリソースを多く消費する機能を後ろに置き、異常な過負荷が発生した場合には運用担当者がそれをオフにできるようにしましょう。

• ああ、プレミアム ユーザーもいるのですから、そのユーザーに対してのみいくつかの機能を有効にしてみましょう。

• 最後に 1 つ、すべてを機能フラグの下に置くことができます。 したがって、修正を元に戻す必要がある場合に備えて、バグ修正をフラグの下に隠してください。

こうして、何百ものアクティブな機能フラグが存在する、ひどい状況に陥ることになります。

上記の提案はすべてが悪いというわけではなく、ほとんどは理にかなっています。 問題は、それがすべての答えになる場合です。

機能フラグは、特に最初に導入されたときに急速に増加する傾向があります。 これらは便利で安価に作成できるため、頻繁に大量に作成されます。 ただし、トグルには持ち運びコストがかかります。 ナイトキャピタルグループの 4億6000万ドルの間違い これは、機能フラグを (とりわけ) 正しく管理しないと何が問題になるかについての警告として役立ちます。

では、その「維持コスト」とは何でしょうか？

複数の機能フラグを含むコード ファイルを理解しようとすることは、特に初心者の開発者にとってはほとんど不可能です。 あなた いつもの 各機能フラグが存在する理由と、それが何を表しているのかについてのコンテキストがわからないため、迷ったり推測したりすることになります。

デバッグも難しくなります。 何らかのバグに対してチケットを取得したが、それをどうやっても再現できない場合。 1 日後、ユーザーが持っている古い機能フラグをオンにする必要があったことを思い出します…

最初の目標を覚えていますか?

リリース切り替えにより、不完全でテストされていないコードパスを実稼働環境に出荷することができます。 潜在コード どれの 決してオンにならない可能性があります。

リリースされていない機能を開発すると、コードは永久に潜在的なままになります。

開発者は最終的にそのコードをサポートすることになります。 開発者が、リリースされなかった機能フラグの下で (より大規模なリファクタリングの一環として) コードのリファクタリングに 1 日を費やしたというケースを見たことがあります。

単一の機能フラグにより、テストの負担が X2 増加します。変更ごとに、機能フラグを使用した場合と使用しない場合の両方で機能をテストする必要があります (e2e テスト カバレッジが 100% ではないと仮定します)。

理想的には、機能フラグは常に個別に、1 か所に配置され、機能を非表示にするか表示するかのいずれかになります。 実際には、それらはしばしば衝突します。 したがって、同じファイル内に複数のフラグがある場合、「可能なトグル状態の組み合わせ爆発‘。

実際には、考えられるすべての組み合わせをテストする必要はありませんが、どの組み合わせをテストすべきかを判断するのがそれほど簡単ではない場合があります。

…そのため、機能フラグはテストの代わりになります。「心配することはありません。問題が見つかったら、オフにして後で修正します。」

その結果、顧客にひどい経験をもたらすことになります。

すべてを機能フラグの下に置く必要はありません。 バグ修正を行う場合は、テストしてリリースするだけで問題ありません。問題が発生する場合は、ソース管理があるため、PR を元に戻すのに長くても数分かかるはずです。

はい、これは時々発生する可能性があります。

古い機能についても同様で、もうサポートする意味がありません。 機能フラグを作成する前に、それらを削除するだけです。 さて、その機能フラグをオフにするのは非常に簡単で、「いつか」誰も文句を言わなければ、最終的に削除が許可されることになります（「削除の許可を待っている開発者」というパブロ・エスコバルの 2 番目のミームは割愛します）機能です」）。

すべての機能の切り替えを同じバケットにまとめたくなるかもしれませんが、これは危険な道です。 トグルのカテゴリごとに影響する設計力はまったく異なるため、すべてを同じ方法で管理すると、将来的に問題が発生する可能性があります。

初め、 機能フラグにはさまざまなカテゴリがあるという事実を組織に認識させてください。

ホジソン氏は主に 4 つのことについて話します。

1. トグルを放す

2. 運用切り替え

3. 実験の切り替え

4. 権限の切り替え

各タイプのトグルは異なる期間存続する必要があり、それを変更するには異なる要件があります。

1.トグルを放します

私たちが始めたものでは、開発者が準備ができていないコードを運用環境にマージし、準備ができたら有効にすることができます。

それを切り替える責任者は誰ですか: 開発者。 これらのタイプの切り替えは構成ファイル内に存在できます。

いつ削除すべきか: 機能のリリースから 1 ～ 2 週間後。

2. 操作の切り替え

運用チームに制御させたかった、リソースを大量に消費する機能を覚えていますか?

パフォーマンスへの影響が不明瞭な新機能を展開するときに、システム オペレーターが必要に応じて運用環境でその機能を迅速に無効化または機能低下させることができるように、Ops Toggle を導入する場合があります。

それを切り替える責任者は誰ですか: 運用チーム – おそらく専用ツールを使用します。

いつ削除すべきか: 1～2週間、 新しい機能に自信が持てるようになったら。 まれに、システムの負荷が異常に高いときに重要ではない機能を停止するために、いくつかの「キル スイッチ」を保持する場合があります。

3. 実験の切り替え

このタイプの切り替えにより、A/B テストを実行できます。 ユーザーをグループに分け、それぞれが異なるエクスペリエンスを体験します。 トグルがアクティブになっている間、最終的な決定を下すのに十分なデータが収集されます。

それを切り替える責任者は誰ですか: 状況によって異なりますが、ほとんどが PM です。

いつ削除すべきか: 数日または数週間 – 最終的な決定を下すのに十分なデータが得られたら。

4. 許可の切り替え

最も危険なものを最後に残しました。 このタイプの切り替えを使用すると、Web サイト上で特定のユーザーが持つ機能やエクスペリエンスを変更できます。 それは、有料顧客向けの「プレミアム」機能、または内部ユーザー/ベータ顧客向けの「アルファ」/「ベータ」機能の提供によるものである可能性があります。

このタイプは危険です。 とても長生きです、時には何年も。 これを他のトグルと同じように、すぐに削除されるものとして扱うことは、重大でありがちな間違いです。

それを切り替える責任者は誰ですか: PM

いつ削除すべきか: おそらくそれを削除するのはあなたではないでしょう…数年以内に一部の貧しい開発者が削除するでしょう。

全員がカテゴリについて意見を合わせたら、社内でそれぞれのカテゴリをどのように管理すべきかについて話し合います。 機能がライフサイクルを経るにつれて、 カテゴリ間を移動することもできます。

最初は、開発中にリリース トグルの下に配置します。 次に、それを実験トグルの背後に移動して、収益への影響を測定する可能性があります。 最後に、これを使用することに決めたら、それを Ops Toggle の後ろに移動して、極度の負荷がかかっているときにオフにできるようにします。

ホジソン氏は次のように提案しています。

…機能フラグ管理の観点から見ると、これらの移行は絶対に影響を与えるはずです。 リリース トグルから実験トグルへの移行の一環として、トグルの構成方法が変更され、おそらくソース管理の YAML ファイルではなく管理 UI など、別の領域に移動する可能性があります。

今後は、開発者ではなく製品担当者が構成を管理することになるでしょう。 同様に、Experiment Toggle から Ops Toggle への移行は、トグルの構成方法、その構成が存在する場所、構成の管理者に新たな変更が生じることを意味します。

ただし、すべてをまったく同じ方法で管理したとしても、 開発者と PM の間の期待を調整するためだけに、さまざまなタイプの存在を認識することが重要です。

開発者が、機能フラグがアクセス許可トグルであり、永久に維持する必要があることを知っている場合、すぐに削除する必要があるリリース トグルとは大きく異なる設計をします。

これは、機能フラグを使用する場合の最大の課題です。 数値を管理できれば、問題の 80% は解決したことになります。問題を解決するのはあなたの仕事です。

一般的なアプローチ (まれに機能しますが) は、機能フラグを導入したらすぐにそれを削除するチケットを追加することです。

より良いアプローチは、自分自身に責任を負わせることです。 記事より:

• 一部のチームは、トグルに「有効期限」を表示します。

• 他の人はそこまで行きます テストに失敗する (またはアプリケーションの起動を拒否することさえある) 「時限爆弾」を作成します。 機能フラグが有効期限を過ぎてもまだ存在する場合。

• もう 1 つのオプションは、システムが一度に持つことを許可される機能フラグの数に制限を設けることです。 この制限に達すると、新しいトグルを追加したい場合は、まず既存のフラグを削除する作業を行う必要があります。

クリックベイトのタイトルとは対照的に、機能フラグは良いことだと思います。 これらは自由に使える強力なツールの 1 つであり、使いすぎないように注意する必要があります。

機能フラグ システムの実装に関する注意: 車輪の再発明はしないでください。 OpenFeature 標準があり、数か月前に CNCF の育成プロジェクトになりました。

新しいセクションへようこそ! 毎週、あなたに関連するかもしれないエンジニアリングリーダーの仕事を紹介します。