主干开发模式下,代码库中会有开发中的特性,这些特性并不适合发布到线上。业界通常用特性开关(FeatureFlags)来解决这个问题。特性开关系统本质上只是一种工程实践,可繁可简。最简单的实现其实就是一个 bool 类型的配置项。在过去我们用 google gflags 库来实现特性开关。功能开启或者关闭,修改后重发配置文件即可(可能要重启)。我们的服务框架也支持通过 HTTP 请求修改。规范地讲,特性开关的生存期不应该太长,否则会引起“特性开关技术债务”,因为每个有效的特性开关在代码中都至少对应着一条 if 语句,引起函数的圈复杂度增加。过于已经固化的特性,应当限期清理掉。但是实际上却有很多特性开关不敢轻易删除。其中原因之一,就是业务开发人员如果不是对代码特别熟,可能不知道这个开关是否真的还在使用,贸然删除可能会导致错误乃至事故。如果每个开关都引入监控项,使用成本又增加了很多。因此我们开发了在线的特性开关管理系统。对每个开关的访问情况作出统计。系统在开关快要到达期限前,就会自动通过企业微信通知其开发人员删除,并且在真正删除之前也会检查是否还有有效的请求。特性开关管理系统也支持以配置文件为主的方式,此时在线系统就成为特性开关的查看和监控系统,了解系统有多少特性开关,使用情况如何。特性开关系统也支持对一些上下文参数(IP,用户 id 等,广告位 id)等通过开发人员配置的表达式动态判断是否开启。
我们在整个流程的收集了大量数据,然后有专业而负责的 QA 团队输出各种报表,和各个业务研发团队对齐目标,推动其改进。比如上面的 UT 覆盖率只是其中一种。不过度量这部分目前做的确实还不好,有待加强。不过要强调的是,数据采集出来,主要用作对研发流程效率提升的分析工作,一定要谨慎考虑是否能纳入度量体系,以免起到负面引导作用。