自从我学习了面向对象，我就好像掌握了一个得心应手的工具，感觉在处理各种问题的时候无往而不利，虽然偶尔也会有些迷惑，但是终归无伤大雅。这样二了一段日子以后，我终于接触到了设计模式，以及有机会见识了一些真正复杂的项目，发现面向对象很多时候，都是一种艰难地抉择。于是，对面向对象开始有了敬畏之心，并一直认真地思考这里面的问题，认认真真去实践面向对象设计，分析别人的写的代码，越发感觉到还有很多路要走。

习惯了用对象思考以后，一旦有实际问题要解决的时候，已经习惯了按照面向对象的思路开始思考，直到最近。在项目中遇到了大段的面向过程的代码，以及贯穿在其背后的设计思想。心中很不以为然，轮到自己操作的时候，还是用上了面向对象的方法，今天我和同事聊起这个问题的时候，我还是换位思考了一下，才明白了面向过程远没有我想象的那样不堪，以及那样容易。

其实面向过程的设计思路，说白了就是自顶向下，逐步求精。但是这么简单八个字，如果放在一个函数里，估计初学写程序的人，也是可以驾驭的，但是如果放到一个数万行代码的项目里，驾驭起来远超想象的困难。我为什么厌恶面向过程的设计方法，我仔细反思了一下，可能根本原因，还是我没法在数万行代码的项目里，很好的驾驭这个方法，已经搞不清楚应该先干什么后干什么了，很容易把事情搞得一团糟，所以才不喜欢这样做。

在稍大的项目中，第一个面临的问题，就是分工合作。而这也是我认为面向过程方法能带来的主要好处所在：第一，项目开发人员水平良莠不齐，有些人懂面向对象有些人不懂，有些理解深刻，有些理解浅薄，有些干脆不会；这种情况下，面向过程的方法最容易推广，也容易掌控，分工下去以后，面向过程其实就是写好一个个函数，最糟糕就是某些函数写得漏洞百出，但是仍旧能够掌控，修复的时候，总也还有办法；第二，利于任务分解，只要想好整体的业务流程，按照功能往上堆叠代码就好了，每个人一块，只要搞清输入输出，就可以开工动手；第三，平行扩容，这个说的是团队扩容，项目发展过程中，需求难免快速变化，如果在紧要时候，难免人手不足，这个时候迅速抽调人力，扑倒项目上，马上就可以着手，只要看清楚function specification，就可以立刻贡献力量，整个团队会因为人手的变多，实现生产力提高；第四，健壮性好，出错的往往只是函数，修复即可，牵一发而动全身的情况少。

要实现我说的这些优点，其实还是非常困难的，需要思路非常清晰的技术领导，正确把握设计流程，关键处把关。所以，我说我驾驭不了，就是这个原因，不知道关键点在哪里，也难以有相当的技术敏感性来预知问题。

劣势是什么呢？第一，代码复用性差，因为设计不可能精细入微，所以代码难免抽象有限，出现大量的重复，比如遍历某个数据结构，因为是通用数据结构，也是和别的函数传递消息用的，免不了每个函数都要去遍历一次，这也是没有办法的事情，要实现不重复，可能设计上的要求要提高一个数量级了；第二，代码混乱，因为分工，乱序能力强，带来的弱势就是，代码会比较混乱，比如顶层和底层并行开发，导致顶层开工的时候，底层还没有就位，不得不先用一些替代方案，等到底层好了对接发现有偏差，不得不打一些补丁代码来修复，最后结局就是混乱；第三，一致性差，因为最小单位是函数，局部变量的要求不高，所以会在代码里看到各式各样的局部变量。

这些劣势都是很容易出现的，因为这是这个方法论本身的缺陷。

面向对象的好处是一开始，就强迫大家用逻辑性比较强，高内聚，低耦合的思路去思考问题，代码的内聚度高，可重用性好，重复少。然后，代码总量会降低。容易写出思路比较清楚的代码。

劣势也是相当明显的。第一就是没法在团队中很好的推广，对每个成员要求比较高；第二，不利于任务分解，因为面向对象设计任务更加繁重，如果要任务分解，势必要确定接口，如果没法很全面地定下接口，那上下游分工就比较困难；第三，扩容难，因为代码对全局观要求比较高，临时加入项目的人，因为没法全面了解所有对象的功能，势必上手比较慢；第四，就是设计上的失误牵扯会比较广，因为都是对象间交互，如果一个对象有问题，牵扯到上下游都要改。第五，代码逻辑内聚度高了，但是业务逻辑代码分散了，比如MVC，同一个业务逻辑相关内容，数据在M里，展现在V里，控制在V里，改一个业务逻辑，最优情况，是改三个文件，事实平均情况下，远高于三个，一般都是4、5个或者8、9个。

