软件开发随记之一 —— 添加功能开关

“你给软件新加的功能A不错，能够让系统的性能大幅度提升。”

“谢谢！老板，我会不断努力的……”

“可是，据测试人员说，有的时候它会导致系统不是很稳定。你知道，客户催得很紧急，他们需要一个稳定的版本。你看，你能不能暂时把这个模块屏蔽掉？”

“！@#￥ 好的，我可以在SVN上把代码回滚到以前的版本。可是，最近在源代码树上，又提交了很多不涉及模块A的代码，如果回滚，这些代码势必也要被去掉……”

“不行！这些代码是修复以前的BUG的，不能去掉。任务紧张，限你一天之内完成！！！”

于是，我只有不断地比较版本，合并版本，不断寻找编译的错误，同时还要不断地调试……真正的超负荷体力劳动。

以上的情形，在软件开发当中经常可以遇到。新功能和稳定性有时是互相冲突的。但是，客户的需求又是漂移不定的。作为开发人员，如何做到既不影响自己的进度，又能尽可能满足客户的需求呢？个人认为，通过给新功能模块添加一个简单的开关，在大部分情况下，可以很好地解决这个问题。添加功能开关有两种，一种是在程序运行时的动态设置开关，另外一种是在源代码编译时生效的静态开关。

1. 动态开关

在编译之后的代码里面就已经包含了新功能A，通过一个特殊的开关可以禁止或使能它（如果是应用程序一般是一个参数，如果是Linux内核模块可以通过proc文件来实现）。这样做的好处就是不用因为功能A来维护不同的发行版本。同一个版本，可以给不同需求的客户使用，减少维护开销。如果客户的需求变化太快，比如今天不要功能A，明天又要，也比较容易实现。

此方法不足的地方就是在涉及到功能A之处，需要用开关进行动态判断，以决定是否进入和A相关的代码。如果这样的判断太多，势必影响性能。不过，当CPU很强大且性能瓶颈不在于CPU的时候，这点影响一般可以忽略不计。

2. 静态开关

源代码中包含了新功能A，但是可以通过一个宏来关闭它。这样，生成的版本可以包含A，也可以不包含A。好处显而易见，到底要不要A，是编译的时候来决定的，运行时没有多余的开销，有利于性能的提高。

不足之处也显而易见，针对不同的需求需要维护不同的版本。且代码中宏太多，有时也影响可读性。一般来说，代码中纯粹用于调试的功能都是用静态开关来控制的，因为客户是不需要这些功能的，没有必要放到发行版当中。（为了解决客户现场的问题，必要的LOG信息等调试功能还是需要保留的。）

到底选择哪种开关，需要根据具体的情况来定。但是，加个开关一般都比不加开关好。现代软件开发越来越复杂，版本的维护有时会变成一种承重的负担，一个很简单的技巧，有时就可以给自己减负不少：）