分类： 程序猿经验心得

五种常见的 PHP 设计模式

另外五个 PHP 设计模式

在 PHP 中养成 7 个面向对象的好习惯

国外开发者博客中有一篇有趣的文章，将程序员按水平像软件版本号那样划分为不同的版本。相对于在招聘时分为初级，中级，高级程序员，直接表明需要某种语言N版本的程序员或许更方便直接。根据作者的观点，可将WEB开发者大致分为以下几个版本：
Alpha：阅读过一些专业书籍，大多数能用Dreamweaver或者FrontPage帮朋友制作一些Web页面。但在他们熟练掌握HTML代码以前，你大概不会雇佣他们成为职业的WEB制作人员。

Beta：已经比较擅长整合站点页面了，在HTML技巧方面也有一定造诣，但还是用Tables来制作页面，不了解CSS，在面对动态页面或数据库连接时还是底气不足。

Pre Version 1 (0.1)：比Beta版的开发者水平要高。熟悉HTML，开始了解CSS是如何运作的，懂一点JavaScript，但还是基于业余水准，逐步开始关心动态站点搭建和数据库连接的知识。这个版本的WEB开发人员还远不能成为雇主眼中的香饽饽。

1.0: 能够基本把控整个站点开发，针对每个问题尽可能的找到最直接的解决办法。但对可测性，可扩展性以及在不同(层)框架下如何选择最合适的WEB设计工具尚无概念。这个版本的WEB开发者有良好的技术基础，需要有进一步的帮助和指导。

2.0：懂面向对象的编程语言，理解分层开发的必要性，关注代码分离，对问题寻找更完美的解决方法，偶然也会考虑设计模式的问题，但对此仍然概念不清。属于优秀的初级开发者，能完成较松散的代码开发(相对大型严谨的站点开发而言)，在面对较复杂问题寻找解决办法时需要周边人的帮助。

3.0：开始较为深入的理解面向对象编程和设计模式，了解他们的用途，当看到好的设计模式时能看透其本质，逐步关注分层的架构解决办法和可测试性。理解不同的开发语言并能说出他们的异同(例如各自的优势)。属于优秀的中级别开发者，雇主也确信他们最终能找到问题的解决办法，这个版本的人可以给1.0和2.0的开发者以指导。但他们对架构的理解仍然不够清晰，值得一提的是，只要给予一些指导，他们能很快理解并熟记做出的决定，以及选定方案的优势所在。

4.0：理解模式，重视用户的反馈。着手研究方法论，架构设计和软件开发的最佳入口。头脑中已经形成了超越开发语言，技术架构的整体方案，可根据需求解构程序。能从理论的角度，不同模式如何融合成最佳形态，将多种X-驱动的模式应用到不同的方案中。是精通多语言的高手，理解不同系统和方法论的细微差别，属于高级程序员。这个级别的人能够轻易的辅导2.0和3.0的程序员，将他们推向更高的级别。

5.0：从系统的角度考虑问题。对各种系统结构有深入研究，能对整个代码架构中的问题进行改进。在团队粘合性以及代码安全性方面有杰出贡献。对1.0到4.0版本的开发人员出现的问题能及时察觉，让整个团队保持积极性且保持兴奋的状态创建软件解决办法。举例来说，他们总是对新的技术和信息保持饥渴状态，试图用最简便的方案解决开发任务。在整个IT团队中获得信任，属于高级程序员和架构师。

那么，您属于哪个版本的程序员呢？

 

源文：http://geekswithblogs.net/leesblog/archive/2008/06/22/developer-versioning-which-version-are-you.aspx

前几天看到多年的兄弟又换工作了，他在QQ签名上写了一句“三十而立，网海茫茫；十年技术，一场空！哎，何处是归途”，看了以后，我回想了一下，感觉我和他也差不多，说实在的，我们计算机班46个人，现在搞软件这行的就剩5个人，转眼间，我们工作都快十年了，而我们几个人的处境其实差不多，也许是物以类聚，人以群分，没办法，我们没关系，没运气，只能靠正常的发展，一步步去做，分析了一下我们这几个人的发展阶段，做了几张图，如下： 工资是生活的根本，每个出来的人都一样，可太看重工资，也许就跟我们一样了，到现在才觉悟就有些晚了，我们做技术的，一般在提高自己的过程中，都希望成一定比例增长，可十年过后，在现在这样的生活环境里还是难以生存，社会在发展，可我们的收入发展，和社会发展太平行了，回头想来，我们都是没什么欲望的人，每天都在为别人创造利益，公司选的好，可能说大了，还是创造了社会价值，反之只是为了生存而活，一个人想成功，就得有强烈的欲望，“如果梦想是成功的方向，那么欲望则是成功的动力”，如果你还在为工资较劲，那还不如为自己定下你成功的目标，为了自己的方向去努力，工资，能让你活就行，剩下的就是为了成就事业去努力，不要看别人做成什么样了，做好自己就行。   在职场的发展的过程中，钱赚少了没关系，可人脉绝对不能少，就算你工作十年，人脉上不来，你也就只是个做技术的，也许你有了点小钱，想做点事，确发现身边的朋友少，业务关系少，不知道做什么，感觉自己力不从心，人脉广了，你的成长也会更快，机会更多，也许十年才能做的事，你五年就可以做到。   根据技术能力的发展，在公司里一般有过十年工作经验的人，差不多都经历了这些职位，职位只能证明你能力的位置，你发展到什么样，如果是找工作，你得将自己定在什么样的位置，可以参考一下，不过每个人的规划不同，如果是和我画的图差不多，那就得改变一下自己的心态了。   工作十年，知识是要不断提高的，这与上面职位的发展是一样的，“知识就是力量”，你有多大能力，公司会去评估，不要把一年的经验当作十年用，不然你永远也只是浪费青春，以前在招聘的时候，我遇到一个已经工作五年了人，但他只要求工资3500，可想而知，他对自己都没有信心，五年，足可以改变人的一生了，他确一成不变的在原地。 经历十年，不断的在得与失中徘徊，到现在也没什么值得骄傲的事，没什么成就感，写点心得希望能和同道的朋友多多交流。   摘自 http://www.cnblogs.com/nick4/archive/2010/08/19/1803393.html