我最后想说的就是，一群人做事和一个人做事是很不一样的，你不得不顾及到整个团队的情况，兼顾每人的能力，偏好。人越多，越难兼顾。还有就是在实际项目开发中，很多东西都要受到限制，这非常糟糕，但是没法对抗。不得不考虑各种因素。如果一味地只考虑方法论本身的先进与否，一味地考虑自己的偏好，可能你离一个技术领导的距离还是比较遥远的。做个小兵容易，领导团队困难啊～

就是一点个人领悟，有点语无伦次，以后闲下来，再好好整理，诸君见谅了。

您可能也喜欢：
工作中常用的Linux命令集锦	Yii框架的Log系统的分析	给SVN客户端配置代理服务器	【边学边用】PHP5函数参数的按引用传递	关于Push Mail的种种
无觅

执行结果如下：

然后再看一个普通变量的引用传递的例子，这个例子里面使用的是原生的整型变量，然后函数changeInt的函数声明里，也用一般方法声明参数，普通的调用，我们发现函数不能改变$x和$y的值，这符合我们的预期，但是第二个形式的调用，就是传参数时候，带上引用标志&，结果我们发现，$x和$y的值也改变了，这是为什么呢，跟上面的例子是一个原因，函数的形式参数a和b其实是$x和$y的引用的拷贝，所以a和b也指向x和y，所以，a和b可以改变x和y的值。再看最下面的一种形式，这种是我认为的真正的按照引用传递参数。非常的绕乎对吧？我也觉得如此，确实太过灵活了。确实不利于学习和理解，代码也不容易维护，如果真的想用引用传递参数，推荐用最底下一种方式，明确告诉调用的人，这里其实是引用，千万别用changeInt(&$x, &$y);这种形式，这个代码散步在各处，将极难定位bug。

您可能也喜欢：

Dedian 5的PHP包缺少readline支持

PHP 5.3.x中弃用的特性 Deprecated

工作中常用的Linux命令集锦

[Tips] PHP中return的用法

视频教程：使用Yii框架开发Blog

无觅

据官网介绍，还有据同事ishow的描述，ExtJS 4.x 是一个变化很大的版本，相比已经应用广泛的 3.x 来说，变了很多、新特性也很多，MVC就是它提供的新特性之一。由于我最近半年都在学习MVC模式（主要是使用Yii框架），所以这个名词更是引起了我浓厚的兴趣，这几天都在官网上看这个框架MVC的例子，直到今天，总算是摸着一点门道，于是画了上面那个图。这个四不像的图，是我个人对框架的理解的第一个具体化产物。

下面简单描述一下这个图。

1. 每个应用都有一个实体，就是Application对象实例，而每个应用同样也采用单一入口结构，有个快捷函数就是Ext.application({config})，创建一个Application对象实例，并且运行它；这里行为表现和Yii框架的Application看起来很像，创建一个实例，然后run；

2. Application在创建之初，会去加载Controller类，加载完毕后，会正式的lunch；

3. Application在lunch的时候，会创建一个Viewport对象实例，这个东西就像一个骨架一样，上面可以拼装各种View，具体说，就是各种布局形式和窗体控件，可以说是应用界面的载体；

4. Controller的角色完全是个粘合剂，它在加载之初，会帮忙加载跟其有关的Model，Store，View类，而其真正的作用，是通过一系列的事件处理函数，确定了每个View上面界面组件对用户交互行为的响应方法，可以说是一堆事件处理器函数的集合；这里面主要通过一个control成员函数来进行事件绑定，通过另一个叫ComponentQuery的组件，使用类似css selector的语法来定位界面上的组件，并为其绑定事件处理器；

