Joyqi.com

最近看了些网络小说打发时间，没想到现在网络小说的水平真是每况愈下，本人有时候都不得不把它们当笑话看。还是比较怀念在学校看武侠小说的日子。去百度几个贴吧看了看，跟我有同样感慨的人还不少，现摘录一二，各位看官权当笑料

先来个现在小说中比较流行描述的皇者霸气

不知道大家看到这段话吐了没？

张大叔，我虽是张羽的师傅，可我今年才六岁，马上就要过年了，过了年我也就七岁，我就称你为张大叔吧！”我拱手淡笑着说道。

　　张狂看着我，他可知道他的儿子可继承了他自己的狂，一般人根本就不理睬，更不要说拜为师傅了，眼前这人单单以孩童的相貌就让自己的儿子拜他为师，看来真是高人。这张狂还是不相信张星峰是个小孩子，将他当作世外高人
我忽的一阵激动，从椅子上站了起来，坚决地对着张大叔说道：“张大叔，你放心，你和我们一起走，没有人可以伤到你，更不用说那‘宝玉祥’了，就是来十个‘宝玉祥’，我都不放在眼里！”我顿时仿佛傲视天下，的确，放眼天下，我作为一个修真者又怕了谁 ！一时我豪气冲天，自己的磅礴的气势自然而然地弥漫开来。

　　张大叔看着我，忽然眼前一阵迷糊，一股皇者气势扑面而来，眼前的小孩的身影变得越来越大，仿佛一座大山，让人无法仰视......忽然心中一股要向眼前的小孩膜拜的念头升起......蓦然，眼前一亮，眼前的一切又回复了清晰，别人可能以为是自己眼睛花了，可是依靠眼睛干活的玉石雕刻师，是极为地相信自己的眼睛的。因此他知道刚才的一切都是真的，而这一切的始作俑者就是眼前的小孩

我吃西红柿的《星峰传说》里的一句话，我看了当时就吐了

评论
....哎. 这还不算是太恶心的。还有一本小说张口闭口的就是王八之气。MLGB..哪来的这么多起。TMB气球啊。

Read the rest of this entry »

PHP界的开发热潮可以用风起云涌来形容了，最新的WEB动向都可以在这里体会到。在我上大学那会还是流行开发论坛，后来流行开发博客，最近似乎开始流行框架了。我们亲爱的水水同学也加入到这水生火热的框架开发大军中了，那么我觉得作为一个PHP开发人员，有必要谈一谈我对框架的看法，希望对这些框架开发者有些启示。

我大二开始接触PHP开发，毕业论文的题目就是《大型网站框架开发》。当然那个时候对框架的认识还是比较幼稚的，但是在实习公司CTO的指导，和大牛老覃的帮助下，对框架的认识开始逐渐加深。到现在已经过了“向世界宣布要独自一人开发出最牛逼，最高效的框架”的时期了，当然并不是磨灭了志气，如果说我有这种资源我还是会尽力一试的，这也就是为什么我一直在推进开源blog项目，因为我们团队有这个实力，我们肯定会成功。

但是框架开发并不是那么回事了，我自己开发过一个框架，那个框架真的完全是我一个人写，也就是现在Magike的前身。当时我心中真是把它当成世界上最好的框架了，执行效率尚可，代码布局规范，开发方便。但是在项目中总会遇到种种问题，当时我对自己的框架开始产生动摇，它毕竟不能解决所有问题，因此我开始在追求全面解决问题的基础上，修改框架，最后搞得身心俱疲，那个项目也以失败告终（当然失败的主要原因是市场运作，而不是技术上的问题）。我当时在这个公司做毕业设计时，公司的CTO告诉我，你只需要回答我一个问题，框架是什么？

现在回想起来，当时的回答可真够烂的，具体是甚暂且不表。经过多个项目的磨炼，我也接触了很多框架，对框架的理解也有所加深。我承认我目前对Zend Framework很欣赏，基本上要我开发项目，我的首选就是它了，自己也给它写了一些插件。现在让我用问答的形式展开此文

1.框架要解决什么问题?

对我来说，框架并不是要给我限制一种开发方式，一种程序结构，它就是帮助我们快速开发的，至于用什么结构，项目多种多样，我们可以自己选择。Zend Framework可以解决这个问题，他几乎包含了所有的PHP应用以及第三方应用支持，所以我选它。因此我并不要求框架给我提供一种解决方案，我只需要它能够根据我的需要组合出一个解决方案。Zend Framework是用package方式来组织项目结构，需要什么模块，只需要引用相关package就行了，也不需要关心依赖问题。

