23
May
每个人的学习方式不同，写这篇文章的目的是分享一下自己的学习过程，仅供参考，不要一味的用别人的学习方法，找对自己有用的学习方式
经常在某些论坛和QQ群里看到一些朋友会问“怎样才能学好PHP，怎样才能学好***语言 ”，但别人回答最多的是：从最“简单”的开始。
这个简单也许真的不简单，呵呵。下面我想分享一下自己学习的一些过程。先说些费话，语言组织能力差，说了不少费话，愿意看的就看，不要骂我就行。
其实学习一门新语言并不是太难，重要的是你有没有准备好去学好它，时间的长短和个人的能力和决心有关。黑客界也流行一句话就是“没有入侵不了的计算 机”，这句话大概的意思是说：如果你的技术比维护这台计算机的管理员更胜一筹，那么就能拿下这台计算机甚至能拿下这个管理员管理的所有计算机，如果技不如 人，只能继续学习超过对方。我说这些话的意思就是让准备学习陌生语言朋友一定要下决心去学习，只要你下了决心去学了，就一定能学好，千万不要半途而 废。（退一万步来说，即使是没学好，但你懂的必然比别人多）
了解什么是最简单:
1、网页的基本构成就是html代码,所以必须熟悉HTML/CSS/JS等基本元素
2、熟悉PHP语法，了解PHP和HTML的运行方式，学习将PHP与HTML结合完成简单页面
PHP手册是比较好的入门老师
影响学习进度和程序强大是否的几个可能因素：
1、记忆力
一门语言的强大是否，应该看它的函数库和代码执行效率。每门语言都是有自己强大的函数库，要学好它，就必须得花很多的时间去记忆，良好的记忆力能使 学习达到事半功倍的效果。
2、数学和逻辑思维
这个当然不是绝对影响，因为看开发项目的复杂程度。小的项目不需要太多的数学和逻辑思维能力，但如果是开发类似于财务或大量运算相关项目，这一点就 是非常重要了。
3、有其它语言的基础
“一通百通”，这句话的道理也是不容置疑。都说有C语言基础的人，学习PHP比较容易，我没学过C语言，所以不知道这句话的效果
4、多看别人写的代码
学习别人的长处，补自己的不足，当然不完全为这个我始终相信：一个有组织的团队写出来的程序不会比个人差我PHP入门就是从看代码开始的，我喜欢看 别人写的代码 。(入门是从disucz,PHPWind和国外的phpbb看起，还有就是目前最流行的开源BLOG程序)，我尽可能的收集网络上的 PHP开源程序，到目前为止，我收集并下载的PHP开源程序有2GB大小,包括BBS，BLOG，CMS等。我下载并不是为了收藏他们，是学习他们的编程 方式和实现方法,如果自己想实现的功能不知道怎么去实现，我就会学习他们的实现方法，并不是抄袭代码，最终结果是想通过学习，将技术变成属于自己的ASP 我也是以同样的方式学习的(动易和讯的程序及其它ASP开源程序)
5、实践
理论固然重要，但实践必不可少。你理论知识再好，如果不实践，就不能看到理论所产生的结果或效果，并不能使你的记忆深刻，所以不能纸上谈兵
6、恒心
广告不是有句话是这样说的么：“世界上最高的山是自己”，这句话相信朋友们都能理解
过自己这关，其它的都好办
7、找对自己有用的学习方式
这条可以参照4，我的入门是从看代码开始可能有朋友会问：“一开始看那些强大的代码，你能看懂么？”我的学习方式是从“使用”找“学函数”：PHP 的函数太多，短时间不可能记住所有的函数，因为我相信，一个大的项目肯定会使用常见和必须的函数，找到这些函数，才会有重点的学习这些函数，难道你能说写 BBS的函数会写BLOG用的函数少么？难道会写BBS还不会写BLOG么？找对学习方式是要经过多种学习方式的尝试，所以这个只有自己把握，毕竟每个人 的学习方式不一样
8、尽可能的找视屏教程看
别人说十句，还不如一个操作看的明白，这个相信朋友们都有体会吧
9、从项目开始
一定要”逼”自己从写项目开始。任何一个高手的“成长”都是要经历一个过程，这个过程是一步步走过来的，来之不易很多朋友学习PHP的第一个作品几 乎都是“留言簿”，因为是最简单的程序了会写留言簿，也并不能完全代表你已经入门了，也并不代表就会了PHP，我自己开始想以一个“网络书签”作为自己的 第一个作品，但写了基本功能后就没继续了，感觉没多大意思。现在写一个完全正确针对企业的CMS系统，包括针对企业的一些常用功能，我想以这个作为自己 PHP入门的第一个作品
10、了解并学习和PHP有关的技术
真正的高手必须得学习和PHP关联的技术，要想学好PHP，就必须得学习数据库，PHP+MYSQL被认为是“黄金搭档”所以你必须得接触 MYSQL或你认为比较好的数据库，开始设计比较”合理”的数据库，这里的合理就比较广泛了，包括数据库优化和查询优化等等
最后想说的是：“不要依靠别人”没人愿意理会一个新手的提问，因为新手提问的在他们眼里太简单，不想去解释女性朋友很流行一句话是“男人靠的住，母 猪会上树” 引用这句话没别的意思，只是让朋友们知道这句话的意思
还想说的是：“珍惜别人回答的次数”人的忍耐都是有限度的，一定要珍惜这个限度，不要什么问题都去问，有些问题自己花点时间能找到答案的也去问，每 问一次，别人的耐心就减去一次，等你真正需要帮助的时候，正好是别人不愿意回答你的时候，可以想像一下，你失去的太多了
建议的是：“有问题？baidu一下”相信朋友们都已经注意到了，你问的问题，在搜索引擎里都能找到相关的提问，并且有详细的解决方案，你可以使用 搜索引擎来找到自己的答案，何必去问别人呢
目前最大的中文搜索引擎是 baidu.com ,全球的google,当然还有其它的搜索引擎，一个找不到，多试几个，除非你的问题是第一个提问的 ，那么你是幸运的，也可能是你“长相”问题，呵呵，说笑的，不要介意，不过这句话倒是挺流行
祝正准备入门的PHP的朋友能找到适合自己的学习方式，早日成功！！！
经常在某些论坛和QQ群里看到一些朋友会问“怎样才能学好PHP，怎样才能学好***语言 ”，但别人回答最多的是：从最“简单”的开始。
这个简单也许真的不简单，呵呵。下面我想分享一下自己学习的一些过程。先说些费话，语言组织能力差，说了不少费话，愿意看的就看，不要骂我就行。
其实学习一门新语言并不是太难，重要的是你有没有准备好去学好它，时间的长短和个人的能力和决心有关。黑客界也流行一句话就是“没有入侵不了的计算 机”，这句话大概的意思是说：如果你的技术比维护这台计算机的管理员更胜一筹，那么就能拿下这台计算机甚至能拿下这个管理员管理的所有计算机，如果技不如 人，只能继续学习超过对方。我说这些话的意思就是让准备学习陌生语言朋友一定要下决心去学习，只要你下了决心去学了，就一定能学好，千万不要半途而 废。（退一万步来说，即使是没学好，但你懂的必然比别人多）
了解什么是最简单:
1、网页的基本构成就是html代码,所以必须熟悉HTML/CSS/JS等基本元素
2、熟悉PHP语法，了解PHP和HTML的运行方式，学习将PHP与HTML结合完成简单页面
PHP手册是比较好的入门老师
影响学习进度和程序强大是否的几个可能因素：
1、记忆力
一门语言的强大是否，应该看它的函数库和代码执行效率。每门语言都是有自己强大的函数库，要学好它，就必须得花很多的时间去记忆，良好的记忆力能使 学习达到事半功倍的效果。
2、数学和逻辑思维
这个当然不是绝对影响，因为看开发项目的复杂程度。小的项目不需要太多的数学和逻辑思维能力，但如果是开发类似于财务或大量运算相关项目，这一点就 是非常重要了。
3、有其它语言的基础
“一通百通”，这句话的道理也是不容置疑。都说有C语言基础的人，学习PHP比较容易，我没学过C语言，所以不知道这句话的效果
4、多看别人写的代码
学习别人的长处，补自己的不足，当然不完全为这个我始终相信：一个有组织的团队写出来的程序不会比个人差我PHP入门就是从看代码开始的，我喜欢看 别人写的代码 。(入门是从disucz,PHPWind和国外的phpbb看起，还有就是目前最流行的开源BLOG程序)，我尽可能的收集网络上的 PHP开源程序，到目前为止，我收集并下载的PHP开源程序有2GB大小,包括BBS，BLOG，CMS等。我下载并不是为了收藏他们，是学习他们的编程 方式和实现方法,如果自己想实现的功能不知道怎么去实现，我就会学习他们的实现方法，并不是抄袭代码，最终结果是想通过学习，将技术变成属于自己的ASP 我也是以同样的方式学习的(动易和讯的程序及其它ASP开源程序)
5、实践
理论固然重要，但实践必不可少。你理论知识再好，如果不实践，就不能看到理论所产生的结果或效果，并不能使你的记忆深刻，所以不能纸上谈兵
6、恒心
广告不是有句话是这样说的么：“世界上最高的山是自己”，这句话相信朋友们都能理解
过自己这关，其它的都好办
7、找对自己有用的学习方式
这条可以参照4，我的入门是从看代码开始可能有朋友会问：“一开始看那些强大的代码，你能看懂么？”我的学习方式是从“使用”找“学函数”：PHP 的函数太多，短时间不可能记住所有的函数，因为我相信，一个大的项目肯定会使用常见和必须的函数，找到这些函数，才会有重点的学习这些函数，难道你能说写 BBS的函数会写BLOG用的函数少么？难道会写BBS还不会写BLOG么？找对学习方式是要经过多种学习方式的尝试，所以这个只有自己把握，毕竟每个人 的学习方式不一样
8、尽可能的找视屏教程看
别人说十句，还不如一个操作看的明白，这个相信朋友们都有体会吧
9、从项目开始
一定要”逼”自己从写项目开始。任何一个高手的“成长”都是要经历一个过程，这个过程是一步步走过来的，来之不易很多朋友学习PHP的第一个作品几 乎都是“留言簿”，因为是最简单的程序了会写留言簿，也并不能完全代表你已经入门了，也并不代表就会了PHP，我自己开始想以一个“网络书签”作为自己的 第一个作品，但写了基本功能后就没继续了，感觉没多大意思。现在写一个完全正确针对企业的CMS系统，包括针对企业的一些常用功能，我想以这个作为自己 PHP入门的第一个作品
10、了解并学习和PHP有关的技术
真正的高手必须得学习和PHP关联的技术，要想学好PHP，就必须得学习数据库，PHP+MYSQL被认为是“黄金搭档”所以你必须得接触 MYSQL或你认为比较好的数据库，开始设计比较”合理”的数据库，这里的合理就比较广泛了，包括数据库优化和查询优化等等
最后想说的是：“不要依靠别人”没人愿意理会一个新手的提问，因为新手提问的在他们眼里太简单，不想去解释女性朋友很流行一句话是“男人靠的住，母 猪会上树” 引用这句话没别的意思，只是让朋友们知道这句话的意思
还想说的是：“珍惜别人回答的次数”人的忍耐都是有限度的，一定要珍惜这个限度，不要什么问题都去问，有些问题自己花点时间能找到答案的也去问，每 问一次，别人的耐心就减去一次，等你真正需要帮助的时候，正好是别人不愿意回答你的时候，可以想像一下，你失去的太多了
建议的是：“有问题？baidu一下”相信朋友们都已经注意到了，你问的问题，在搜索引擎里都能找到相关的提问，并且有详细的解决方案，你可以使用 搜索引擎来找到自己的答案，何必去问别人呢
目前最大的中文搜索引擎是 baidu.com ,全球的google,当然还有其它的搜索引擎，一个找不到，多试几个，除非你的问题是第一个提问的 ，那么你是幸运的，也可能是你“长相”问题，呵呵，说笑的，不要介意，不过这句话倒是挺流行
祝正准备入门的PHP的朋友能找到适合自己的学习方式，早日成功！！！
23
May
你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原 则看成警铃，若违背了其中的一条，那么警铃就会响起 。 —– Arthur J.Riel
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存 在或者尚未发现的某个类中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但 不是必须如此。
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么，但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。
(41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
(61)不要绕开公共接口去修改对象的状态。
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存 在或者尚未发现的某个类中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但 不是必须如此。
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么，但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。
(41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
(61)不要绕开公共接口去修改对象的状态。
23
May
语法结构教科书上的知识和实际的程序设计是有区别的，真正的知识要在实际的开发中获得。每个php的开发人员在开始开发web应用程序之前，都应该 熟悉下面的五件事：
1. 框架
框架可以说是php开发中的一个最重要的问题。 用php开发web应用程序时有很多方法，有很多开源的框架可以使用，可以帮助快速的开发，保持更高的一致性和有效性。 其中比较好的框架包括cakephp ，Symfony和CodeIgniter 。很多框架还按照MVC设计模式 ，如果你在这个模式下工作过，那你一定会很熟悉。过一段时间，你甚至可以根据自己的需要来创建框架。
2. 模板引擎
如果您使用的不是一个框架来执行一个具体的设计模式，那么您想要使用的是模板引擎。不论你是自己创建或是使用现有的模板(如 Smarty)，模板引擎都会使你的逻辑代码从HTML页面中独立出来(以及相关的CSS / js /等)。 这大大的简化了你的代码，使整个程序的修改变得快速简单，也使非开发者更容易修改你的程序。
3. 代码重用
正如我先前提过的，php是所用语言中代码重用性最好的。从多中小的文档到整个数据库类，php开发者需要的时候可以随意的选择重用现有的代码。其 实，你几乎可以不用编写一行代码就能建立起整个应用程序。
4. 不重新开发现有的东西
很明显的一件事，只有少数的php开发者知道php本身有很多可用之处。忘记新的图书馆，或复杂的代码例程-先看看PHP手册。 例如，你们有没有听过number_format(), parse_url(), wordwrap()或bbcode_parse()?看一下整个函数参考 ，选择一个类别，浏览一下，您一定会有所发现。
5. IRC 是令人愉快的事
当你有个复杂的问题不能解决的时候，可以到IRC上。php非官方的支持频道，很多经验丰富的开发者陶醉其中。你需要一个IRC客户端，如果你用的 Firefox，ChatZilla是一个很好的插件，当你需要帮助时，以irc://irc.freenode.net/php做为头部粘贴你的代码。 张贴您的问题，并耐心等待;某种热心人(或多个)会给你答案。当你得到答案后，考虑一下其他需要帮助人的问题。对于php庞大的函数库来说，没有人是泰 斗;在IRC上，汇集所有人的知识就可以解决任何问题。
1. 框架
框架可以说是php开发中的一个最重要的问题。 用php开发web应用程序时有很多方法，有很多开源的框架可以使用，可以帮助快速的开发，保持更高的一致性和有效性。 其中比较好的框架包括cakephp ，Symfony和CodeIgniter 。很多框架还按照MVC设计模式 ，如果你在这个模式下工作过，那你一定会很熟悉。过一段时间，你甚至可以根据自己的需要来创建框架。
2. 模板引擎
如果您使用的不是一个框架来执行一个具体的设计模式，那么您想要使用的是模板引擎。不论你是自己创建或是使用现有的模板(如 Smarty)，模板引擎都会使你的逻辑代码从HTML页面中独立出来(以及相关的CSS / js /等)。 这大大的简化了你的代码，使整个程序的修改变得快速简单，也使非开发者更容易修改你的程序。
3. 代码重用
正如我先前提过的，php是所用语言中代码重用性最好的。从多中小的文档到整个数据库类，php开发者需要的时候可以随意的选择重用现有的代码。其 实，你几乎可以不用编写一行代码就能建立起整个应用程序。
4. 不重新开发现有的东西
很明显的一件事，只有少数的php开发者知道php本身有很多可用之处。忘记新的图书馆，或复杂的代码例程-先看看PHP手册。 例如，你们有没有听过number_format(), parse_url(), wordwrap()或bbcode_parse()?看一下整个函数参考 ，选择一个类别，浏览一下，您一定会有所发现。
5. IRC 是令人愉快的事
当你有个复杂的问题不能解决的时候，可以到IRC上。php非官方的支持频道，很多经验丰富的开发者陶醉其中。你需要一个IRC客户端，如果你用的 Firefox，ChatZilla是一个很好的插件，当你需要帮助时，以irc://irc.freenode.net/php做为头部粘贴你的代码。 张贴您的问题，并耐心等待;某种热心人(或多个)会给你答案。当你得到答案后，考虑一下其他需要帮助人的问题。对于php庞大的函数库来说，没有人是泰 斗;在IRC上，汇集所有人的知识就可以解决任何问题。
23
May
对于WEB开发，很多人想到的是HTML或者CSS+DIV等技术。看来在2010年的WEB开发方面，还是这些技术占据重要位置。
2009即将结束，2010年的Web会是什么样，或者说，未来的Internet意味着什么，2010会是值得关注的一年。本文从5个方面展望 2010年的Web，包括HTML5，CSS3， 字体服务技术；浏览器；社会媒体；JavaScript框架；以及SAAS。
1.CSS3,HTML5以及字体服务
CSS3，HTML5，以及Typekit一类的字体服务，将给Web设计师带来更多自由。
CSS3的新功能会让Web内容的展示变得更容易，从多背景图，到更强大的选择器，到颜色渐变，到圆角，这一切都让原先复杂的工作变得简单。
HTML5虽然进展缓慢，但必将改变我们描述页面的方式，成为通往语义Web的重要阶梯，为Web带来真正的本地多媒体支持，并改善我们同Web内 容的沟通。
而Typekit一类的字体服务联同@font-face，将允许我们在Web页面上使用任何字体，设计师们不必再依赖CSS背景 图，JavaScript或Flash。
这意味着什么？
这些新技术将为Web世界带来新的美学体验，当然，也会引发新的滥用潮，那些蒙古大夫式的设计师将会大量使用各种花里胡哨的字体和渐变色，使他们的 页面变得难以访问，对专业的设计师而言，这些新功能会让他们的创意更吸引人。
2.Web的消费方式
浏览器领域重新繁荣，诸如GoogleChrome,Firefox,Safari,Opera一类的浏览器大行其道，用户如今拥有更广泛的选择， 厂商之间的竞争更加激烈。浏览器之战进入新的阶段，和过去不同，过去的浏览器之争是微软主导并最终将对手消灭，新的浏览器之争使IE身涉危境。
人们消费Web的方式也在改变，上网不再意味着坐在电脑桌前打开电脑，智能手机越来越普遍，电视可以上网，SP3之类的游戏机，上网 本，iPhone，Android设备都可以在一个相对小的屏幕上给用户带来上网体验。
浏览器本身也在改变，Google Chrome将WebKit引擎，将大部分CSS3和HTML5功能从苹果迁移到Windows，Google在未来几年的目标是争取到10%的市场份 额，这将撼动IE的统治地位，在德国，Mozilla Firefox已经在超过IE成为主导浏览器。
这些因素也将改变我们对Web设计以及可访问性的看法，你的站点是否有一个移动版本？它们在小屏幕上看上去如何？在一个很大的屏幕上看上去又如何？ 在Weibit引擎，或是Gecko引擎，或是Trident引擎上看上去是否一致？
人们对在不同设备上访问Web的观念也在改变，设计师们逐渐意识到，没必要在各种不同设备上输出相同的页面，也无需为不同的设备提供相同的用户体 验。
这意味着什么？
人们将发现Web在不同的浏览器上有不同的样子，诸如渐进式增强的Web技术越来越普遍，为不同Web用户提供不同的体验。同时，放弃对陈旧浏览器 的支持也逐渐为人接受，让用户将压力推向浏览器厂商而不是设计师。另外，人们会将注意力转向内容，功能，可访问性，并注重设计和创意。
3.社会媒体
没有人会否认，2009年是社会媒体极其重要的一年，比如，Twitter已经成为热门话题，它还会继续热门。诸如 Twitter，Facebook一类的平台的发展使Web逐渐成为社区导向的Web，毫无疑问，社会媒体会有大的变革且会实现盈利。
围绕着社会媒体的一个问题是，如何衡量它的价值并获得这份价值。1000个Twitter跟随者价值几何？他们是否将为此收费？在2010年，对这 类问题的解答将导致社会媒体的大变革。
伴随着这些变革，信息的实时获取将成为焦点，Google已经在讨论针对Twitter等平台进行实时搜索的问题。这些改变如何同现有的系统，尤其 是搜索引擎技术集成，将引发一些技术革新。
这意味着什么？
随着越来越多的人参与 Web 信息的创建，我们获取信息的方式将从过去的单一来源向更社区化的来源转变，假如我们要搜索修车行，我们会看到修车行 最新的Twitter或Facebook消息而不是那些过时的静态内容。
4.JavaScript
当CSS3和HTML5开始涉足JavaScript的地盘，JavaScript本身也向Flash逼宫。诸如jQuery一类的框架使富客户 端，异步与无缝用户体验变为现实，Web应用的开发变得更简单，并引发竞争和创新。
JavaScript已经可以帮我们实现过去只能靠Flash实现的东西，如交互式游戏，复杂的交互式数据可视化技术，也使那些富客户界 面，Flash式体验变得更具可访问性。
最近，已经10年没有升级的JavaScript也迎来了它的一次重要升级(中文)，一旦浏览器厂商们吸纳了这些标准，Web开发者们将拥有更强大 工具来创建Web应用。
这意味着什么？
随着CSS3和HTML5开始涉足一些JavaScript的功能（如复杂对象的选取，动态圆角，实时可编辑页面），JavaScript将趋向于 用来处理Web应用与客户端的程序逻辑。JavaScript的最新升级将使Web应用之间更容易相互操作（JavaScript的这次升级的一个主要目 标是实现JSON对象的安全细则）。
5.SaaS-软件即服务
SaaS（软件即服务）已 经不新鲜，象37Signals，GoogleEnterprise一类的SaaS越来越普遍。竞争会越来越激烈，引入门槛低，那些小厂商将有机会和大厂 商展开竞争，2010年，我们会看到这种竞争加剧并带来Web应用的创新。
这意味着什么？
SaaS商业模式会继续取代传统软件的位置，随着上网的人越来越多，人们需要的是基于Internet可以相互操作的系统。
2009即将结束，2010年的Web会是什么样，或者说，未来的Internet意味着什么，2010会是值得关注的一年。本文从5个方面展望 2010年的Web，包括HTML5，CSS3， 字体服务技术；浏览器；社会媒体；JavaScript框架；以及SAAS。
1.CSS3,HTML5以及字体服务
CSS3，HTML5，以及Typekit一类的字体服务，将给Web设计师带来更多自由。
CSS3的新功能会让Web内容的展示变得更容易，从多背景图，到更强大的选择器，到颜色渐变，到圆角，这一切都让原先复杂的工作变得简单。
HTML5虽然进展缓慢，但必将改变我们描述页面的方式，成为通往语义Web的重要阶梯，为Web带来真正的本地多媒体支持，并改善我们同Web内 容的沟通。
而Typekit一类的字体服务联同@font-face，将允许我们在Web页面上使用任何字体，设计师们不必再依赖CSS背景 图，JavaScript或Flash。
这意味着什么？
这些新技术将为Web世界带来新的美学体验，当然，也会引发新的滥用潮，那些蒙古大夫式的设计师将会大量使用各种花里胡哨的字体和渐变色，使他们的 页面变得难以访问，对专业的设计师而言，这些新功能会让他们的创意更吸引人。
2.Web的消费方式
浏览器领域重新繁荣，诸如GoogleChrome,Firefox,Safari,Opera一类的浏览器大行其道，用户如今拥有更广泛的选择， 厂商之间的竞争更加激烈。浏览器之战进入新的阶段，和过去不同，过去的浏览器之争是微软主导并最终将对手消灭，新的浏览器之争使IE身涉危境。
人们消费Web的方式也在改变，上网不再意味着坐在电脑桌前打开电脑，智能手机越来越普遍，电视可以上网，SP3之类的游戏机，上网 本，iPhone，Android设备都可以在一个相对小的屏幕上给用户带来上网体验。
浏览器本身也在改变，Google Chrome将WebKit引擎，将大部分CSS3和HTML5功能从苹果迁移到Windows，Google在未来几年的目标是争取到10%的市场份 额，这将撼动IE的统治地位，在德国，Mozilla Firefox已经在超过IE成为主导浏览器。
这些因素也将改变我们对Web设计以及可访问性的看法，你的站点是否有一个移动版本？它们在小屏幕上看上去如何？在一个很大的屏幕上看上去又如何？ 在Weibit引擎，或是Gecko引擎，或是Trident引擎上看上去是否一致？
人们对在不同设备上访问Web的观念也在改变，设计师们逐渐意识到，没必要在各种不同设备上输出相同的页面，也无需为不同的设备提供相同的用户体 验。
这意味着什么？
人们将发现Web在不同的浏览器上有不同的样子，诸如渐进式增强的Web技术越来越普遍，为不同Web用户提供不同的体验。同时，放弃对陈旧浏览器 的支持也逐渐为人接受，让用户将压力推向浏览器厂商而不是设计师。另外，人们会将注意力转向内容，功能，可访问性，并注重设计和创意。
3.社会媒体
没有人会否认，2009年是社会媒体极其重要的一年，比如，Twitter已经成为热门话题，它还会继续热门。诸如 Twitter，Facebook一类的平台的发展使Web逐渐成为社区导向的Web，毫无疑问，社会媒体会有大的变革且会实现盈利。
围绕着社会媒体的一个问题是，如何衡量它的价值并获得这份价值。1000个Twitter跟随者价值几何？他们是否将为此收费？在2010年，对这 类问题的解答将导致社会媒体的大变革。
伴随着这些变革，信息的实时获取将成为焦点，Google已经在讨论针对Twitter等平台进行实时搜索的问题。这些改变如何同现有的系统，尤其 是搜索引擎技术集成，将引发一些技术革新。
这意味着什么？
随着越来越多的人参与 Web 信息的创建，我们获取信息的方式将从过去的单一来源向更社区化的来源转变，假如我们要搜索修车行，我们会看到修车行 最新的Twitter或Facebook消息而不是那些过时的静态内容。
4.JavaScript
当CSS3和HTML5开始涉足JavaScript的地盘，JavaScript本身也向Flash逼宫。诸如jQuery一类的框架使富客户 端，异步与无缝用户体验变为现实，Web应用的开发变得更简单，并引发竞争和创新。
JavaScript已经可以帮我们实现过去只能靠Flash实现的东西，如交互式游戏，复杂的交互式数据可视化技术，也使那些富客户界 面，Flash式体验变得更具可访问性。
最近，已经10年没有升级的JavaScript也迎来了它的一次重要升级(中文)，一旦浏览器厂商们吸纳了这些标准，Web开发者们将拥有更强大 工具来创建Web应用。
这意味着什么？
随着CSS3和HTML5开始涉足一些JavaScript的功能（如复杂对象的选取，动态圆角，实时可编辑页面），JavaScript将趋向于 用来处理Web应用与客户端的程序逻辑。JavaScript的最新升级将使Web应用之间更容易相互操作（JavaScript的这次升级的一个主要目 标是实现JSON对象的安全细则）。
5.SaaS-软件即服务
SaaS（软件即服务）已 经不新鲜，象37Signals，GoogleEnterprise一类的SaaS越来越普遍。竞争会越来越激烈，引入门槛低，那些小厂商将有机会和大厂 商展开竞争，2010年，我们会看到这种竞争加剧并带来Web应用的创新。
这意味着什么？
SaaS商业模式会继续取代传统软件的位置，随着上网的人越来越多，人们需要的是基于Internet可以相互操作的系统。
22
May
每个程序员都有自己烦心事，不论这事指的是范围蠕变（scope creep），还是指匈牙利变量命名 （Hungarian notation），我们都明白，这是我们有我们行业里的特定的烦恼。 下面要说的就是让程序员们烦恼的十件事情。
10. 注释 — 只解释了“how”却没有解释“why”
入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。
r = n / 2; // 让 r 等于 n 除以 2
// 当 r - (n/r) 大于 t 时进行循环
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半
}
经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。 问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。
现在，请看一下我们采用另外一种方式对同一段代码进行的注释:
// 使用牛顿-Raphson算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。
注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认为，读者对for循环的工作原理是了解的；所以没必要写这样的注释：“// 对客户列表进行for循环操作”。读者不明白的是你的代码是做什么用的，你为什么要采用这种方式实现它。
9. 干扰
很少有程序员能在眨眼之间从一种活动中转换到编程的状态中。通常情况下，我们更类似于需要慢慢启动的火车，而不是能突然加速的 法拉利; 我们需要一定的时间才能进入工作状态，一旦我们进入稳定有效的工作状态，我们的工作效果和产出会很丰硕。 不幸的是，当思路不断的被客户、经理、以及你的同事打断时，你的大脑很难进入编程的状态。
当我们干一件事情时，有太多的琐事需要我们放在心里，我们需要先放下这个事情，处理那个人事情，回头又干这个事情，还不能有差错。这些干扰会中 断我们的思路，而重新整理清楚思路又要你花费大量的时间，这是让人懊恼的、没有比这更让人泄气、让人有挫折感的过程了。
8. 范围蠕变（Scope creep）
范围蠕变（Scope creep） (也称作焦点蠕变（focus creep）， 需求蠕变（requirement creep）, 功能蠕变（feature creep），以及其它一些乱七八糟的演变词语)，指在项目管理里项目的需求变更失控。 当一个项目的范围没有明确的定义清楚、没有文档化、不受控时就会出现这种现象。 这通常被认为是一种有负面影响的事情，应该尽力避免。
范围蠕变通常会把一个简单的需求变成一个复杂惊人的需要大量时间的巨无霸。 那些负责需求调研的家伙们只需要敲几下无辜的键盘就能把事情变成这样：
◆版本 1: 显示这个地区的地图
◆版本 2: 显示这个地区的地图，要三维立体的
◆版本 3: 显示这个地区的地图，要三维立体的，而且能够使用它作为飞行导航图
一个本来30分钟能完成的任务变成了一项要几百人/天才能完成的超级复杂的系统。更糟糕的是，大多数情况下，需求变更是发生在开发阶段 的，这样一来你需要重写代码，重新回归，有时要把前几天才开发的代码删除。
7. 管理者 — 完全不懂编程
管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、喜怒无常，我们都自以为天下第一。想让这样的一群人都感到满意和团结，你需要付出像山一样大的努力。 然而，这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。 当管理者对我们的工作没有一点知识概念时，后果只会是需求频繁变动，不现实的工期，普遍的挫折感（管理者和开发人员）。程序员们对此的抱怨相当普遍，这也 是产生争执不合的根源。
6. 写文档
在说这个条目之前我先承认，我们确实有很多的文档生成工具，但据我的经验，这些工具都是只适合生成API文档，以供其他程序员参考。如果你开发 的软件是平时人们每天都要用的，你必须要写一些外行人(例如你的实施，客服等)都能理解的文档手册。
我们可以很容易的看出，有些事情程序员们极不愿意去做。 你可以简单的回顾一下所有的开源项目。 人们百折不挠的对这些项目的一个索求是什么：文档。
我敢打保票的说，不管在哪里，至少会有一半的程序员当要求写文档时会说：“不能让其他人去写吗？“。
5. 程序 — 缺少文档
我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。
当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。 函数 poorlyNamedFunctionA() 和函数 poorlyButSimilarlyNamedFunctionB() 有什么区别？ 在我使用 PropertyX 属性前是否需要测试一下它是不是 null 值？我估计只有通过自己的测试和报错才能弄清楚!。
4. 硬件
任何一个曾经被叫去调试一个数据库服务器上奇怪的宕机现象，或是被叫去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时， 都会痛苦不已。 人们有一种普遍的误解，认为程序员就是搞电脑的，他们肯定知道如何修理电脑。 不可否认，有些程序员确实是个全才，但我估计，绝大部分程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们只关心做出来的东西是否符 合需求文档，这样我们才能集中精力去解决这上层的任务。
3. 含糊不清
“网站宕机了”. “XX功能工作不正常”。 处理含糊不清的任务是种痛苦。 每次当非程序员被要求重现他们所遇到的问题时表现出的愤怒都让我吃惊不已。 他们似乎不太明白，仅仅一句”它宕机了，修复它！”是无法让我们开始工作的，我们需要更多的信息。
软件的运行是(大部分情况下)有迹可寻的。我们也乐见与此。 请迁就我们，帮我们指出是在哪个阶段，什么情况下出的问题，而不是简单的说一句”修复它“。
2. 其他程序员
程序员经常和其他程序员合不来。诧异吗，但这是真的。 这方面的事情我可以轻松的列出十大条，讲细点甚至可以单独写篇博客，所以这里我只列出几个常见的、让其他同事感到懊恼的程序员的特征：
◆脾气暴躁以至态度极不友好。
◆不能明白什么时候该去讨论系统的架构，什么时候是应该去动手去做。
◆无法进行有效的沟通，使用易于误解的专业术语。
◆自己的事情处理不好。
◆对要做的程序和项目缺乏兴趣。
那么，这最后的，但不是最糟糕的，序号为1的让程序员们烦恼的…
1. 自己写的代码 — 6个月以后的
Don’t sneeze, I think I see a bug.
回顾一下自己以前写的代码，是否也会愁眉苦脸？当时怎么会这么愚蠢！怎么能编写成这样的东西！烧掉!丢到火里！
现实是，软件技术界是一个不断变化的世界。 今天被看成是最好的方式，明天也许就会过时。 我们不可能写出完美的代码，因为判断我们的程序好坏的标准日新月异。 这令人很不爽，你的作品，今天看来是那么的完美，但也许不久之后就会变成被人嘲笑的对象了。 真是让人沮丧，因为不论我们如何努力的学习最新最棒的开发工具，设计，框架，以及开发方法，我们总是比最新的技术发展趋势慢了一拍。 对于我来说，这是做一个程序员最苦恼的事情了。我们不断的升级技术，是为了让软件更好，但却禁不住感到，我就像一个做沙毯（sand-painting） 的和尚。
10. 注释 — 只解释了“how”却没有解释“why”
入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。
r = n / 2; // 让 r 等于 n 除以 2
// 当 r - (n/r) 大于 t 时进行循环
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半
}
经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。 问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。
现在，请看一下我们采用另外一种方式对同一段代码进行的注释:
// 使用牛顿-Raphson算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。
注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认为，读者对for循环的工作原理是了解的；所以没必要写这样的注释：“// 对客户列表进行for循环操作”。读者不明白的是你的代码是做什么用的，你为什么要采用这种方式实现它。
9. 干扰
很少有程序员能在眨眼之间从一种活动中转换到编程的状态中。通常情况下，我们更类似于需要慢慢启动的火车，而不是能突然加速的 法拉利; 我们需要一定的时间才能进入工作状态，一旦我们进入稳定有效的工作状态，我们的工作效果和产出会很丰硕。 不幸的是，当思路不断的被客户、经理、以及你的同事打断时，你的大脑很难进入编程的状态。
当我们干一件事情时，有太多的琐事需要我们放在心里，我们需要先放下这个事情，处理那个人事情，回头又干这个事情，还不能有差错。这些干扰会中 断我们的思路，而重新整理清楚思路又要你花费大量的时间，这是让人懊恼的、没有比这更让人泄气、让人有挫折感的过程了。
8. 范围蠕变（Scope creep）
范围蠕变（Scope creep） (也称作焦点蠕变（focus creep）， 需求蠕变（requirement creep）, 功能蠕变（feature creep），以及其它一些乱七八糟的演变词语)，指在项目管理里项目的需求变更失控。 当一个项目的范围没有明确的定义清楚、没有文档化、不受控时就会出现这种现象。 这通常被认为是一种有负面影响的事情，应该尽力避免。
范围蠕变通常会把一个简单的需求变成一个复杂惊人的需要大量时间的巨无霸。 那些负责需求调研的家伙们只需要敲几下无辜的键盘就能把事情变成这样：
◆版本 1: 显示这个地区的地图
◆版本 2: 显示这个地区的地图，要三维立体的
◆版本 3: 显示这个地区的地图，要三维立体的，而且能够使用它作为飞行导航图
一个本来30分钟能完成的任务变成了一项要几百人/天才能完成的超级复杂的系统。更糟糕的是，大多数情况下，需求变更是发生在开发阶段 的，这样一来你需要重写代码，重新回归，有时要把前几天才开发的代码删除。
7. 管理者 — 完全不懂编程
管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、喜怒无常，我们都自以为天下第一。想让这样的一群人都感到满意和团结，你需要付出像山一样大的努力。 然而，这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。 当管理者对我们的工作没有一点知识概念时，后果只会是需求频繁变动，不现实的工期，普遍的挫折感（管理者和开发人员）。程序员们对此的抱怨相当普遍，这也 是产生争执不合的根源。
6. 写文档
在说这个条目之前我先承认，我们确实有很多的文档生成工具，但据我的经验，这些工具都是只适合生成API文档，以供其他程序员参考。如果你开发 的软件是平时人们每天都要用的，你必须要写一些外行人(例如你的实施，客服等)都能理解的文档手册。
我们可以很容易的看出，有些事情程序员们极不愿意去做。 你可以简单的回顾一下所有的开源项目。 人们百折不挠的对这些项目的一个索求是什么：文档。
我敢打保票的说，不管在哪里，至少会有一半的程序员当要求写文档时会说：“不能让其他人去写吗？“。
5. 程序 — 缺少文档
我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。
当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。 函数 poorlyNamedFunctionA() 和函数 poorlyButSimilarlyNamedFunctionB() 有什么区别？ 在我使用 PropertyX 属性前是否需要测试一下它是不是 null 值？我估计只有通过自己的测试和报错才能弄清楚!。
4. 硬件
任何一个曾经被叫去调试一个数据库服务器上奇怪的宕机现象，或是被叫去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时， 都会痛苦不已。 人们有一种普遍的误解，认为程序员就是搞电脑的，他们肯定知道如何修理电脑。 不可否认，有些程序员确实是个全才，但我估计，绝大部分程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们只关心做出来的东西是否符 合需求文档，这样我们才能集中精力去解决这上层的任务。
3. 含糊不清
“网站宕机了”. “XX功能工作不正常”。 处理含糊不清的任务是种痛苦。 每次当非程序员被要求重现他们所遇到的问题时表现出的愤怒都让我吃惊不已。 他们似乎不太明白，仅仅一句”它宕机了，修复它！”是无法让我们开始工作的，我们需要更多的信息。
软件的运行是(大部分情况下)有迹可寻的。我们也乐见与此。 请迁就我们，帮我们指出是在哪个阶段，什么情况下出的问题，而不是简单的说一句”修复它“。
2. 其他程序员
程序员经常和其他程序员合不来。诧异吗，但这是真的。 这方面的事情我可以轻松的列出十大条，讲细点甚至可以单独写篇博客，所以这里我只列出几个常见的、让其他同事感到懊恼的程序员的特征：
◆脾气暴躁以至态度极不友好。
◆不能明白什么时候该去讨论系统的架构，什么时候是应该去动手去做。
◆无法进行有效的沟通，使用易于误解的专业术语。
◆自己的事情处理不好。
◆对要做的程序和项目缺乏兴趣。
那么，这最后的，但不是最糟糕的，序号为1的让程序员们烦恼的…
1. 自己写的代码 — 6个月以后的
Don’t sneeze, I think I see a bug.
回顾一下自己以前写的代码，是否也会愁眉苦脸？当时怎么会这么愚蠢！怎么能编写成这样的东西！烧掉!丢到火里！
现实是，软件技术界是一个不断变化的世界。 今天被看成是最好的方式，明天也许就会过时。 我们不可能写出完美的代码，因为判断我们的程序好坏的标准日新月异。 这令人很不爽，你的作品，今天看来是那么的完美，但也许不久之后就会变成被人嘲笑的对象了。 真是让人沮丧，因为不论我们如何努力的学习最新最棒的开发工具，设计，框架，以及开发方法，我们总是比最新的技术发展趋势慢了一拍。 对于我来说，这是做一个程序员最苦恼的事情了。我们不断的升级技术，是为了让软件更好，但却禁不住感到，我就像一个做沙毯（sand-painting） 的和尚。