先给大家看一段据说是史上最强的程序：
e100 33 f6 bf 0 20 b5 10 f3 a5 8c c8 5 0 2 50 68 13 1 cb e 1f be a1 1 bf 0 1
e11b 6 57 b8 11 1 bb 21 13 89 7 4b 4b 48 79 f9 ad 86 e0 8b c8 bd ff ff e8 20
e134 0 3d 0 1 74 1a 7f 3 aa eb f3 2d ff 0 50 e8 f 0 5a f7 d8 8b d8 26 8a 1 aa
e14f 4a 75 f9 eb de cb 57 bb 21 13 8b c1 40 f7 27 f7 f5 8b fb ba 11 1 4f 4f 4a
e168 39 5 7f f9 52 8b c5 f7 25 f7 37 2b c8 95 f7 65 2 f7 37 95 2b e8 fe e fe
e181 10 79 6 c6 6 fe 10 7 46 d0 14 d1 d1 d1 e5 79 ec 5a b8 11 1 ff 7 4b 4b 48
e19b 3b d0 75 f7 5f c3 83 f7 83 a6 5d 59 82 cd b2 8 42 46 9 57 a9 c5 ca aa 1b
…………………………………………………………………..

这 段程序是1997年世界程序设计大赛的一等奖作品的部分代码（完整的代码 下载，把代 码复制粘贴到cmd的debug命令中，回车看到效果）。这个程序运行后将是一个3D的且伴随着音乐的动画。震撼吧！
是不是从事软件开发的人员都 希望成为这样的武林高手呢？然而真要是用这样的高手来设计、编写我们的产品代码，恐怕某一天，我们什么都不用干了，只能人手一本机器代码，一句一句进行翻 译了；那么对于软件产品开发而言，如何写好代码呢？一流的软件产品的代码具备哪些特征呢？

一流代码的特征

1、稳定可靠（Robustness）
代码写出来以后，一定要能够运行得非常好，非常稳定可靠。在现 今的IT行业，软件产品都是是24*7，即要保证系统一天24小时，一星期7天中都可以无间断的正常运行。比如我们百度的搜索引擎系统，比如我们的通信系 统，等等。到了产品开发后期，大部分的成本都将投入到产品稳定性的提高。

2、可维护且简洁（Maintainable and Simple Code）
在写代码时，首先要考 虑的是：写出来的代码不但要自己可以读懂，而且我们的同事、测试工程师都可能要修改这些代码，对其进行增减。如果代码很复杂，不容易读懂，如程序中的递归 一大堆、程序不知何时或从何地跳出，则会使程序的可维护性和简洁性降低。所以必要的注释、统一的编程规范等都是非常重要的。

3、高效（Fast）
在软件行业中效率是非常重要的，比如搜索引擎。有些软件的搜索效率就不高，搜索过 程特别缓慢，让人难以接受。当然这里面有一个带宽的问题，但是程序效率不高也是一个重要的原因。而实际上程序的效率提高，有时候很简单，并没有什么神秘之 处，如使用数组索引时候，可以用指针方式而不使用数组下标；数组的空间定义应该定义为2的N次幂等等。

4、简短（Small）
这方面大家的感受可能不是很深，但是我的感受是很深的。配置过PSTN程控交换 机、路由器、VoIP网关设备的人都知道，这些设备的软件都是从PC机通过网口或串口下载到这些设备的Flash上（类似PC机的BIOS）再通过设备上 的CPU启动。如果程序写的很罗嗦，随着特性不断增加，程序规模将变大的巨大，Flash空间告急、内存告急、下载升级变的不可忍受，等等，带来的就是成 本不断增加，利润不断下降。

5、共享性（Reusable）
如果做大型产品开发，程序的共享性也是非常重要的。我们产品有那么多开 发人员，如果每一个人都自己定义字符串、链表等数据结构，那么开发效率就会降低，我们的产品恐怕到今天也不能出台。我所说的“共享”不是指将别人的代码复 制到自己的代码中，而是指直接调用别人的代码，拿来即可用。这一方面可以减少代码的冗余性，另一方面可以增强代码的可维护性。如果别人的代码里有Bug， 只需修改他的代码，而调用此代码的程序不用进行任何修改就可以达到同步。这同时要求我们在设计的时候，如何考虑系统的内聚和耦合的问题。

6、可测试性（Testable）
我们的产品开发里，除了软件开发人员，还有一部分工程师负责软件测 试。软件测试人员会将开发代码拿来，一行一行地运行，看程序运行是否有错。如果软件开发人员的代码不可测试，那测试工程师就没有办法进行工作。因此可测试 性在大型软件开发里是很重要的一点。可测试性有时候与可维护性是遥相呼应的，一个具有好的可测试性和可维护性的代码，测试人员可以根据开发提供的维护手 册、debug信息手册等就可以判断出程序出错在哪个模块。

7、可移植性（Portable）
可移植性是指程序写出来以后，不仅在windows 2000里可以运行，在NT/9X下可以运行，而且在Linux甚至Macintosh等系统下都可以运行。所有这些特性都是一流代码所具备的特性。但是 其中有些特性是会有冲突的。比如高效性，程序写的效率很高，就可能变得很复杂，牺牲的就是简洁。好的代码要在这些特性中取得平衡。

写好代码的10个秘密

1、百家之长归我所有（Follow Basic Coding Style）
其实写代码的方式有很 多，每个人都有自己的风格，但是众多的风格中总有一些共性的、基本的写代码的风格，如为程序写注释、代码对齐，等等。是不是编程规范？对就是编程规范。

2、取个好名字（Use Naming Conventions）
取个好的函数名、变量名，最好按照一 定的规则起名。还是编程规范。

