フィーチャーフラグの命名規則
フィーチャーフラグキーの一貫した命名規則を確立します。プレフィックス、名前空間、ケーシングスタイル、大規模チーム向けの組織パターンをカバー。
Best Practices
詳細な説明
フィーチャーフラグの命名規則
一貫した命名により、フラグが発見しやすく、自己文書化され、大規模に管理しやすくなります。良い命名規則は、一目でフラグの目的、スコープ、オーナーシップを伝えます。
推奨フォーマット
{prefix}.{team}.{feature-name}
例：
release.checkout.one-click-buyexperiment.growth.signup-modal-v2ops.payments.stripe-circuit-breakerpermission.enterprise.sso-login
プレフィックスカテゴリ
| プレフィックス | 目的 | 典型的なライフタイム | 例 |
|---|---|---|---|
release. |
新機能ロールアウト | 数週間 | release.auth.passkey-login |
experiment. |
A/Bテスト | 2-4週間 | experiment.pricing.annual-discount |
ops. |
運用制御 | 恒久的 | ops.api.rate-limit-v2 |
permission. |
権限/プラン | 長期間 | permission.pro.export-csv |
config. |
動的設定 | 様々 | config.ui.items-per-page |
ケーシング規則
| スタイル | 例 | 使用タイミング |
|---|---|---|
kebab-case |
new-checkout-flow |
最も一般的、URLフレンドリー |
snake_case |
new_checkout_flow |
Python/Rubyエコシステムで一般的 |
camelCase |
newCheckoutFlow |
JavaScript/TypeScriptコードベース |
dot.notation |
checkout.new.flow |
階層的な名前空間 |
1つのスタイルを選び、すべてのフラグで一貫して使用してください。
避けるべきアンチパターン
| 悪い例 | 理由 | 良い代替 |
|---|---|---|
flag1, test-flag |
意味がない | release.search.fuzzy-matching |
temp-fix-for-bug |
曖昧すぎる | ops.billing.invoice-retry-fix |
johns-experiment |
個人固有 | experiment.growth.signup-redesign |
new-feature |
一般的すぎる | release.editor.markdown-preview |
ユースケース
15のエンジニアリングチームを持つ企業が、300以上のフィーチャーフラグに秩序をもたらすためにフラグ命名規則を採用。release.{team}.{feature}のフォーマットをLintツールで強制し、作成時に非準拠のフラグキーを拒否。1ヶ月以内にフラグの発見可能性が向上し、チームが誤って他のチームのフラグを参照することがなくなった。