5. Model是对抽象数据的具体化，或者可以这么理解，就是数据库里面的一行记录，到底是怎么变成一个对象的，将数据库字段变成了对象的属性的对应关系；而这里比Yii框架MVC模型多出来的东西，就是Store这个东西，在Yii框架里面，有强大的ORM系统，还有强大的AR将Model直接连接到了DB上，数据一出来就直接变成了对象，而在ExtJS框架中，代码全在客户端，势必就出现了透过网络来加载数据需要，而我认为，Store就是对通过网络来加载数据的过程的一个抽象，Store依赖于Model，通过关联的Model对象来获知如何将取回的数据对象化，以方便View展现，所以View是依赖Store对象的；（这里岔开一点，感觉这个Store的设计理念或许可以借鉴，由于某些原因，我们在使用PHP框架的时候，不能让Model直接连接DB，是不是也可以把数据取回最终拼接成Model对象的这个过程给抽象化成类似ExtJS中Store的这套机制呢？）

6. View就纯粹是一个界面组件，或者说窗体控件的集合，通过Store来加载数据并且展现到界面上，界面控件的响应都写在Controller里面，View对Controller的存在全无所知，也没有代码上的依赖；

总结一下，感觉这套系统的好处是在于，将View和Model都给抽象了出来，以至于它们可以更加好地被复用，做好一个面板，所有的地方都可以调用，而真正业务逻辑又被很好的封装在了Controller里面，这样也便于去模块化地开发系统，基本感觉上，是一套非常优秀的框架，由于我对ExtJS 3系列版本，没有任何经验，也就没法做出其相对于先前版本是否有质的飞跃的判断，通过仔细的挖掘，我发现其易用性上确实比我原来想象的要好，开发人员可能没太多必要去纠结于内部原理，只要理解到跟我现在差不多的样子，就可以快速上手去做一些东西出来，当然还是必须看着文档按图索骥的，嘿嘿:)

您可能也喜欢：
MVC就是个选择题	MVC最佳实践	Yii框架的Log系统的分析	Google可以搜索Twitter的内容了	Join PayingPost and Earn Money Now!
无觅

特意开辟这个文章，用于收藏一些工作中常用的操作，主要有这么几个原则：

1. 非常有用
2. 不常用
3. 每次用都想不起来应该怎么用

不知道大家是不是经常跟我一样有这种感受呢，我会把我遇到的这类操作，都详细写在这里。

将配置文件中的指定列前面加上注释符号

如上代码是一个很常见的配置文件，我现在要给第2-12行前面都加上一个#号，注释掉他们，在EmEditor里面这个事情无敌简单的，但是到了vi里面，你是不是总也想不起来应该怎么弄？

解释一下，【2,12】在vi中叫range，看帮助的时候，如果看到range，这就是一种写法，表明第2行到12行。
还有一种写法：

将光标移动到第二行，然后执行上面的命令，后面的【11】代表，执行这个命令，重复11次。这里一直没解释里面那个至关重要的乱码串，那个就是替换的命令了。下次再说。

删除的时候使用f和t

删除是vim里面非常常用的功能，一个一个字幕删除，用x，可以代替del用。整行删除，dd，应该都会了。删除一个单词，用dw。这些都是简单提一下，我主要想两个很好用的功能，就是f和t。

f的本意是行查找，fa，就是从光标当前位置开始，在本行中，找到第一个字母a，和d结合起来以后，就非常方便了，比如：

在这个代码里，你想删掉第一个参数，可以把光标放在(后面的第一个$上，然后按”df,”，就可以把$a连同后面的逗号都删掉，非常方便。当然了，你可以发挥一下，”d2f,”这个按键序列就是把$a和$b都删掉了，但是呢，用数字这种东西，在实际操作中，我感觉大脑经常反应不过来，需要思考，不实用。

在来说一下t，t这个东西，跟f非常像，区别就是t把找光标放到找到的那个字符前面一个位子，比如上面那个例子，我把光标放在第一个$上，然后按下”dt)”这个序列，可以把函数的3个参数都删掉，但是却不会删掉括号，非常舒服，在括号里删东西，我经常用这个功能。

您可能也喜欢：

Vim最低配置单

工作中常用的Linux命令集锦

Mac OS X上如何实现到Linux主机的ssh免登陆

[Tips]Word2007中看不到图片

【边学边用】PHP5函数参数的按引用传递

无觅

我自己经常使用的是另一款SVN客户端，不知道国内有多少用户，总之我也提一下吧，下载的网站是这里：http://www.collab.net/，这家公司是SVN的幕后支持公司，他们开发基于命令行的各种操作系统的客户端，基于命令行，所以就非常的轻巧，最关键是装好以后，可以和NetBeans无缝集成，也不会弄一堆花花绿绿的图标在资源管理器里面，让你看了红色惊叹号凭空焦虑。

