Feature Flags：何时该用，何时该弃
When Feature Flags Do and Don't Make Sense
我在多个团队见过 Feature Flags 的极端用法。它在 A/B 测试、复杂 Epic 的渐进式发布以及无法控制部署的场景（如 Facebook Android App）中非常有用。但过度依赖它来规避风险是个陷阱，这往往意味着你的自动化测试和回滚机制出了问题。Feature Flags 会成倍增加代码复杂度，导致组合爆炸，甚至像 KCG 那样因废弃代码引发巨额损失。它不是银弹，滥用只会让技术债务雪球越滚越大。
Feature Flags 是二进制回滚的廉价替代品，它绝对无法取代强大的自动化测试套件和稳健的 QA 流程。
- MaulingMonkey
Feature flags 非常棒。正在处理某个可选子系统中的崩溃或内存损坏问题吗？直接禁用该子系统，就能让你同一分支上的同事先开展工作，而你继续追踪原因。
Feature flags 也非常糟糕。正在处理某个可选子系统中的崩溃或内存损坏问题吗？你之前为了本地构建禁用了它，结果尽管 QA 提供了完美的复现步骤，你却会浪费数小时无法复现问题。
（就我自己的游戏开发背景而言，我学会了通过将音量设为 0 来静音，而不是直接禁用音频子系统。）
- joezydeco
“在 Google，我们的理念是‘回滚是常态’。当在新版本中发现或合理怀疑存在错误时，发布团队会先回滚，然后再调查问题。”
好吧，这下全都讲得通了。我的公司裁掉了大部分 QA 团队，我现在看到的就是一连串的回滚公告。谁还需要回归测试呢？
- classictraffic
我同意整篇文章的前提，但我认为关于成本的论点有点夸大。在我看来，添加“不必要”的 feature flags 并不是什么大不了的事，feature flags 的添加和维护成本都很低。此外，在某些情况下，切换 feature flags 比执行回滚更快，尤其是当涉及多个系统时。
我认为真正的成本在于 feature flags 会导致代码膨胀和可读性问题，因为工程师们通常不太擅长在功能上线后清理 feature flags。我认为这是一个很容易解决的问题，并不需要采取“少用 feature flags / 仅在必要时使用”这种稀缺心态。LaunchDarkly 让追踪 feature flags 的使用情况并提醒人们清理旧的 flags 变得非常容易。