3、凌波微步，未必摔跤（Evil goto’s?Maybe Not…）
这里我用“凌波微步”来 形容goto语句。通常，goto语句使程序跳来跳去，不容易读，而且不能优化，但是在某种情况下，goto语句反而可以增强程序的可读性。Just go ahead，not go back。

4、先发制人，后发制于人（Practic Defensive Coding）
Defensive Coding指一些可能会出错的情况，如变量的初始化等，要考虑到出现错误情况下的处理策略。测试时要多运行几个线程。有些程序在一个线城下运行是正常 的，但是在多个线程并行运行时就会出现问题；而有些程序在一个CPU下运行几个线程是正常的，但是在多个CPU下运行时就会出现问题，因为单CPU运行线 程只是狭义的并行，多CPU一起运行程序，才是真正的并行运算。

5、见招拆招，滴水不漏（Handle The Error Cases：They Will Occur！）
这 里的Error Case（错误情况），是指那些不易重视的错误。如果不对Error Case进行处理，程序在多数情况下不会出错，但是一旦出现异常，程序就会崩溃。

6、熟习剑法刀术，所向无敌（Learn Win32 API Seriously）
用“剑法刀术”来形容一些API是因为它们都是经过了很多优秀开发人员的不断开发、测试，其效率很高，而且简洁易懂，希望大 家能掌握它，熟悉它，使用它。是不是象我们的ULIB。

7、双手互搏，无坚不摧（Test,but don’t stop there）
这里的测试不是指别人 来测试你的代码，而是指自己去测试。因为你是写代码的原作者，对代码的了解最深，别人不可能比你更了解，所以你自己在测试时，可以很好地去测试哪些边界条 件，以及一些意向不到的情况。

8、活用断言（Use,don’t abuse,assertions）
断言（assertion）是个很好的调试工具和方法，希望大家能多用断言，但是并不是所有的情况下都可以用到断言。有些情况使用断言反而不合适。

9、草木皆兵，不可大意（Avoid Assumptions）
是指在写代码时，要小心一些输入的情 况，比如输入文件、TCP的sockets、函数的参数等等，不要认为使用我们的API的用户都知道什么是正确的、什么是错的，也就是说一定要考虑到对外接口的出错处理问题。

10、最高境界、无招胜有招（Stop writing so much code）
意思就是说尽量避 免写太多的代码，写的越多，出错的机会也越多。最好能重用别人开放的接口函数或直接调用别人的api。

 

——摘自 http://www.iwanna.cn/archives/2010/12/07/6111/

导语：

进入IT行业，等于在无形之中进入了一个高压力、高需求、低满足的行业圈中。压力那么大，主观快乐却那么的少，并且主观快乐会随着从业时间的推移而不断减少。在身体健康之外，IT从业者的心理健康已经成为了关注焦点。到底IT从业者们的心理面临着怎样的挑战呢？

韩青已经第三次走进心理咨询室了，可是他仍然无法完整的表达他的痛苦，不管怎样引导他，他也只能问一句答一句，多说一点儿，他就会不知如何回答，而他反复表达的意思就只有一个：他已经快要32岁了，工作太忙，没时间恋爱，还没有结婚，事业无所谓上升与否，看不到未来，觉得生活实在无聊，无聊到活着都觉得费劲了。作为一名工作了7年的资深程序设计员，韩青面临着人生各种需求的低满足困境，而他，并不是唯一有问题的人。

对于IT企业各阶层的员工而言，压力那么多，而主观感受的快乐却那么少。满怀激情地走出校园，就被湮没在“蚁族”群中，成为挣扎底层的“蚁民”；在城市中刚刚立足，卖PC为生，成为自轻自贱的“P民”；跻身白领，在多年疲于奔命的奋斗中，成为自我迷失的公司人，也就是IT“公民”。

IT公司的“公民”已经成为高危人群——《计算机世界》的调差显示：57%的“公民”最关心的心理健康问题是“缓解工作压力”；50.6%是“调适自己的心理健康”；31.7%是调适人际关系；31.7%是解决家庭压力。超过50%的人认为自己有必要接受心理机构的辅导和治疗。

IT行业里有一种其他行业罕见的职业倦怠感，“不知道为什么，我在工作中无法找到乐趣，现在我是个老手了，压力比原来小了，可也没有了动力，像我这样的人也就只能混到这样了。我也想过跳槽、创业，但是我老了，跳不动了。”30出头的韩青显得暮气沉沉，他说他现在喜欢上了养花，摆弄那些花花草草比编代码有意思多了。

每个男人心中都有一个创业的梦想，韩青也曾经冲动过。但是，工作的枯燥磨平了他的热情，这个刚刚32岁的技术天才，甚至连槽也懒得跳。懒得跳槽、懒得拼命、懒得辞职、懒得结婚……IT公司白领中那种深深的职业倦怠感和枯竭感让我们感到震惊。

究竟是什么造成了这一切？压力？需求？

IT业是一个特征鲜明的行业，其突出特点是知识密集、人才聚集、高智商者互相撞击。在这种环境里工作，既需要脑力的付出，也需要体力的付出。从人的需求层次来说，IT人往往处于需求的高层次。但在现实生活中，他们却在所有需求层次上均遭到挑战。从最基本的生理需求到最高级的自我实现的需求，都对他们具有冲击性影响。心理学家马斯洛把人的需求分为5个层次，分别是生理需求、安全需求、社交和爱的需求、尊重的需求、自我实现需求。大量材料表明，中国IT人的五个层次的需求均存在未被满足状态，有些人则处在极端未满足状态。而不同年龄段、不同工作时间段的IT从业者面临着不同的需求，而这些需求的满足情况却是普遍低下。高压的工作环境，造成了对需求的高要求，然后IT行业却只能提供极低的需求满足，这之间的落差就造成了IT从业者的强大心理挫折感，压力于是更加肆虐，从而带来焦虑、烦躁、空洞、无聊、倦怠等等负面情绪。

30岁之前：自我实现需求最大化

