10. 注释 — 只解释了“how”却没有解释“why”
入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。
经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。 问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。
现在，请看一下我们采用另外一种方式对同一段代码进行的注释:
这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。
注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认为，读者对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.
回顾一下自己以前写的代码，是否也会愁眉苦脸？当时怎么会这么愚蠢！怎么能编写成这样的东西！烧掉!丢到火里！
现实是，软件技术界是一个不断变化的世界。 今天被看成是最好的方式，明天也许就会过时。 我们不可能写出完美的代码，因为判断我们的程序好坏的标准日新月异。 这令人很不爽，你的作品，今天看来是那么的完美，但也许不久之后就会变成被人嘲笑的对象了。 真是让人沮丧，因为不论我们如
比较PHP和JSP这两个Web开发技术，在目前的情况是其实是比较PHP和Java的Web开发。以下是我就几个主要方面进行的比较：
一、 语言比较
PHP是解释执行的服务器脚本语言，首先php有简单容易上手的特点。语法和c语言比较象，所以学过c语言的程序员可以很快的熟悉php的开发。而java需要先学好java的语法和熟悉一些核心的类库，懂得面向对象的程序设计方法。所以java不如php好学。
Java首先要编译成字节码.class文件，然后在java虚拟机上解释执行。Java的Web开发首先最容易想到的就是JSP(现在已经到JSP2.0)，原来的java的Web开发都是用servlet来实现的，用servlet来开发需要程序员在java的源文件中嵌入大量的html代码。所以后来就出现了JSP,JSP可以方便的嵌入到html文件当中，其实jsp文件在服务器上执行的时候首先会被应用服务器转换成servlet，然后再编译执行。Jsp可以通过servlet和JavaBean的支持产生强大的功能。JavaBean 是一种可复用的、跨平台的软件组件。使用javabean可以方便的实现java代码和html的分离，能够增强系统的功能和软件的复用性。
Java的Web开发属于SUN公司定义的J2EE其中的规范。而且在J2EE中包括了java的Web开发的所有方面，如：JSP、Servlet、JDBC、JNDI、JAVABEAN、EJB等等。J2EE就特别适合于做大型的企业级的应用。
二、 数据库访问比较
Java通过JDBC来访问数据库，通过不同的数据库厂商提供的数据库驱动方便地访问数据库。访问数据库的接口比较统一。
PHP对于不同的数据库采用不同的数据库访问接口，所以数据库访问代码的通用性不强。例如：用Java开发的Web应用从MySQL数据库转到Oracle数据库只需要做很少的修改。而PHP则需要做大量的修改工作。
三、 系统设计架构比较
采用Java的Web开发技术，需要使用的是面向对象的系统设计方法，而PHP还是采用面向过程的开发方法。所以用Java进行开发前期需要做大量的系统分析和设计的工作。
四、 跨平台性
Java和PHP都有很好的跨平台的特性。几乎都可以在不作任何修改的情况下运行在Linux或者Windows等不同的操作系统上。
五、 开发成本比较
PHP最经典的组合就是：PHP + MySQL + Apache。非常适合开发中小型的Web应用，开发的速度比较快。而且所有的软件都是开源免费的，可以减少投入。
Java的Web应用服务器有免费Tomcat、JBoss等，如果需要更好的商业化的服务有：Web Sphere和 Web logic。
六、 分布式多层架构比较
PHP只能实现简单的分布式两层或三层的架构，而JAVA在这方面就比较强大，可以实现多层的网络架构。数据库层(持久化层)、应用(业务)逻辑层、表示逻辑层彼此分开，而且现在不同的层都已经有一些成熟的开发框架的支持。例如Struts就是利用java的Web开发技术实现了MVC的设计模式，而在业务逻辑层也有Spring框架，数据库持久化层有Hibernate等框架。这些框架可以方便开发者高效、合理、科学得架构多层的商业应用。
下面简要的说一下Struts，它实质上是在JSP Model2的基础上实现的一个MVC(Model、View、Controler)框架。JSP Model2体系结构是一种联合使用JSP 与Servlet 来提供动态内容的方法。在Struts框架中，模型由实现业务逻辑的JavaBean或EJB组件构成，控制器由Servlet实现的，视图由一组JSP文件组成。采用Struts可以明确角色的定义和开发者与网页设计者的分工。而且项目越复杂，其优势越明显。
七、 源代码安全
PHP开发的程序的源代码都是公开的，他人拿到php开发的程序后都可以进行修改。
Java开发的程序，最后用户拿到的是只是一些编译好的class类，无法看到完整的源代码，安全性高。
八、性能比较
有人做过试验，对这两种种语言分别做回圈性能测试及存取Oracle数据库测试。
在循环性能测试中，JSP只用了令人吃惊的四秒钟就结束了20000*20000的回圈。而PHP测试的是2000*2000循环(少一个数量级)，却分别用了63秒。
数据库测试中，二者分别对 Oracle 8 进行 1000 次 Insert,Update,Select和Delete： JSP 需要 13 秒，PHP 需要 69 秒。
综上所述，我个人认为，PHP适合于快速开发，中小型应用系统，开发成本低，能够对变动的需求作出快速的反应。而Java适合于开发大型的应用系统，应用的前景比较广阔，系统易维护、可复用性较好。还有，同样功能的系统用Java开发的系统要比PHP开发的系统的价格要高。
对于如何使代码的可读性更强，开发者往往都有自己的看法。那么你可曾仔细想过什么才能真正使代码可读性增强。
一些标准答案
无论你使用什么编程语言，你都可能会认同下面的建议可以增强代码的可读性：
- 好的变量、方法、类名
- 一个变量、类、方法只做一件事
- 一致的缩进，一致的格式
- 减少代码中的嵌套级别
或许你要说，这些东西我都知道。那么，下面就是一些你可能没有考虑的、关于代码可读性的更深层次的东西。
读者的经验
给我一段代码，我能在2秒内告诉你这段代码是否写得好，是否具有很强的可读性（至少我会告诉你我的意见）。
同时，如果我将我写得最好的、可读性很高的代码给一个编程新手，他们可能也不会发现这些代码与其他代码有什么不同。
虽然我的代码中有很好的、描述性的变量名，短的命名方法和少量的参数，并且它们只做一件事，各个功能结构清晰地组合在一起，但是这些新手并没有发现我的代码比其他没有考虑结构的代码好读到哪去。
事实上，我经常听到其他人抱怨我的代码中有太多的方法，难以理解，并且变量名称太长，容易混淆。
有经验的开发者与新手读代码的方式有根本的区别