微信号:infoqchina

介绍:有内容的技术社区媒体

在项目中透明地引入特性开关

2013-09-06 17:30 孟宇

在前几期的InfoQ专栏中刊登了一篇名为“使用功能开关更好地实现持续部署”的文章,文中讲解了特性开关与Spring的集成应用。但如果项目没有依赖Spring,又该如何更好地使用特性开关呢?同时,又该如何透明地引入,使得项目不至于完全依赖特性开关呢?

接下来我将结合我们在项目中实际运用特性开关的经验,从另一个角度为大家介绍如何使用特性开关透明地实现功能屏蔽。


问题

我们的团队正在开发一款在线保险产品,该产品下包括若干品牌,每个品牌有不同的目标用户群,但提供的服务基本相同。当第一个品牌正式上线后,我们就面临一个很大挑战——既要修正上线后发现的Bug,又要继续为其它品牌添加新特性,且这些特性暂时不能反映到已上线的品牌中。我们并不愿意为这种多品牌开发的业务创建分支版本,因为它对于版本维护而言,无疑是一场灾难。因而,我们决定选择特性开关来解决这个问题。


  • 条件式特型开关会对现有的业务结构产生影响

清晰的业务逻辑,简单的代码结构是保证项目可维护性的基础。如果特性开关的添加使业务逻辑变得复杂而不易理解,那么特性开关就在一定程度上破坏了项目的可维护性。

  • 添加特性开关前的代码如下:


  • 添加特性开关后:



可以看到,简单的条件分支虽然实现了特性开关——部分代码只有在满足条件时才会执行,但却破坏了原有清晰的业务结构⋯⋯


  • 当前程序中如果已存在了某些类似特性开关的判断,条件式特性开关会造成逻辑混淆

    添加特性开关前:

  • 添加特性开关后:

可以看到,新加入的条件式特性开关 brandA.isActive() 与原有业务判定逻辑 currentBrand == brashA 十分相似,很难区分,在使用过程中更是特别容易混淆。更糟的是,随着项目的不断深入,越来越多的条件式特性开关会被放置在代码中,代码中会充满“坏味道 “,使得混淆的情况进一步恶化!

  • 条件式特性开关并不具有可扩展性

    条件式特性开关通常只是简单的条件判断,并不具有可扩展性。添加第一个条件判断与添加第十个需要写同样多的代码,并且随着判断逻辑的增多,会令添加代码所用的时间和维护成本持续增加。

    例如:

  • 当需要移除特性开关时,我们必须删除代码

    例如:

通过上面的分析,我们可以看出简单的条件式特性开关对于我们的项目并不是最好的选择。那么我们所期待的特性开关应该具有那些特点呢?更多精彩内容,请阅读原文。


作者简介

孟宇,现任ThoughtWorks公司高级咨询师。具有十年商务软件开发经验,精通Java与DotNet开发,多次应邀到客户现场,指导客户团队的开发与改进。也因此,在大型遗留系统的改造方面积累了许多经验。 熟悉的业务领域包括:保险、金融、能源与通讯。


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 FaceBook推出的Android图片加载库Fresco 产品发展部简介 Android 极简反射教程 淘宝技术部世界杯算法大赛赛况 Java的不同版本:J2SE、J2EE、J2ME的区别