此文取自我框架升级日志中，算是我自己对自己说的一些话，这几天解决了几个框架升级中十分重要的问题，一时兴致，写下寥寥数字。
这篇文章引发了class & function之争，我已将 @ichenshy 的观点转发到讨论区，帖子在此《PHP的Class与function之争》。
效率和完整度、便利性，似乎是天生的敌人。这次升级，为此我没有少费功夫，底层的函数调用次数最多，我花了无数时间一次又一次的重构，代码写了又删，测试，觉得不满意，再改，改到最后发现思路不对，然后删除，再写。
现在包解析的函数，运行10000次，所需时间为180-200毫秒之间，这个算是我比较满意的运行时间，也已经无法再从中压缩更多的运行时间出来了。提升速度最主要的一个办法就是设置运行时的缓存，这时候我会很想念ruby on rails或者node.js这种模式的脚本，因为他们运行时常驻内存，而PHP每次请求以后都要重新初始化，所以这个运行时缓存无法持久化，同时，也逼迫你花更多时间去调整这些核心函数的实现细节。
其中运行较多的，往往是类型判断，这就是完整性和效率之间的考虑，作为一个底层的方法，你必须要考虑到执行这个函数时的各种可能性，而且为了性能，我们往往无法真的每个细节都照顾到。一个折中的设计思路，就是缩小风险发生的可能性，而后放弃一些验证，以使用开发的约定，说明文档来标识，不然你永远无法更好的提高运算的性能。
这时候我总会想到那些静态类型的语言，比如Java、Scala，他们函数的参数是指定类型的，并且允许基于不同参数类型重载方法，Oh亲，这对于值类型判断控来说，真的太重要了，因为在不同的方法体里，你完全无须顾虑，这个函数的执行结果是不是会完全失控走样，因为在这个方法体里，他只有少数的可能。而更多的可能，你完全可以用不同的参数类型进行重载，而且也可以很好的区分代码块，多么贴心的设计！
不得不说，值类型判断，这简直是编程语言设计上，一个十分坑爹的设置，尤其对于动态语言来说。即便如Javascript，也可以快速的通过typeof和instanceof来定位变量的类型。而且让你十分无语的是，PHP判断值类型居然是需要消耗运行时间……对于习惯了用Scala，全类型系统的语言我来说，这个真的是既好笑，又傻A的事情……更遑论，Scala那飘逸的类型匹配语法，相比之下，PHP就好像在玩小孩子过家家。
好吧，就是一点一吐槽！
autoload的实现接口，循环生成10000个不同class的条件下，能达到300毫秒左右的速度，这是我比较满意的结果了。如果以设计目标看，一个项目最多运行100次loadClass以内的话，就是4毫秒之内的事情。当然这还没计算每次import时候的算法，算上一倍吧，就是8毫秒，然后还有io方面的运行时间损耗。底层加载类库最起码需要花费10-12毫秒的时间。我想，这也就是PHP语言本身的极限了，除非我能把框架转换为基于C语言的扩展（我开发是在台式机i7 3770K windows 7）。
这不得不说是我内心的一个伤疤，2010年的时候，我是希望朝C语言扩展的方向去的，当时Max说，C写扩展，你确保不会内存溢出？这当然是个问题，但是有哪个类库不是一个一个版本这样更新过来的？2010年回mixmedia的时候，切莫说C语言写扩展，我也希望框架能升级出一个扩展性，灵活性更强的版本，这件事，也是拖拖拉拉的到今天才有大块大块的时间去进行。而当年回mixmedia之后，很快就被迫接受了wordpress了，C扩展，升级框架，几乎是南柯一梦……就这么拖了2年多，直到离开了mixmedia。
当然我不能说，是被mixmedia拖累了。自己是迫于生计，但是看到今天，各个基于C扩展的框架如雨后春笋般冒出来，心中的滋味，真的是酸酸的。再看去年年底，委曲求全，千方百计的将框架兼容到Wordpress中，各种艰辛、忍气吞声地向Jeremy介绍自己的框架。他当然是不接受的，事实上无论广州团队，Max、Sam、我，曾经做过什么项目，曾经为MixMedia付出过多少。尤其是后期我经手的项目，大到和IBM合作的RalphLauren，小到FTV、中美交流会.org.hk，几乎0bug、0严重的漏洞（设计不完善，再升级是有的，但都是在一个合理的迭代周期内，准时更新的），亦或者Sam对服务器管理、驾驭得如何纯熟。他从骨子里，压根就不相信这个广州团队，不信任这个团队的人做出来的东西。
这是一个悲剧，尤其对于一个程序员来说。这种感觉我压在心里良久，一面要自信满满的面对着下面的人，一面要和IBM的各路人马撑到底，而内心却总是恻恻不安，生怕哪天写了哪个程序出现重大的漏洞，这是很难对人言明的。
Jeremy给出的说法却是堂而皇之的，Wordpress是这个世界上第一使用量的CMS——我对他这个说辞还是持保留意见的，第一的博客系统，我不否认。他说，这样他在跑销售的时候，可以毫无顾虑，毫无掣肘。可是在开展国内业务的时候，他自己也承认，客户的技术负责人在开会的时候公开质疑Wordpress，也有人压根没听说——毕竟就是一个博客系统。与其说，Wordpress让他信心满满，不如说，他从头到尾都没有信心，既不相信广州团队的出品，也不也不相信任何人。
但是随着Wordpress爆出漏洞等，他也曾几次的质疑Wordpress，并且尝试寻找替代的产品，其中两次选择了WolfCMS，一次是发起全公司讨论卖砖头（Magento，这个我没参与了，因为当时已经宣布离职了），不过最终都不了了之。这说明他内心矛盾的冲突、各方利弊的权衡是如何的激烈，怎能不权衡呢，怎么说也用Wordpress走了2年多了，前后也有数10个网站了。
真的觉得很无语，mixmedia从09年开始，拿得出来的项目，全部是用框架的1.x，2.x版本制作的，轩尼斯、百威官网、某Club管理系统，这几个项目都是经历过大流量的冲刷洗礼，好像百威，09年底的第一届K歌之皇，最后一周投票决胜，流量超载（具体已经忘记了）。某Club的管理系统，定时轮训服务器查订单状态等，这几个是当年所谓的拳头项目，还有若干项目，也是用框架快速搭建的。09年底10月，我离开mixmedia，那些项目也依旧这么跑着。
但是进入2010年，这些曾经的拳头项目，纷纷闪红灯，只有百威项目，仍算运行良好。在2010年10月（离开整整一年）重回mixmedia的时候，除了百威以外的项目，其他项目全部进入崩盘边缘。我还记得那段艰苦、青葱的岁月，Zero、Sam和我和Max一起坐在一个小办公室里，每天都有处理不完的事情——不是程序的问题，而是补漏——那些漏洞与其说是项目、程序的问题，不如说是管理的缺漏。当时我几乎天天都在办公室里过夜，白天处理业务，晚上写代码。
回想09年时，几个项目初上马，公司大张旗鼓，网罗人才，投入项目运营的人数，与程序部门持平。可是到10年底，负责运营的人缩减到程序部门人数的1/3。而程序方面，在我离开的这一年间，除了百威和Club管理系统以外，人员主要都投入在开拓新项目上，而其他的项目，代码据我离开时几乎纹丝未动、毫无二致。
10年到11年春节前，公司斩断了除百威以外的所有项目，压缩运营成本、管理混乱（缺乏重视、尤其是第一代经理离职，和Max接任中间毫无任何交接工作）、程序又没有更新升级、缺乏照顾，斩断——是必然结局。在以后的2年间，Jeremy鲜少在众人提起当时的事，偶尔提起，眉宇间总有鄙夷之色，言辞中流露的是，当年程序员的错，当年程序的漏洞，云云。
在我09离开MixMedia后，进入了瑞寰，当时的赵总打算用Zend Framework做开发，因为我坚持要开发自己的框架，他决定给我这个机会，而且从各个方面给予了很多很多的支持。我并没有沿用在mixmedia时的1.x、2.x的基础，而是从零开始设计，因为最初的意图是，由Zend Framework做引导，而后加入我的框架做一个辅助库，但是从我的角度看来，当时的Zend Framework臃肿不堪（人家是设计来给自家的商业产品使用的），而且我也有这样的经验，所以我决定推翻原来的设计方案，框架运行时，用最少的类库进行引导，而且框架自身实现全部基础的控制，也包括ORM。而把Zend Framework作为一个工具库使用，保证框架能完美兼容Zend Framework的所有现成类库。得知改变了设计意图，赵总的第一反应是吃惊，不过很快就接受了，我真的很难表达对他这份信任的感激，以及他在工作上照顾。
重回mixmedia，我把这套框架带了过来，而且也做出相应的修改和升级。习惯上我们把这个版本称呼为3.1，虽然在命名空间上和1.x和2.x完全不同。
3.1版本在mixmedia经历的大小十多个项目，尤其是在老板公布了要使用wordpress以后，使用框架进行开发，就像是地下党偷偷摸摸干的勾当。我真的无法解释，用框架，比wordpress开发速度快了10倍之多，我也无法描述，框架是如何通过接口化编程，来约束团队成员的编程习惯，使得每个项目都能成为不需要文档就可以交接的无形文档。
2012年底，我真的觉得厌倦了，有些东西是无法用言语去表达的，压力、痛苦、对未来的追求，我对自己的出品，要求之高，把控之严，我不需要向任何人解释。
离开mixmedia数月，我已能安心的把大块大块的时间铺洒在框架的升级上，我立定决心，要做一个更彻底的升级——尤其是关键部分的算法与实现。因为在我看来，我将会慢慢的淡出PHP的使用，而转向Node.js或者其他，框架到今天，已经是4.0的版本了（之所以跨度那么大，因为基于5.4版本，而且比起3.1的架构，有彻底的不同，3.1之后，曾经有后续的版本，有实际项目经验的是3.5版本，之后3.6，3.7，3.8我都持续有开发过原型出来，但都不甚满意），有时候经验的积累，已经不在于具体的编码细节，或者语言的熟练度，而在于对整个编程行为、项目架构、团队运作等等综合因素结合为框架设计的出发原点。这已经不再局限于语言实现上，而是一个整体的、系统的、生态的结构性设计。我无法表达，我对底层实现的每一个细节是琢磨到如何细致的程序，只说我丢掉了一个又一个的版本，以求得那最满意的结果，而他最终的表象上，可能平淡，就是众多框架中的一个——而已。
之前有打算将升级的版本开源，包括将3.1版本开源，不过基于各种考虑，主要是mixmedia项目保护的角度，我会让3.1彻底的烂在我的电脑里。而新升级出来的4.0版本，计划在4月中完成第一个测试版本，他也将不会作为开源的代码发布，纯粹只会是我自己公司使用。其实在框架满地的今天，尤其还有那些用C扩展写的框架也不绝于耳，我并没有指望我的框架，要打败谁谁，要成为某某主流框架，我唯一的目的就是有一个自己用着趁手的兵器，而恰好自己能造这个兵器。
不过把握住效率、完整度、便利性的平衡点，我想，这是每个框架设计者，编码者都要认真测试、考虑的问题。框架，论其本身，不是为了包揽一切，而是应该提供更好的扩展性和灵活性，以兼容并蓄，包揽天下。同时，框架不是开发者的紧箍咒，良好的设计，应该能让程序员看看示例就能快速上手，并且切入编程角色，编写他自己所需要的类库。而在必要时，又能随手查到文档，找到那个最核心的接口……而不是失望的搜搜google，看看stackoverflow，然后准备动手改你框架的代码（我时常听闻，大家都在用某某框架，不过都按照自己需要改），这不是等于宣告了这个框架的失败吗？
7637
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