给这个命令行客户端设置代理有点纠结，看不明白的童鞋，自动忽略好了。首先打开CMD，然后键入命令echo %APPDATA%，得到的结果，就是你的配置所在的根目录，进入那个目录，然后进入Subversion子目录，你会看到两个配置文件，一个叫config，一个叫servers，用写字板编辑那个servers的配置文件：

配置好后，就可以实现给SVN客户端挂上了代理，如果只想给特定的域挂代理，就使用另一个section来配置代理：

如上只是我的配置的一个节选，是我给googlecode这个域配置了一个代理。

您可能也喜欢：

在WinXP上搭建自己的SVN服务器

工作中常用的Linux命令集锦

VIM常用小窍门收集

面向过程与面向对象

Yii框架的Log系统的分析

无觅

tcpdump就是大家嘴里常说的抓包工具，在linux命令行下，使用tcpdump，可以查看服务器特定端口进出的数据包内容。
tcpdump -X -s0 -i any udp port 12009
上述命令是我在工作中常用的一组参数组合，其含义如下：

• -X 将每个包打印成16进制形式和ASCII形式，调试新协议的时候非常方便
• -sN 每个包显示的（截断）字节数，N代表字节数，填0代表64K，为UDP包最大长度，实际实践中UDP包长1500字节左右，如果调试的协议只关心包头，一般查看前128个字节即可，可以视情况而选择。
• -i 代表interface，可以认为是网卡，any代表任意，也可以填eth0，eth1，代表以太网口
• udp port 12009是表达式，例子的含义就是UDP协议，12009端口。

tcpdump [ -adeflnNOpqStvx ] [ -c 数量 ] [ -F 文件名 ][ -i 网络接口 ] [ -r 文件名] [ -s snaplen ][ -T 类型 ] [ -w 文件名 ] [表达式 ]

如上是tcpdump命令的完整格式，具体每个参数的含义，可以参看linux的man。

这里简单谈谈最后的那个“表达式”，这个表达式的写法是非常灵活的，使得tcpdump像一个可自由编程的调试工具一样，强大异常。这里可以把表达式理解成是一种编程语言的语句。

1. 表达式 = 语句 语句 语句 ……
2. 语句 = 修饰符 | 修饰符 内容

不知道我上面的描述方式，是不是说清楚了表达式的结构，表达式是一个又一个原语（primitives）组成的，每个原语又是由修饰符和数据组成。数据可以数字或者id或者ip或者range等。

修饰符有很多种：

1. 类型–可以是host（后面跟主机名），net（后面跟ip地址），port（和面跟端口号），如果不指定，默认是host
2. 方向–可以是src，src or dst，src and dst，dst，主要是源端还是目的端，如果不指定，默认是src or dst
3. 协议–就比较多了，常用的就udp和tcp，其他的可以看参考

现在再来看看我给的例子，udp port 12009，表示使用UDP协议的，通过12009端口的（进入和出去的）包都显示出来。

tcpdump这个工具还是比较难以记住的，Charels觉得还是要注意理解这个命令的功能和原理，然后在用到的时候，才能快速的找到准确的用法。

netstat —— 打印网络连接，路由表，网络数据统计等功能

netstat是Linux服务器上最常用的命令之一，一般我总是用这个命令来诊断一些问题：mysql是否已经成功启动？web server是否已经成功启动？哪些进程在侦听哪些端口，建立了哪些连接？
netstat -npl
这是我最常用的参数组合，n代表使用数字，哪个进程在哪个IP上侦听哪个端口，你看到的结果列表里，是192.168.26.128:3306这种形式的，这个例子里是mysql正常启动的状态，一般mysql启动后，会有一个进程侦听在3306端口上，如果不是用n参数，netstat会试图找出主机和程序的名字，会显示成localhost:mysql类似这样。
p代表program，也即程序，到底是哪个程序在侦听端口呢？这个进程的id是多少？就是用这个参数来显示的。所以，np一般一起用，前面用n现实IP，后面用p显示程序的名字。
l代表listen，代表让命令只列出正在侦听端口的进程，对于那些不活跃的则不显示，与l相对应的参数是a，代表all，表示列出所有的socket，不管是在侦听还是没在侦听的。
其他的参数还有很多，比如i可以现实所有的网卡，s可以现实所有包的统计，但是因为使用场景较少，我就不介绍了，大家可以自己去看man，不爽看woman也行:)

lsof —— 待续

您可能也喜欢：