对于刚刚走出校园的IT从业者们，创造力、发展力正强，精力充沛，心态积极，理想化程度高，在这个时期，爱情等情感往往只是生活的调剂品，不占主要地位，在这一阶段，尊重和自我实现的需求占据主要地位，甚至于为了这两个需求，大部分的从业者会放弃一定的生理需求和安全需求。在这个时期，获得认可、获取不可替代的重要性是最主要的事情。

然而，在这一时期，恰恰是积累经验的时期，行业可以满足从业者们的生理需求，却无法满足其他的需求，更不用说自我实现。在一定程度上，尊重的需求是可以实现的，当我们取得了成绩，获得了一定的奖励时，我们会有动力进行下一次的拼搏。但，可获得的奖励是有限制的，能够获得提升、认可，得到奖励的人，永远只是极小的一部分，大多数的从业者就不得不面临着，庞大的压力，最最基本的生理需求满足，和永远也无法满足的其他需要，并在这种追逐当中，不断地经历挫败。

当挫败积压到了一定程度，自我实现的需求就被消磨殆尽，尊重的需求也不那么重要，而安全需求则被提升到了一个迫切的地位上，如何保住自己现有的工作、收入、社会地位，会成为大部分从业者努力的目标。

从现象来看，IT人都是高薪阶层，似乎衣食无忧，前程似锦。但实际情况却并非如此。中国的IT业与世界同行相比，还不够成熟，中国IT人的生存与发展状况注定缺少安全感。IT人普遍对自身的前途堪忧。许多企业在管理上规范程度不够，与人性化管理相去甚远。正如网上的一篇文章《一个老程序员的心里话》中所说：“国外（程序员）可以在一个单位效力几十年，在国内不行。为什么？没有培训，没有晋升机会。你被压榨完后就被扔掉。哪个人甘于这样的命运？”所以，IT人的忧患意识、不安全心理要大于其优越感和安全感。加之企业之间、个人之间竞争激烈，所以IT人安全心理远远未能得到满足。这种安全心理的缺失也会直接导致IT从业者产生挫折心理。

“编写代码是极费脑筋的事，一旦思路打断就很难续上，必须得一鼓作气地干。”一个小时的咨询里，韩青抽了5支烟，尼古丁对他而言，已经无法刺激神经、提神醒脑以及安抚情绪了，“我上大学那会儿不抽烟，现在不得不抽。”

不安感是几乎所有IT从业者都会遇到的问题，因为能力的成长速度远快于薪水的成长速度，一旦能力成长到一定时候，而薪水却仍旧无法攀升，那么这份工作的吸引力必然会降低。韩青说几个月前他还在无聊与跳槽中徘徊，“难道我这辈子就这样了吗？我也经常问自己，可是转念一想，到哪里找这样的工作还房贷？还是就这样吧。”

厌烦、焦虑、百无聊赖，IT“公民”正被这样的负面情绪缠绕着。在《计算机世界》的调查中，有37.4%的人表示经常感到“厌烦、缺乏耐心”；厌烦与缺乏耐心随之带来的是焦虑与抱怨，调查中，经常抱怨自己的工作的有25.8%，46.1%的人会“偶尔”抱怨。（如图）

30岁之后：从理想走向现实

到了30岁左右，IT从业者们都开始放弃自己曾经理想化的想法，而转向了残酷的现实。现实就是，在自我实现的需求满足之前，IT从业者们极有可能先被需求折磨至疯狂。到了这一时期，工作已经基本稳定，生存不再成为一个问题，安全的需求慢慢的被满足，然而，社交与爱的需求在这一阶段极大的凸显出来。

IT从业者与电脑打交道的时间要多于与人打交道的时间。工作特性决定他们与外界交往的时间、机会相对有限。在公司内部，同事间的交往形式比较单调，情感贫乏。很多时间都是通过EMAIL相互沟通。这种交流方式缺少面对面交流的直观性与生动性。由于缺少身体语言的参与，使得人们之间思想与情感的交流大打折扣。由于经常要加班，IT人与家庭成员间的交流也大受妨碍。他们很少有机会与家人一起吃饭、逛街、聊天。因此也就无法获得正常的社会交往，因此而妨碍了正常的情感体验。

许多IT从业者，因为缺少正常的情感体验，慢慢地变成了情感匮乏者，而这一人群正是心理疾病高发群体。缺少正常的社会交往与情感体验，会让人们察觉不到内心需要，感受不到生活中的喜怒哀乐，甚至会产生严重的厌世、弃世的情绪。不能够正确表达内心，无法与人正常沟通，是抑郁症、焦虑症等神经官能症的重要致病原因。

到了这一时期，IT从业者们褪去了理想化的外衣，开始追寻现实当中可以满足自己需求，让自己快乐起来的生活，然而，IT行业却无法提供条件来满足这些需求。在这样的情况下，IT从业者们会慢慢地去选择一些极端方式带给自己快乐，从而来逃避现实中的挫败。许多IT从业者深陷网游无法自拔，还有一些人用暴走、暴食等方式来获得短暂的快乐体验，女性从业者常常会选择疯狂购物……而这些方式无一例外的都是在逃避现实中的挫败感，逃避由此而产生的种种负面情绪。

某种意义上说，这些方法帮助IT从业者们适当远离了心理疾病，然而，事实上，这些极端的行为不仅不能有效减压，反而会导致新的循环压力出现，我们甚至于可以将这些行为看成是强迫症的直观表现。在某一项关于中关村企业员工的心理调查显示，46%的被调查者存在心理健康轻度异常，58%的人承认自己有强迫症状、敌对情绪，而这种强迫症状的倾向，就是过度释压的危险信号。

也许对于IT行业的从业者来说，“中年危机”的种种现象来的有些太早，更早地了解我们所要面临的困境，或许有助于我们主动的去摆脱和解决。尽管IT行业的性质和环境是我们无法改变的，但是我们应该从我们自身寻找原因和解决的途径。任何一种心理上的问题，其实都是一种含蓄的告诫：我们身上出了问题，我们应该彻底检视自己。

