フィーチャー トグルのメンテナンスについて説明する
フィーチャー トグルは、単なるコードです。 より具体的には、条件付きコードです。 コードがより複雑になり、技術的負債が増加します。
これらを記述するときはこの点に注意し、不要になったらクリーンアップしてください。
機能フラグは役に立ちますが、独自のさまざまな問題を引き起こす可能性もあります。
トグルという概念は、その有効期間が短く、顧客にリリースする必要がある場合にのみソフトウェアに保持されることにあります。
Martin Fowler 氏が説明しているように、トグルの種類は 2 つの側面に基づいて分類できます。
同氏によれば、トグルをどのくらいの期間コードベースに保持するべきかという面と、逆にトグルをどの程度動的なものにする必要があるかという面を見ることができます。
機能フラグのライフサイクルの計画
最も重要な点は、ソフトウェアからトグルを削除する必要があることです。
そうしないと、長期間保持した場合、それらは技術的負債になります。
機能フラグを導入するとすぐに、全体的な技術的負債が増加します。
他の技術的負債と同様に、簡単に追加できますが、コード内のブランチに必要なスキャフォールディング ロジックも追加されるため、コードに組み込まれている期間が長いほど技術的負債が大きくなります。
機能フラグを追加すると、コード内の可能なパスの数が増えるため、コードのサイクロマティック複雑度は増加し続けます。
機能フラグを使用すると、コードの堅牢性が低下し、以下の問題が追加される可能性があります。
- 論理的な組み合わせの数が増えるにつれて、コードの効果的なテストが難しくなる。
- コードがより複雑になるため、メンテナンスが難しくなる。
- コードの安全性も低くなる可能性がある。
- 問題が見つかっても、それを再現するのが難しい場合がある。
機能フラグのライフサイクルを管理するための計画が非常に重要です。 フラグを追加したらすぐに、いつ削除するかを計画する必要があります。
機能フラグの再利用はしないでください。 コードの一部ではなくなったと思われる古いフラグを新しい目的で再利用することにしたチームでは、重大なエラーが発生しています。
リリース フラグの管理ツール
機能フラグの管理に必要な作業量を過小評価しないでください。 以下を追跡するツールの使用を検討することが不可欠です。
- どのフラグが存在するか。
- どのフラグがどの環境、状況、または対象顧客カテゴリで有効になっているか。
- 運用環境でフラグを使用するタイミングの計画。
- フラグを削除するタイミングの計画。
機能フラグの管理システムを使用すると、技術的負債が増え過ぎるリスクを最小限に抑えながら、機能フラグの利点を得ることができます。
Azure App Configuration には、機能マネージャーが用意されています。 Azure App Configuration の機能マネージャーに関する記事をご覧ください。