框架: 用与不用

在最近的一个项目中, 与同事在是否使用框架上产生了一些分歧

在一个游戏项目中, 后台的同事主张使用他们非常熟悉的ZendFrameWork框架, 但我对此持保留态度;

由于对ZendFrameWork不甚了解, 我没有进行任何的建议, 直到后面我在做服务器性能测试时, 发现ZendFrameWork简直就是个性能黑洞,

尤其它的路由效率简直可以让身为CPPer的我抓狂; 

于是我拜读了这个高达50MB的超大类库, 不可否认, ZendFrameWork的野心很大, 基本上网站能用到功能库中都提供;

恩, 很好, 啊哈, 一部百科全书式的框架; 不过在研究过程中发现, 虽然在外边提供了灵活的定制机制, 可惜里面的代码大部分是过度臃肿,

内部相互耦合, 我想我明白它为什么会这么慢了, 做为一个脚本语言框架, 和ACE比体积, 我已经无力吐槽了;

这件事引起了我的思考, 框架, 用还是不用;

使用框架的优点:

1) 框架为程序员提供各种安全, 经过检验, 便捷的机制;

2) 框架本身是一个半成品, 在其支持的领域, 可以在上面扩展定制, 快捷的开发出最终的产品

3) 框架规范和限制程序员依照它的标准进行开发工作, 有利于项目代码的风格的统一

使用框架的缺陷:

1) 框架都是基于某种业务领域进行架构和设计的, 在其他领域中可能表现不佳, 或无法满足业务要求;

很多时候会束缚住程序员的手脚, 甚至逼迫程序员使用一些Hack手段来解决问题; 好吧, 兔子逼急了还咬人呢

2) 框架提供的机制, 对于不熟悉它内部机制的开发者, 就好象女人的年龄一样是个秘密;

3) 框架限定的不仅仅是程序员的规范和习惯, 还有可能限制住程序员的思维

4) 部分框架可能会污染你的代码空间, 尤其是你使用了一些它特有的机制, 当你发现不对劲想回头时

发现已经没可能脱离它了, 它绑架了你的项目; 虽然这个有前期调研时技术选型时的失误, 

但不可否认修正这个失误代价很高

5) 部分框架是买一送一的, 你得到你想要的同时, 你不想要的部分同样也附赠给你了, 而且还无法拒绝

结论:

并不是不赞成使用框架, 但是使用框架时要确定其设计时对应业务领域;

PS: 作为一个CPPer, 总是会有重新造轮子的冲动, 我会努力克制它的;