Mac OS X上如何实现到Linux主机的ssh免登陆

VIM常用小窍门收集

[Tips]Word2007中看不到图片

NetBeans 中我选用的插件

面向过程与面向对象

无觅

system.logging 包类结构图

首先，来看一下这个图，这是Charles昨夜工作的结晶，研究了logging目录下一共九个文件中的类的关系。YiiBase，Yii，CWebApplication不属于logging目录，但是为了说明这些类如何发生作用，也放在了这种图里。我的初衷，是要画一张标准的UML图的，无奈于本科的知识都还给老师了，所以这个图只能算是个四不像，大家凑合看一下，后面我会给自己补补课，后续的文章画得图会趋于规范的。

言归正传，左下角的类CLogger，是在开发过程中，打log时候，真正调用的类，这个类作为所有应用最最基础的组件，被包含在了YiiBase中，任何时候，在代码中调用Yii::getLogger()函数，会得到一个CLogger类的实例，这里用的是一个单件模式（Singleton）。打印log，只要调用其log()方法即可，这个方法有三个参数，第一个是log的内容，第二个是级别（warning，debug，fatal等），第三个category，可以叫类别，也可以视作是一种标识符，可以用于log的过滤。

上面的代码片段给出了一个打印log的范例，任何时候想打log，只要这样写就好。从上面的代码片段中，我们看到，log系统的调用接口是极其简单的。接下来分析一下大家非常关心的，log到底会被怎么处理的问题。

在框架中这个log系统里，负责打log，和负责记录log的是两个对象，他们被很好的解耦合了。CLogger扮演了一个专门生产log的角色，其任务就是将用户使用log()函数记录的log放到一个数组里，可以认为是一个内存buffer，长度可配置。在buffer满了的时候，会激发flush（如果配置了autoFlush）的话，flush就是冲掉的意思，如果内存buffer满了，则清空之，继续接受log信息。在清空log buffer之前，这个类对象会触发一个事件，就是onFlush事件，后续其他的类hook到这个onFlush事件上，就可以在log信息被清空之前，有所动作了。

这是一个生产者与消费者的故事，以上讲述的是生产者的故事。接下来，讲消费者的故事。CLogger已经在内存中生产了log，那么接下来就要来收集，分析，处理这些log，该记录的记录，该抛弃的抛弃，该报警的报警。当然，你可以不给系统提供消费者，那些log产生了，然后消失了，基本不会带来什么负载和泄露，轻轻松松。

log的生产者是系统中必然存在的，但是log的消费者不是，是通过配置文件配置到系统中的，打开位于/protected/config/main.php的配置文件，在components段，我们可以看到关于log组件的配置，如下所示：

负责采集处理log的真正对象，是一组以Route结尾的类，在上面类图中，位于右上角的那5个类。它们各有个的功能，发邮件的，写文件的，写Db的等等。前面也提了，对于一堆log，可能各自要使用不同的方法处理，比如debug信息抛弃，info信息记录在文件，而fatal信息发邮件给管理员，一个系统中很可能有这样那样的需求。所以，被以组件形式装进应用中的，并不是Route，而是类图中叫CLogRouter的对象。

对log的各种处理方法，都继承自一个叫CLogRoute的抽象类，提供了统一的调用接口，CLogRouter就是这些route的管理者，它主要负责的就是在onFlush事件发生的时候，把CLogger生产的log都接过来，然后，逐一地交付给自己旗下的Route们，分别处理。从上面的配置信息里，我们可以看到，LogRouter管理多少个Route也是通过配置文件配置的，也即route是router所依赖的组件。在具体开发过程中，你可以只配置一个，也可以配置一群。这种行为特征，真的有点像路由，怪不得叫router和route，我猜就这么个解释。

在操作实践中，我们完全可以自己继承CLogRoute，实现collectLogs方法，可以开发譬如名为NetLogRoute的类，将log从网络端口上以UDP包或者通过TCP连接形式发送到网络上专门的log服务器中，也可以开发名为MobileLogRoute的类，用来给管理员发送手机报警短信。

上面一直没有介绍到的Filter，其作用其实可以顾名思义，就是在log处理的时候，过滤用的，可以根据前文提到的category参数来过滤，也可以根据log等级类过滤，等等等等。Filter也是通过参数配置的形式被插入到route中的，完全可以创建自己特有的filter通过配置来替换默认filter，可以说，将灵活性发挥到了极致。不过，灵活还是有牺牲的，比如我就觉得，如果一个router下面挂上N个route之后，每个route都采用特定的filter，则会造成同一批log（10000条）被过滤的N遍。所以，比较好的模式，可能还是一个router，下面一个route，然后可以选择用或者不用filter，挂多个虽然理论可行，但是从实际代码来看，可能有一定性能损耗。