——摘自 听心理学网站

所谓谚语，就是用言简意赅、通俗易懂的方式传达人生箴言和普遍真理的话，它们能很好地帮助你处理生活和工作上的事情。也正因如此，我才整理了10句编程谚语，每位开发人员都应该铭记他们，武装自己。

1. 无风不起浪

代码设计是否糟糕，从某些地方就可以看出来。比如：
a. 超大类或超大函数 b. 大片被注释的代码 c. 逻辑重复 d. If/else嵌套过深
程序员们通常称它们作代码异味(Code Smell)，但是就我个人认为“代码警报”这个名字更为合适一些，因为它有更高的紧迫感的含义。根本问题处理不当，终将引火烧身。

译注：Code Smell中文译名一般为“代码异味”，或“代码味道”，它是提示代码中某个地方存在错误的一个暗示，开发人员可以通过这种smell（异味）在代码中追捕到问题。

2. 预防为主，治疗为辅

20世纪80年代，丰田公司的流水作业线因为它在缺陷预防方法上的革新变得出了名的高效。每个发现自己的部门有问题的成员都有权暂停生产。这个方法意在宁可发现问题后马上暂定生产、解决问题，也不能由其继续生产而导致更棘手且更高代价的修复/更换/召回后的问题。

程序员总会做出生产率就等同于快速编码的错误臆断。许多程序员都会不假思索地直接着手代码设计。可惜，这种Leeroy Jenkins式鲁莽的做法多会导致软件的开发过程变得很邋遢，拙劣的代码需要不断的监测和修改——也可能会被彻底地替换。最终，生产率所涉及到的因素就 不仅仅是写代码所消耗的时间了，还要有调试的时间。稍不留神就会“捡了芝麻丢了西瓜”。（因小失大。）

译注：Leeroy Jenkins 行为：WOW游戏中一位玩家不顾大家独身一人迎敌，导致灭团。

3. 不要孤注一掷 （过度依赖某人）

一个软件开发团队的公共要素（bus factor）是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了，项目可能就会无序，甚至会搁置。

译注： bus factor 即指公共要素，比喻了开发过程中的一些共同因素。如果挤上 bus 的 factor 越多，bus 就越不稳定，所以要控制好 bus factor ，以免问题发生。

换句话说，如果你的团队突然失去了一个主力成员，你会怎么办？生意依旧进行还是戛然而止？

很不幸，大多数软件团队都陷入了后一种情况。这些团队把他们的开发员培养成了只会处理他们自己专业领域的“领域专家”。起初，这看起来是一个比较合理的方法。它 对汽车制造装配生产线很适用，但是为什么对软件开发团队就不行呢？毕竟，想让每个成员都掌握所编程序的细微差别也不太可能，对吧？

问题是开发人员不容易轻易替换掉。虽然当每位成员都可用时，“抽屉方法”很有效，但如果当“领域专家”突然因人事变动、疾病或突发事故而无法工作时，抽屉 方法立马土崩瓦解。（所以，）软件团队有一些看似多余实则重要的后备力量是至关重要。代码复查、结对编程和共有代码可用成功营造一个环境，在这个环境中， 每位开发人员至少表面上是熟悉自己非擅长领域之外的系统部分。

4. 种瓜得瓜，种豆得豆

《注重实效的程序员》一书中有这样一段话解释“破窗理论”：不要留着“破窗户”（低劣的设计、错误的决策或者糟糕的代码）不修。发现一个就修一个。如果没有足够的时间进行适当的修理，就先把它保留起来。或许你可 以把出问题的代码放到注释中，或是显示“未实现”消息，或用虚拟数据加以替代。采取一些措施，防止进一步的恶化。这表明局势尚在掌控之中。

我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素（我们将在其他地方接触到），但（对“破窗”）置之不理，肯定会更快地加速系统崩溃。

简而言之，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了惯性的力量。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟。写好你的代码，它才更可能经得住时间的考验。

译注：《注重实效的程序员》，作者Andrew Hunt / David Thomas。该书直击编程陈地，穿过了软件开发中日益增长的规范和技术藩篱，对核心过程进行了审视――即根据需求，创建用户乐于接受的、可工作和易维护的 代码。本书包含的内容从个人责任到职业发展，直至保持代码灵活和易于改编重用的架构技术。从本书中将学到防止软件变质、消除复制知识的陷阱、编写灵活、动 态和易适应的代码、避免出现相同的设计、用契约、断言和异常对代码进行防护等内容。

译注：破窗理论（Broken Window theory）：是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：如果有人打坏了一幢建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户。发现问题就要及时矫正和补救。

5. 欲速则不达

经理、客户和程序员正日益变得急躁。一切都需要做的事，都需要马上就做好。正因如此，快速修复问题变得非常急迫。

没时间对一个新功能进行适当的单元测试？好吧，你可以先完成一次测试运行，然后你就可以随时回来继续测试它。

当访问Y属性时，会不会碰到奇怪的对象引用错误？无论怎样，把代码放到try/catch语句块中。我们要钓到大鱼啦！

是不是似曾相识呢？这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟，我们有最后期限，还得满足客户和经理。但不要过于频繁操 作，否则你会发现你的代码不稳定，有很多热修复、逻辑重复、未测试的方案和错误处理。最后，你要么是把事情草草做完，要么是把事情好好做完。

6. 三思而后行

“敏捷开发”这个词最近被频繁滥用，经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者，看到产品朝正当方向有实质进展，我们理应高兴。但意外的是，UML图和用例分析似乎并不能满足我们的愿望。所以，在不知自己做什么的情况下或者不知自己身处何处时，我们开发人员经常就稀里糊涂地写代码了。

