/tags/feature-flags/ Recent content in feature-flags on Hugo -- gohugo.io en Thu, 23 Jul 2026 09:00:00 +0800 /reading/pete-hodgson/feature-flags-hidden-complexity/ Thu, 23 Jul 2026 09:00:00 +0800 /reading/pete-hodgson/feature-flags-hidden-complexity/ Pete Hodgson 是 OpenFeature 治理委员会成员、软件交付顾问，曾在 martinfowler.com 发表过关于 Feature Toggles 的经典长文。在 KubeCon + CloudNativeCon NA 2025（Atlanta）的演讲 Feature Flags Suck! 中，他分析了 feature flag 被低估的水下复杂度与债务成因，并提出了通过元数据治理、Keystone Interface 架构模式以及 CNCF OpenFeature 标准管控开关成本的思路。 两种常见偏见与同一个病根 Pete 在开场抛出了业界对待 feature flag 的两种典型态度： 偏见一：不就是个 if-else 吗？ 数据库加个字段、写几行逻辑就能搞定，为什么需要框架或付费服务？ 偏见二：代码里的开关太多太乱了！ 充斥着大量过期的 if 判断，无人敢删，测试路径爆炸，系统维护成本飙升。 Pete 的观点是，这两者本质上是同一个问题：正因为最初低估了开关的复杂度，采取了过于粗糙的实现，才导致后期陷入开关膨胀与代码腐化的困境。Feature flag 本身不产生直接业务价值，它只是达成安全发布、灰度验证或实验目的的手段，同时伴随着持续的维护与测试成本。 水下冰山：被低估的开关复杂度 为什么说 feature flag 不仅仅是 if 判断？Pete 用冰山作比喻：水面上能看到的仅仅是「评估一个布尔条件」；但随着使用场景从简单的全局开关扩展到复杂灰度，水面之下会陆续冒出一整套基础设施需求： Evaluation Context（评估上下文）：需要知道「对谁评估」——包含用户 ID、租户/组织、环境等上下文信息。 Rules Engine（规则引擎）：基于上下文实现动态路由、特定组织可见或百分比灰度。 管理 UI 与权限控制（RBAC）：提供给产品经理等非工程人员配置，同时防止误操作把未就绪功能全量推向生产。 Audit Trail（审计追踪）：记录谁在什么时间修改了哪个开关。 Analytics & Telemetry（可观测性）：将开关评估事件与业务指标、系统耗时及实验数据对齐。 如果团队选择自研开关，通常在 6 到 12 个月后就会发现，自己不知不觉中承担了维护一套内部 Flag 平台的沉重负担。