最佳实践
除了主干开发，什么情况下选择使用Feature Flag呢？下面是使用Feature Flag的一些典型场景：
- 在 UI 中隐藏或禁用新功能
- 在应用程序中隐藏或禁用新组件
- 对接口进行版本控制
- 扩展接口
- 支持组件的多个版本
- 将新功能添加到现有应用程序
- 增强现有应用程序中的现有功能
可以看到，由于Feature Flag本身是对业务功能的控制，所以不适于功能大范围的改动等情况。另外使用过程中需要注意一些问题：
- 只在需要的地方创建开关。美酒虽豪，不可贪杯。滥用任何技术都会出现问题。
- 控制开关的数量。同上，开关应按需使用并及时清除。
- 开关之间代码保持独立。如果代码存在依赖就没法删除，最终维护性反而变差
- 清除发布开关和废弃代码。发布开关应当在功能稳定后删除，旧代码也是。
- 界面层最后暴露。
如何实现 实现这套东西复杂吗？下面以php和smarty模板为例来介绍。
首先需要一套控制代码逻辑的工具，虽然开源的框架有在后端代码层的支持，但推荐在模板层使用Feature Flag，因为模板直接跟功能挂钩，维护起来更加直观方便。
例如我们会提供一个smarty插件，让你控制相应的展现:
这个代码的意思是如果common模块的featureA命中，则展现下面代码，否则展现另外一套代码，展现代码由于与功能相关，所以就相当于控制了展现哪个功能。当然你也可以不用featureelse只控制功能的开启或者关闭。
另外我们需要一个配置文件，对应featureA的配置，如下所示：
{
"features" : {
"featureA" : {
"type" : "switch",
"value" : "on",
"desc" : "test switch feature work or not"
}
}
}
|
featureA配置的value是on，开关类型是switch。也就是说这个功能是开启的。与switch类似的可以实现多个feature类型，例如抽样控制、日期控制、地域控制等，代码逻辑只需要根据value的设定判断是true还是false。例如抽样类型，value设置0.5，那么对应的类型逻辑只需要判断随机数是否在0-0.5范围内而已。
部署中我们只需要修改featureA的配置就可以控制功能的发布，是不是so easy!
开发框架
有哪些相应的开源框架呢？几乎各种语言都有相应的实现。例如FEX FIS小组提供了基于php和node.js的框架。此外还有多种语言的开源实现：
总结- Feature Flag与Feature Branches各有优势，结合使用能发挥更大作用
- 结合业务场景选择合适方案
- Feature Flag能支持主干开发，并在控制功能发布上有独特优势
参考资料
原文出处： 百度FEX - zhangtao
转自 http://blog.jobbole.com/73930/ | 