这就好比你要去吃饭，但你根本没有想好去哪里吃。因为你太饿了，所以你迫不及待地找个餐馆，定个桌位。然后你上车开车后沿途在想（找地方吃饭）。只是，这样会耗费更多的时间，因为你要过较多的U型弯道，还在餐馆前停车，也许最后因等待时间过长而不吃了。确切地说，你最后应该能找到地方吃饭，但你可能 吃的饭并不是你想吃的，并且这样花费的时间，可能比你直接在想去的餐馆订餐所花的时间更长。

7. 如果你惟一的工具是一把锤子，你往往会把一切问题看成钉子

程序员有一种倾向，当一谈到他们工具时，其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”，我们就会在接下来所有的项目上都用到它。学习新东 西仿佛是一种煎熬，有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。一定要摒弃这种想法，按我们所知道的去做，即使那不是最完美的解决方法。

坚持自己所知很简单，不过从长远的角度讲，选择一个适合这项工作的工具要容易得多。否则，就会与你的职业生涯格格不入。

8. 沉默即赞同

“破窗理论”与”变成惯性理论”有着宏观的联系。

编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多，就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码，那你每天都将和糟糕的代码相伴了。

同样地，如果你看到别人写出了糟糕的代码，你就要跟这个人提出来。注意，这时候机智就应该用上场了。一般情况下，程序员都愿意承认他们在软件开发中还是有不懂的地方，并且会感谢你的好意。互相帮助对大家都有利，而对问题视而不见，只会使问题一直存在。

9. 双鸟在林，不如一鸟在手 

如果可以讨论系统架构和重构，那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动，权衡改动的利弊很重要。当然了，简洁是一个理想目标， 但总会有可以通过重构改进的代码。在编程世界中，为了代码不过时，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘 境：你不能一石二鸟。你在重构旧代码上所发时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也需要找到平衡点。

10. 能力越大，责任越大

毫无疑问，软件已成为我们生活中一个既基本又重要的一部分。正因如此，开发优秀软件格外重要。乒乓球游戏中的Bug是一回事，航天飞机导向系统或者航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文，讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子便说明了我们正行使着多大的权利。你今天写的代码，无论你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想想都令人害怕。编写正确合格的代码吧！

译注：Slashdot是一个资讯科技网站。

Justin James曾发表过一篇博文《10 tips for advancing from a beginner to an intermediate developer》，为我们分享如何才能完成程序员从初级到中级的蜕变，现将中文译文转载于此，供大家借鉴。 在一封与TechRepublic会员交流的邮件当中，他提到了面向程序员的博客、文章及杂志分成两类：面向初学者类（“hello world”这种类型的教程）以及面向专家类（MSDN杂志）。这个观点很好，有关程序员如何从初级跃升到中级的信息极少。以下是为了实现这种转变需要你去做的10件事。

1.学习另一门语言 其实你学的是哪一门语言并没有关系，但是学习另一门语言（不管你已经了解多少种语言）将把你打造为更好的程序员。能学会一门与你日常使用的语言风格迥异的 语言则更佳。打个比方，如果你是C#程序员，学习VB.NET或者Java对你的帮助就没有学习Ruby或者Groovy大。 我说“学另一门语言”的意思是要真正学会它。学习一门语言包括三个领域的知识：语法、内置操作符和库，以及“如何使用”。前面两个简单；我认为一名有经验 的程序员，根据语言的不同，能在半小时到几小时内掌握足以维护代码的语法知识。操作符和库只不过是知识逐步积累的过程，你什么时候想清楚要了解什么了，再 去查阅参考材料也不迟。只有第三项，“如何使用它”-要花上你几个月的时间去跟这门语言打交道，真正的奇迹就在此发生。我建议用这门语言的风格去做一个适 合该语言的项目。 真正学会了另一门语言之后，我敢保证你的程序员水平一定会突飞猛进。

2.学习先进的搜索技术、手段和及策略 作为一名好的程序员，不仅仅是技能的问题了，而是你寻找信息的技巧，这个趋势越来越明显。对大部分人而言，仅仅输入“现代语言及开发框架”，这都是泛泛之 谈，记不住多少的。因此，你完成工作的能力通常取决于你的检索能力。不幸的是，了解到如何找到准确而高质量的信息可不仅仅是跑到TechRepublic 来找答案，或者在你选好的搜索引擎上敲几个字那么简单。 “技术（Techniques）”、“手段（tactics）”和“策略（strategies）”看起来是一回事，实际上并非如此。你需要学会的技术是 掌握你喜爱的搜索引擎的高级搜索系统；你需要了解诸如布尔操作符，如何过滤结果（像“非”关键字，域限制等等），关键字的词序扮演什么角色，等等。一句 话，RTFM（Read The Fucking Manual，读那些他妈的手册）吧。 你应该学会这些手段，诸如如何接近特定的搜索，以及了解自己实际上想查些什么。查错误很容易—只需查出错代码即可—但是许多搜索的关键字选择要困难得多。 至于策略，你需要学会的东西，包括像应该使用哪种搜索引擎（提示：普通的搜索引擎不一定就是最佳选择），使用普通搜索引擎前应该访问哪个网站，甚至是应该 到哪个论坛去寻求帮助，等等。

3.帮助别人 教别人始终是学习一切东西的最好方法之一。相对而言，由于你在开发领域还是个新手，认为自己没什么可教给人家的，这可以理解。但这毫无意义。记住，你所学 到的一切都是你从别人或别处学到的；因此请尝试一下，成为另外一个人要请教的“别人”。每天尽量花一点时间试着回答TechRepublic上的问题，其 他网站的亦可。读读其他会员的回答，你也可以学到很多东西。

4.有耐心，常练习 研究表明，要成为一名“专家”，需要花费10年，或者10000到20000小时的刻意练习时间。真的很久。还有，成为专家不尽然就是执行10年同样的任 务；通常这意味着要在特定领域内执行广泛的任务。需要花费大量的时间和精力才能成为“专家”；做几年程序员是不够的。想在30岁左右成为一名高级软件开发 工程师？要么尽早接受教育/培训，要么你得愿意在闲暇时间进行大量的工作、阅读和练习。我从高中开始编程，还牺牲了许多休息时间去跟踪行业发展、学习新技 能等等。结果，我获得中级和高级程序员的时间就比我的大部分同事都要早得多，随着时间的推移，这些就转化成为很多的金钱。

