主干开发,“关上”未完成的功能

软件开发中,“配置开关”根本算不上是一个“新”概念。无论是通过启动时加载配置,还是应用程序运行时动态刷新配置,都可以用来决定或改变应用程序的某种具体行为。比如:

  • 通过配置文件,使用应用程序连接不同的数据库
  • 通过模板配置,达到应用程序“换肤”的目的
  • 通过系统管理员的配置,使不同的用户具有不同的权限

所有这些“开关”都被认为是理所当然的,因为用户的需求就是这样的,“我需要通过xx开关来控制yy”。因此,做为交付团队,也会老老实实地把这些需求实现了。

然而,现在的很多团队,为了能够尽早发布软件,使用主干开发方式,并在程序中加入了另外一种“对用户透明”的开关。这种开关通常有两种使用场景是:

  1. 某些高级(或创新)的特性已经开发完毕,但业务人员根据市场情况,认为不需要投放市场。
  2. 市场需要某些已开发完成的特性,但还有一些特性尚未完成,仍旧处于开发中。

无论哪种情况,都是要求将某些特性进行隐藏后再发布。这种开关常常被认为是不可取的,但现在很多需要“持续交付”的公司都在使用。

(有的同学会说:“这完全可以通过按特性拉分支的方式来解决”。关于这个问题,我会在下一篇中讨论,本次仅限于讨论在使用“主干开发”的情况下,如何正确使用开关。)

开关最容易的地方就是应用程序的用户界面。当为已上线的应用程序重新设计了全新交互界面后,团队无法在一次性在同一发布周期中将其修改完成时,可以 先保留原有页面不变,同时每次仅替换少数的新页面。令所有未开发完成的页面对用户不可见,例如:原有页面的URL是 http://xx.xx.xx.xx/create_user,那么对应的新页面使用http://xx.xx.xx.xx/new_UI /create_user(要对后台逻辑的修改应能够同时响应新旧两个页面的请求)。当新页面完成后,将原来创建用户的页面链接重新指向新页面就可以了。 这样,就能在不破坏原有功能的前提下,做到持续发布。

开关实现形式

另外,对于那些无法在一个发布周期内实现的新功能,我们可以使用下面形式的“开关”:

  • 配置文件,通常在启动时加载

<features>
<feature name=”hq.remote_panel_load” />
<feature name=”el.enable_asset_library” />
…etc…
</features>

  • 在代码中实现

public function isFeatureOn(featureName:String):Boolean {
var nodes:XMLList = xml.features.feature.
(@name==featureName);
return null != nodes && 0 < nodes.length();
}

  • 设计成API

${core-url}/accounts/featureBits?userUid=&orgUid=&

而在编码中,可以使用不同的实现方式:

  • 最简单的检查

if( registry.config.isFeatureOn( featureName ) ) {
// new implementation …
} else {
// the old way …

}

  • 使用策略模式

if( registry.config.isFeatureOn(“ct.analyzer.v2”) ) {
service.analyzer = new Analyzer_v2();
} else {
service.analyzer = new Analyzer();
}

  • 使用工厂模式

public function createMainDisplay():DisplayObject {
if( registry.config.isFeatureOn( “service.panel.v2” ) ) {
return new panel2(); // which extends panel
} else {
return new panel(); // which extends DisplayObject
}
}

  • 使用责任链方式

if( registry.config.isFeatureOn(“hq.trickle_reporting”) ) {
userActionLogger = userActionLogger.setNext(new       TrickleReportNotifier() );
}

注意事项:

  • 提前评估是否需要开关,需要的话提前设计,不应该随意在代码中添加。
  • 定义一个开关命名规则,并在团队中达成共识。
  • 尽可能在设计时考虑在哪些层次上加开关。

“开关”在使用中的反模式:

  • 代码中到处都是开关,个数太多;
  • 在开关完成其使命后,未及时清理,使代码变烂。

现在,很多公司的产品都使用这种开关方式。进一步阅读,请参见:

相关工具:

代码示例来自于:Erik Sowa,”Feature Bits” on slideshare.net

本文版权归作者乔梁所有,转载请包含作者签名和出处,不得用于商业用途,作者将保留“追究法律责任”的权利!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据