敏捷开发流程中的质量控制：Feature Flag

现在都提倡敏捷开发，基本上已经成了现代软件开发的尤其是移动互联网app开发的标准模式。快速迭代、快速试错成了每个人开口闭口都在谈的东西，但是问题是，如何在快速迭代中保证产品质量，如何在快速试错的同时尽量避免你的“错”去影响到实际用户，以及如何知道是“对”还是“错”？实际上，这才是区分一个开发团队优秀与否的关键，如果只是求快，有大把外包公司排着队。。。

在Agile Development中如何保持质量以及如何快速测试功能是个复杂的话题，涉及到A/B test, User tracking, unit test, code review flow, CI及Analytics等等多个方面。在这里 鹅厂Turing Lab副总监 张力柯 先从一个概念的实施谈起：Feature Flag.

1）What is Feature Flag?

我们假设现在你的app已经完成核心功能，打个比方说你是一个交友软件能够用两个用户账号互相发消息了，现在你在考虑是不是要加入微信登录或者QQ登录，你不知道是不是两者都要还是只需要一个看起来比较简洁，或者是不是年轻人更喜欢QQ登录，或者要不要加个facebook登录看起来更国际范。。。这时候你很可能就需要实现Feature Flag并以此作为数据驱动的来源。

啥叫feature flag?也就是功能开关标志，顾名思义，很简单，无非是有个后台控制去开启／关闭某个功能。简单吧？然而，在开发／测试人员一天埋没在各种bug里面，一天在发布新版本上线时彻夜不眠时，是否想过其实你缺的就是个功能开关。实际上，Feature Flag在硅谷FLAGUAPS等一线互联网公司及大大小小startup的开发流程中，早已成为标配。这不仅仅只是为了开关某个功能，而是要在敏捷开发／快速试错／数据驱动决策这整个流程中不可缺少的一环。

首先来说数据驱动，这个词语已经流传了很多年，各家公司都号称自己是data driven. 那么到底是不是，很简单，看他们的产品和代码是否支持A/B Test. 如何看？很简单：一个新功能，能否只对Android用户开放而不对iOS用户开放？能否收集两天数据后别换版本，直接后台控制对iOS开放而对Android用户关闭？当然，这一般还会对用户群比例作出限制，这是另外一个细节，在这里先就不谈，大家应该对A/B test的概念不陌生。技术实施上可以复杂可以简单，但是区分一个团队是否是做到了data driven(或者拍脑袋driven)，就要看A/B test是否普及。在国外FLAGUAPS等公司，A/B测试是任何新功能发布（哪怕改一个按钮位置）必须加入的环节。当然，这也可能是资本主义的糟粕。。。

至于Feature Flag，一个软件是由各种功能组合起来，那么对于每一个功能，理论上是应该能够随时开启或关闭的。这里又涉及到一个core flow的问题，就是一个软件的核心最基本的流程是可以没有关闭选项的，打个比方说微信的功能入口，对“看一看”这些功能在初上线的时候，是应该能后台控制关闭或开启，并能针对不同用户／设备／地域等进行控制，但对于聊天这个选项，是可以没有关闭选项的（这就看设计者的要求了，原理上唯一不能关闭的就是进入app，其它都该能够有开关选项）。

2) Who should be using feature flag?

必须强调一点，Feature Flag这个概念并非程序员专用，这实际上是个产品开发设