5.对教条拒之门外 是时候开诚布公了：也许初级程序员了解的东西还不足以说出做某件事情有一种最好的方式。尊重朋友或者权威的观点是好的，但直到你更有经验之前，不要把他们 的观点说成是你自己的。很简单，如果你所了解的不足以让你独立地找出这些东西来，你又怎么会认为你知道哪一位“专家”是对的呢？话是难听了点，不过请相信 我；由于受某些愚蠢建议的蛊惑，或者追随某些根本不知道自己在说些什么的所谓专家，白白把自己的职业生涯耽搁了几年，这样毛头小伙程序员，我见过多了。这 一点有一个很好的例子，就是面向对象结构的滥用。比如说，许多初级者读了一些有关面向对象的信息后，突然间，他们那简单的应用程序的类图看起来就像埃菲尔 铁塔一样了。

6.深入学习一点先进理念 成为一名中级程序员，很大一部分是要在代码里面体现出一些所擅长的概念。就我而言，是多线程/并行性，是正则表达式，以及如何对动态语言进行变化（后两个 在我离Perl渐行渐远后开始退化）。这是如何发生的？多线程和并行处理是因为我读了相关文章，觉得它看起来很有趣，然后再自己把它弄清楚了；然后我就一 直使用这些技术来写应用。我做过一件工作，是用Perl写的，里面运用了大量的正则表达式。我也用一个过程引擎模板和内置数据库系统写过我自己的电子商务 引擎；那时我几乎花了2年时间在这上面。 找到真正令你着迷的东西。也许是图像处理，也许是数据库设计，等等。即便你是一个入门级的程序员，也要尝试一下成为某一自己所关注领域的专家。这会让你相 当快速地进入到中级水平，一旦你到了那个水平，你的专家之路也走到一半了。

7.学习你的领域里面的基本理论 写出“Hello World”，跟理解那些字是如何显示到屏幕上的是两码事。通过学习支撑你所从事的工作的“基础/底层工作（groundwork）”，你会变得更加在 行。为什么？因为你会理解事物为何会以这种方式运作，当东西坏了就能知道是哪里的问题，等等。通过掌握工作的底层机制，你变会得更出色。 如果你是Web程序员，读读HTTP RFC和HTML规范。如果你使用代码生成器，好好看看它生成的代码；如果你使用数据库工具，看看它生成的底层SQL语句，不一而足。

8.看看高级程序员的代码 在工作中看看高级程序员写的代码，然后问一问事情是如何以某种特别的方式完成的，为什么？可能的话看看开源的项目。甚至即使其他程序员没有最好的编程习 惯，你也会学到许多编程经验。当然，要小心别学到坏习惯。我的意思是说不要生搬硬套人家的东西；你要能领会到哪些是能行的通的，哪些是有道理的，然后再模 仿人家。

9.学习好的习惯 愚蠢的变量名，糟糕的缩进习惯以及其他一些凌乱的迹象就是一个没有经验的程序员的最好标记。一个程序员在学会如何编程时，却经常没有被传授到那些不那么有 趣的细节，像代码格式编排。甚至尽管学习这些东西并不会令你的代码更好，也不会令你成为更好的程序员，它也会确保你不被同事视为入门级的程序员。甚至即使 某人是高级程序员，如果他的变量是以他那97只猫的名字来命名，或者其函数叫做“doSomething（）”的，他们看起来也不像是知道自己在干什么的 人。而且会令其代码在过程中更难以维护。

10.要玩的开心 想要痴迷于单调乏味的工作？痛恨工作吧。要想升级为中级程序员可不仅仅是为了拿到不断增长的工资不达目的誓不罢休，而是要真正享受工作。如果你不喜欢自己 的工作，且还是初级程序员，你怎么会认为成为中级或高级程序员情况就会有所好转呢？换工作或改职业吧。反过来说，如果你喜爱所从事的工作，那就好！只要你 坚持下去，我保证你能成为一名更好的程序员。（Justin James）

在StakeOverflow上有这样一个贴子叫“Confessions of your worst WTF moment”（WTF就是What the fuck的缩写），挺有意思的，我摘几个小故事过来，希望大家在笑过之后能从中学到什么——所有的经验都是从错误中来的（我在其中加了一些点评）

 

我们公司的软件是给警察局用的，那是一个对用来处理被逮捕的人的系统，此系统还需要收集脸部特征和指纹信息，并且，这个系统和会向FBI的系统提交这些信息。当我们在测试这个系统的时候，我们一般都是用我们自己的指纹，当然，数据库联着的是我们的测试数据库。不过，有一次，在我们测试完后，我们忘了把系统切换回生产库，于是我们的测试数据库就联上了生产环境，于是我们的指纹信息和照片就散布到了其它系统中……清除我们警察局这边的还好办，但是，你需要波士顿警察局警司去法院签字才能从FBI的数据库中清除我们的信息。

点评：测试环境和生产环境的数据不要混在一起。

有一次，我需要向新系统中导入一堆数据，因为数据量太大，需要5个小时，只能在夜里来干，在系统需要正式使用前2个小时，数据导完了，此时是凌晨4点。随后，我需要删除一些数据，于是我在SQL命令地上输入了“DELETE from important_table; where id=4”。是的，我没有看到哪里还有个分号，天啊。

点评：这就是加班工作的恶果。另，在delete之前最好先做一次select。

我把我的管理员口令提交到了一个开源软件的源码里。

点评：1）版本管理器里的东西是删不掉的。2）一些用户和口令要hard code在代码里，所以，不要混用代码使用的权限和管理员的权限，小心管理程序的运行权限，为其注册专门的用户。

 

