一个程序猿

去年尝试开发了一个框架，开发了一半。或者说第一阶段开发完成。

为了开发这个框架，阅读了大量框架代码，框架思想，然后精心去调试了自己的框架。

在框架完成后，我并没有去使用。

框架的初衷是为了性能跟开发规范，而我在这个框架下兼职无法写代码，无法发挥。自从学写PHP，我从来没受什么规矩约束过，向来是自由度很高。而规则则是多年编程留下的一些经验。后来发现我的风格实在无法用框架来约束，所以放弃使用这个框架，依然按照自己的风格进行开发。

但反思，为什么有很多的框架在项目中应用－那就是规范。不成规矩，不成方圆。尤其在团队合作开发过程中，团队利益就高于个体利益。如果每个人能损失一点个人利益，那团队就可能拥有至高的利益。

因此，我又尝试开发了一套闭源自用的框架。其既集成了框架的一些模块化，规范化的理念，又适合程序员在小范围内自由发挥。后来我又加上了一些管理功能，通用模块系统，现在我可以在这个上边快速开发，又可以很轻松得把模块拆离重组。

内心我并没有把他当作框架，叫做程序“模子”会更好，感谢lamp群友给这么个名字。

其实我有两个框架，一个是比较简单的框架，适用于多人生产，只是拿出了框架的一些基本特性，便于由程序员自由发挥，又不缺乏一个基本的规则。

另一个是cakephp的“高仿版”，虽然是一个完整的框架，但学习成本高，另外扼杀了程序员的天性，所以，不再更新。

这次更新的是第一个框架，因为投入了生产，暴露了很多问题，这次的目标，首先是一个完善的框架系统，另外继承很多的应用实例。

另外一些LAMP应用脚本也会适当集成，当然得是拥有root的人才能使用这些功能。

主框架依然是PHP类库，路由，JS库（考虑是否集成JQUERY）

什么是框架：字典中框架指架构，骨架结构，框子，底座等，从字面意思，不难理解，框架指一个基础，而在程序开发中，框架指基于底层语言而逐步向上层应用进行的一些功能实现。其并没有实现具体的功能，而是简化了开发过程，任何模块中常用的功能都被框架进行封装或者扩充，给开发人员以最简的操作实现。

常用的PHP框架：Cakephp Flexphp Thinkphp

什么是脚手架：脚手架通常使用在框架的数据抽象层，数据脚手架可以很直观得给开发者或者使用者数据结构的表现。脚手架同样可以表现在一些具体应用上。但脚手架的功能只是把数据或者应用的最终结果能用简单的方式表现，但并没有达到最终的应用效果，常用在建模或结构设计的初期。脚手架的优势就是给最终用户一个直观的产品但中间并没有经过大量的开发，以减少需求变更所带来的反复开发。

常用脚手架：CI框架中数据脚手架

什么是应用资源包：应用资源包就是具体的应用了，比如bbs，blog，用户管理，资源管理等一些具体的应用。应用资源包侧重完成了一个完整的功能，而面向开发的应用资源包又提高了可迁移性，使一些项目的功能模块直接修改应用资源包的接口而达到快速开发。

常用案例：xoops中功能模块包。

简单使用了下CI框架，发现了不少技巧：在 Controller类中实例化了好多的类

然后在默认welcome的模型里print_r($this),那是一个密密麻麻阿，无数的实例化数据摆在这里，估计内存CPU消耗也是惊人。
当然，作者并不是没有解决这些问题，所有的类在实例化之后使用static的方式常驻内存中，在第一次加载后，响应时间明显缩短，我本地测试是否默认实例化如此多的对象速度没有明显的差别。
对于原来我写程序，其实是有洁癖的，或者是心理障碍，就是像写C一样仔细考虑每个变量和每个方法，计算操作复杂度，其实对于整个系统开发和PHP这们语言来说，这么开发其实是杞人忧天，因为PHP本身就可以处理这些问题，比如static方法，一些缓存。
在进行各种测试之后，我的类库居然也默认加载了一些方法，只是应用在小网站中。
对于大型网站，还是要充分考虑效率性能的问题。

最近一直在研究框架，翻阅了各大框架结构，最后总结出两点：性能和接口规范。
1、接口规范
框架的一大意义在于整合类库和资源，使用统一的接口和统一的方式进行调用，统一的接口又更加方便其他资源的整合，模块化的管理更容易对代码进行管理。这样，可以使得不同的开发人员形成一致的风格进行分工协作。
2、效率
框架在整合类库，判断路由的时候，毕竟消耗很多冗余操作。太多的类库加载也将耗费很多的内存和CPU，因此，框架开发的另一个要点就是要降低操作复杂性，降低内存消耗，在这个基础上有可优化性。

总结到这里，晚上继续玩命……

罗马真的不是一天建成的，不能不承认，那些框架作者在此花费的精力。我的框架只写了一个说明，两个函数，就已经尽兴不下去了，当然跟这几天的感冒有关，不过，更多的是我没有理清框架应该有的结构。

一个优秀的框架除了规范化大部分操作外，其在效率和性能损耗上做了进步一的改进，从而能够高效处理复杂的操作。

第一个自动加载类的函数，参考了下PHP手册关于引用部分，才发现自己原来写类的方法，是如何的消耗内存和CPU，任何一个方法的诞生都是有其目的的，不能认为PHP是神，但PHP毕竟比我强，因此我还是要相信这些我不熟悉的操作是有用武之地的。

第二个方法，是要定义URI路由，URI路由我会尽量使用逐一匹配的方式进行解析，但有些操作不确定变量数量的时候，简单使用正则。我正则不很强，但也对着手册也可以写，但我总感觉这玩意太费劲，大脑想着费劲，电脑做着肯定费劲。有简单的方式，为何用难的，难道只是为了省点代码空间么，没必要的。

不过说到底，正则这东西还是很有用，不能因为效率差而失去，计划写个分支，把简单的用模板匹配，复杂的用正则，皆大欢喜。

不过写之前，还是要大量翻看别人的东西。

最近在看一些框架，从zendframework，cakephp，IC，都大概了解了一下，因为以前习惯全部手工代码，但后来发现这种方式过于松散，松散到不能管理，因为类，函数，虽然有自己的方式整理，但每次开展项目的时候都得重新整理，重新配置接口，过于麻烦，于是想到了框架。

框架，其实是用程序管理类库的一种方式，采用统一的接口，统一的调用风格进行操作，对于团队合作中代码可读性提供了便利。但框架也有很严重的问题，就是效率。

框架大都采用了单点的入口，然后提供url的路由功能进行解析，另外，类的调用也大都采取__autoload进行寻找，大大降低了程序的效率。

后又看了奶瓶老仙的BSMlite，深有感触。

其实，使用框架完全可以应付中小型项目，至于效率，也可以在完工后进行优化再发布，这样就会达到两全其美的效果。