好了，终于啰嗦完了，最后问个问题，整个logging系统的这种结构，到底是哪一种设计模式呢？欢迎交流哈～

您可能也喜欢：
视频教程：使用Yii框架开发Blog	Yii框架中验证器的allowEmpty属性	Yii框架base包代码分析	使用Gii时出现403错误	面向过程与面向对象
无觅

当然，我不是在批判MVC，只是觉得，在使用MVC过程中，还是需要投入更深入的思考，到底怎样才能用好这个设计模式。MVC给我的感觉是，要求使用其的开发者有更高的觉悟，来正确选择存放一段代码的地方。从而实现解耦合，代码复用，和易于维护。为什么说使用MVC会有成倍的开发时间，主要就是因为在开发中，我们需要更多的时间去思考，这些代码放在哪里更合理一些。在MVC框架下代码被切割成一个又一个的小文件，分散在复杂的目录树中，那么到底怎样选择把代码写在哪里呢？这道选择题，并非有看起来那么容易。就我个人感受而言，更多的时候，无论将代码放在哪里都可以正确实现你的逻辑，MVC不是什么神兵利器，并不能通过其模式本身的约束，将开发者导入到一个正确的轨道上，反而会因为开发者本身错误的选择而让MVC自己变得一团糟。所以说，当一个团队确定要在一个项目中引入MVC时候，应该思考一下，每个团队成员是不是真的都有能力驾驭，如果没有对应的能力话，是不是要考虑前期对项目成员进行一定的培训。

可能我说得话很装逼，但是我绝对不敢以一个专家的身份站到这里来说话，我只是一个初学者，我要把我的学习感受说出来。现在回归到MVC上，Controller给我的印象是一个协调者的形象，它知道谁能干什么，然后分配任务，构造哪个对象，初始化哪个视图，是Controller应该决定的事情。Model呢，应该是一个实干家的形象，负责所有肮脏而又细致的事情，所以我在编码实践中，将所有的业务逻辑都塞进Model里面，对Controller，提供一个简单接口，对Views，输出纯数据。View则是一个消费者的形象，给其的数据都是纯粹的，直接显示即可以。以上是我对MVC这道选择题给出的一个答案，当然我不是很确定这样做很对。

我在项目中就看到过这样的代码，将Model做成了一个工具箱，实际上是一个有各种方法的对象，每个方法看起来也提供了简单的调用接口，实际跟Controller配合时候呢，由Controller来操纵功能，安排各个方法被调用的顺序。这等于是由Controller来执行业务逻辑，但是却又对其封装了每个步骤的细节。而我个人倾向于连业务逻辑也对Controller封装。这两种选择各有优劣，而实际上从短期也难看出来谁更胜一筹。甚至，等项目上线后，最终也没法发现哪个做法更优一点。

所以说，MVC真的就是一个选择题。你有多重选择来实现同一个目的。我列举的例子只是九牛一毛，在实际项目开发中，还面临着更多的选择问题。我想，到底怎样交出自己的答案，还是应该在实践过程中不断积累，不断优化。我们只要把握好一些原则，就可以让自己不要偏离航向太远。第一，可维护性，代码逻辑一目了然应该是写代码时候的第一追求，因为看别人的代码是非常痛苦的，甚至最后回头来看自己写过的代码可能都会很痛苦，保持代码一目了然才是最重要的，给别人，给自己节省下时间。第二，可复用性，写内聚度高的代码，减少依赖，判定很简单，我写的这个代码，拷贝到别的项目里，是不是直接就能用，时刻问自己这个问题，就能保持代码的高内聚度。第三，封装变化，这个原则总体来说很难把握住，我自己的体会就是尽可能提供一个强大的接口，如果XXX改变了，那么调用我写的函数是不是格式不变？如果你写的函数，一会儿增加个参数，一会减少个参数，那么所有调用的地方都会跟着变化修改。

就到此为止了，一些愚见，请大家指正。

您可能也喜欢：

MVC最佳实践

ExtJS 4 的MVC

面向过程与面向对象

Yii框架的Log系统的分析

VIM常用小窍门收集

无觅