在此我要特别提醒各位框架开发者，目前几乎大多数开源的第三方库都是使用package模式来发布，如果你希望自己的框架能够快速扩展第三方应用，我觉得还是用这种方式来组织结构比较妥当。

2.中小型框架在乎执行效率，大型框架在乎生产效率。

这是它们所服务的对象不同所造成的，初学程序的同学会把程序性能看成头等大事，但当你经过了项目的洗礼后你就会发现，对于大型项目来说程序性能已经被放到比较次要的位置了，结构才是王道。现代计算机系统发展非常迅猛，很多在程序中性能提升的小技巧很快就会被淘汰，特别是像PHP这种脚本语言，最终计算机指令集与其语言解释器本身有很大关系，与其关心这些技巧，不如把注意力放到程序结构的优化上来。

我举一个很简单的例子，为什么在很多框架中都有数据库抽象层这个概念？如果你不理解它的意义，你设计出来的抽象层可能没有任何意义。在我看来数据库抽象层有三个意义

1. 减少SQL书写量，从而降低出错几率

2. 通过提供给开发者统一的接口，让Developer与DBA角色分离，即使数据库被更换，也无需更改程序

3. 缓存考虑

以上三点，第一点，对于小型框架来说一般开发者比较少，出了错可能也是你自己调试，因此基本这一条可以忽略。第二条也可以忽略，理由同第一条。第三条看上去比较重要，但是小型项目在数据库这一级用到缓存的机会比较少，也可以忽略。综上所述，小型框架里没有存在数据库抽象层的必要，直接上SQL吧，当然为了少写些代码，不用每次都要先query再fetch，也为了满足程序员懒得每次都connect数据库的愿望，还是可以简单得封装一下的。但也就是connect封装到__construct里，query封装到fetch里了事，不用搞得太复杂。

如果你想把数据库层搞得复杂点，可以达到另一个极致，现在有的数据库层已经可以直接绑定ORM视图，这意味者什么？意味着你在所见即所得设计工具里把数据库ORM关系映射设计出来，丢到PHP里面就可以直接生成Model了，不用管什么联动操作，因为关系里面都标明了。

可以说这也是一种发展方向，但PHP是一个解决实际问题的语言，它所有的函数都是为了解决问题才出现的，以前天天有人说PHP不够企业级，语言不规范，不是完全OOP等等。其实他们都没有看到PHP流行的实质，没有看到PHP草根的原因？这个原因可以用他们的问题来解释，也就是这个世界上非企业级的问题比企业级的问题多得多。PHP只是专注于它自己的问题，而恰好这个范围又比较大，门槛比较低罢了。

但PHP的学习者也不必担心，自己提高到某个程度后就到顶了，没有这回事，虽然说高处不胜寒，但也有无限风光在险峰一说。其实PHP是一门对系统工程要求比较高的语言，因为它的开放性，开发者需要不停地与不同的系统打交道，一般做过几年开发的，对服务器优化，数据库管理都比较精通。

3.不要盲目地选择框架，更不要盲目地开发框架

经常看到有人用"Hello World"程序来对比两个框架的执行效率。这样的对比是没有任何意义的，虽然大家都说没有意义，但是还是有很多人要这样比，因此我也不指望我说的这句没意义能像许三多那句这么有影响力。就我自己来说，选择框架主要看两点:

1. 完善的支持

2. 适合项目需要

为什么我把“完善的支持”放到第一点，因为从某种意义上来说如果你有强大的支持社区那么这个框架也可以和“强大”二字画上等号了，因此从这一点上来说zend framework是世界上最强大的php framework不为过。这种成熟框架的文档一般比较全面而且规范，它不会在一些无关紧要的问题上废话一句，而在那些可能会出现问题的地方则是详加解释，又是注释又是FAQ，从这里就可以看出开发者的素质。可能是自己性格问题，我实在是不喜欢在论坛上提问题等着别人来回答，也不喜欢碰到个问题就要和开发者联系，这样耽误大家的时间。

适合项目需要，当然也不必多提。杀鸡不用牛刀的道理大家都懂。

好了，杂乱地写了这么多，从头到尾看了一下好像又什么都没说，各位权当浮云罢

各位,约定一定会兑现...