我为一个很大的银行开发软件，在我的代码里，我为一段理论上根本不可能执行到的代码加了一个报错信息。有一天，不可思异的事发生了，这条报错信息显示在了该银行的1800个分行的超过10000个终端上——“如果你看到这个信息，说明整个系统被Fuck了，回家吧，祝你过得愉快！”

点评：“假设是恶魔”，Assume意为Ass – u – me，意为——搞砸你和我。对于一些关键东西，永远不要做假设。小心你言语中的——“可能、应该、觉得、不应该”等词语，程序可不认这些东西。

我远程登录到服务器上加几个防火墙规则。第一件我想干的事是在不允许任何人的任何连接，第二件是，为某个端口打开访问权限。不过，我在做完第一件事后就把配置保存了，结果其生效了……

点评：这样的事经常发生，做远程网络管理的人多少会有那么几次发生这样的错误。在你将你的网络配置生效前，你得想一想，断线了你是否还能登得上去。改配置不要太冲动，生效前检查几次。

我们的代码中有一个模块完美地工作了很多年了，只是代码太乱了。我说服了我的老板，我可以重写这个模块，于是我花了三个星期来重写这个模块。今天 ，我还记得，我的老板站在我的后面看着我，而我在在流着斗大的法汗珠去fix被我重写的“超级漂亮”的那个模块中一个接一个的bug。从那以后，我再也不重写代码了，除非有重大的利益。

点评：这就所谓的屠宰式编程。这个案例告诉我们两个道理，1）维护代码要用最最最保守的方法来进行。2）重构代码前要像一个商人一样学会计算利益。当然，ThoughtWorks的咨询师一定会告诉你TDD，结对，极限等等方法告诉你如果实践重构。但我想告诉你，一个程序在生产环境里运行好几个年能没有问题是一件很不容易的事，那怕其中的代码再烂，你再看不过去，你都要有一个清醒的头脑明白这几点，1）软件的运行质量是远远大于代码质量的，2）你的测试案例是远远小于生产环境的，3）软件的完美的质量，是靠长时间的运行、测试和错误堆出来的，而不是某种方法论。

————————————————

相信大家做程序员这一生中也有很多发生在自己身上的悲催的事儿，欢迎分享。我先分享几个我亲身经历过的事。

一个发生在我的领导身上。

我98年刚参加工作的时候，在某单位网络部门，一次，我们整个部门去给下属单位培训Cisco路由器，结果我们发现带去培训地点的设备少带了集线器HUB，设备连不起来。于是领导很不高兴，质问我们为什么没有带集线器？那几个对领导平时就不满的老员工说办公室里没有集线器了，都借给别的部门了。领导想了想，问我：“陈皓，我记得上次我给过你个集线器”，我说，“好像没有吧，我记不起来了，什么牌的？几口的？”，领导说： “什么牌子想不起来了，不过我记得那个集线器是一个口的”。“一个口的？！”，我心里嘀咕着，“真敢说啊”。但我不敢接话了。那几个老员工来劲了——“哪有一个口的HUB啊，一个口的怎么联两台电脑啊？”，领导说：“用两个一个口的不就行了”。领导这话一出，全场一片寂静，无言以对……

后来：我们所有的组员都离开了我们的这个领导，我们的这个领导今天还在那里工作。我想告诉大家，很多时候该走的是领导（包括外企，我上一东家正在裁人，不过我觉得该被裁掉的应该是那些经理）。我们的领导经常出这样或那样的笑话，这让我随时随地地警醒自己——“不要当一个被人笑话的经理”，于是，今天我还在努力地学习技术。

另一个发生在我身上

刚刚接触Linux的时候，还不是很懂，那时的PC还只有奔3，编译公司的程序好慢啊，有时候为了调查一个问题，需要不断地打log，来来回回地编译，很不爽。直到有一天，硬盘不够了，df一下，发现/dev/shm还有空间。于是，把全部程序copy了过去，发现编译起程序超快无比，爽得不行。于是就把工作环境放在/dev/shm下了，连开发都放在这里了。这一天，开发一个功能，改了十来个文件，加班很晚，觉得基本搞定，大喜，回家睡觉。第二天一来，发现/dev/shm下空了，一个文件都没有了，问同事，同事不知，同事还安慰我说，上次他的文件也不知道被 谁删了，于是我大怒，告老板！老板也怒，发邮件到整个公司质问大家谁删了陈皓的程序，无人应答。IT部门答，“昨晚唯一的操作就是重启了linux服务器，什么也没干，不过我们天天备份服务器，可以恢复”，IT部门问我丢的文件在哪个目录下？于是，我reply to all – “在/dev/shm下……”，哎，人丢大发了……

后来：我很感谢我以前犯的这个错，从那天以后，我开始立志学好Linux，这个错误让我努力，让我发奋。所以，我想告诉大家——尤其是刚出道的程序员，你们要多多犯错，要犯错那种丢死人的错，这样你才会知耻而勇。

再来一个发生在我同事身上的

01年，我们开发银行系统，在AIX上开发，RICS6000很贵，只能在客户那里开发，开发进度很紧张，慢慢地硬盘就不够用了，系统中有大量的垃圾文件，于是需要清除一些文件，于是有一个同事写了一个脚本，可以自动清除的各种不重要的文件，里面有一条命令大致是这个样子“ rm -rf ${app_log_dir}/*”，意为清除程序运行的日志。为了使用这个脚本，需要在root用户下运行，一开始还不错。直到有一天，某人一运行，整个根就没了。搞得整个团队只能用一周前的备份重写已写好的代码。后来，才发现原因是${app_log_dir}变量为空，于是成了“rm -rf /*”……

后来：这个事后，我的那个同事，把rm命令改了名，并自己写了一个rm命令，把删除的文件先放到一个临时目录下。而我也因为这个事情，到今天，每次当我在root目录下使用rm时，敲击回车的手都是抖的。（另，rm时永远使用绝对路径）这里，我想告诉大家——犯错不可怕，可怕的是不会从中总结教训，同一个错犯两次。

欢迎分享发生在你身上那些悲催的事。