宏开关和布尔开关地狱

最近开发的产品遇到了网络问题，很严重的网络问题，具体我就不说了，总之问题很严重，项目组有个哥们儿，看似很有经验，企图通过添加新的处理逻辑来解决问题，这个方式我本身就很不同意，因为遇到问题之后最好的办法就是找到问题的根源然后彻底解决，而不是在错误之上试图弥补，这哥们儿用了一招试图让大家觉得他很有经验，他害怕添加新的逻辑会引起新的问题，于是他用宏开关来控制他新加入的逻辑，一旦出现新问题他可以关掉他加入的逻辑从而定位问题。但是想象一下，这个做法实际上变成了整合他新加入的逻辑而不是解决原来的问题，一个又一个的新功能被加入了，一个又一个的宏被define，甚至出现了嵌套的define，嵌套的ifdef，过了大概一周，我想除了他自己之外，没有第二个人可以读明白代码的逻辑了，在他眼里，代码很清晰，然而在大家眼里却很混乱。

于是我开口了，我不能忍受陷入宏定义的泥潭，我明确反对了这哥们儿的做法，他还好说话，不再添加宏定义了，怎么修改代码呢？他引入了很多的布尔变量，试图靠布尔开关在运行时左右代码的执行逻辑，我只能苦笑，这实际上还不如宏开关呢，宏开关起码还是在编译期左右编译过程，好一点的开发环境比如vs2005可以讲未定义的宏包围的代码置为灰色，还不错，但是换成布尔开关之后，我们大家完全不知道了代码的处理流程，其实这是一个更大的错误...

当代IT业的基础是什么，是计算机和网络技术，后者的基础是什么，是布尔逻辑，我感觉那哥们儿适合做硬件，后来知道他以前是写汇编的，晕！高级语言的优势就在于可以是人们逃离布尔逻辑而使用人们惯用的逻辑来分析和解决问题，他倒好，又回到了布尔逻辑时代，不管是宏开关还是布尔开关，他好像对布尔逻辑很亲！这一点是软件开发的大忌，软件开发应该从整体上把握问题，然后试图用人的思维方式去解决问题，这正是面向对象思想的精髓，最重要的一点就是按照人的逻辑去解决问题而不是机器的方式，布尔逻辑当然很重要，它对编译器和cpu的设计更加重要而不是对业务软件开发...