程序员的七大坏毛病 编辑本段回目录
1.- 所有的程序都写的很烂，除了我的。
我要告诉你一个坏消息，兄弟，所有的程序都写的很烂，包括你的。无论你在上面花多少功夫，其他大多数程序员总是会认为你写的代码很烂、他们能写出比你好10倍的程序。
如何纠正：不要挑剔别人的程序，有一天也许你的程序会被人放在聚光灯下挑剔。要保持客观和专业的评论，不要轻易判断。要谦虚，从周围人哪里学习经验，警戒自己不要写出这么糟的程序。
抄捷径充满诱惑，每个人都想抄捷径。有时候抄捷径是必要的，但总的来说，抄捷径是危险的，非常危险，应该避免这样做。走捷径也许会节省你数小时的时间，但如果走错了，它可能会给你带来数月的麻烦。
如何纠正：遇到需要慎重处理的事情时不要太过自信。让其他人来复查你的所作所为。如果你计划要走捷径，请确保让你的负责人知道这样做的理由以及其中的风险。每次在走捷径时最好都让你的经理来确认实施成功，也就是“让他给你擦屁股”。
3.- 这是个几分钟就能搞定的事。
在我的家乡Barcelona，那里的圣家族大教堂让我非常的自豪，它的举世闻名来自于它的美丽，也来自于它的建筑完工日期的规划(它动工于1882年，目前仍未完工)，但这可能是因为他们没有让一个程序员去估计这个完工时间，否则的话，估计出的完工所需的时间很可能2周。
如何纠正：从一开始，你就必须严肃的认识到，对于一个有一定规模的软件开发过程来说，进行精确的时间评估是不现实的，我们能做的只是猜测。同样要记住的非常相似一点是，我们通常会发现有很多事情根本不能预见到它们会花去我们数倍于我们初始估计的时间，我通常的做法是把估计的时间乘上1.5或2。
很多程序员参与的讨论会基本上看起来就像是一场斗鸡，而不像是人类的讨论，这通常会出现在关于设计和架构问题的讨论会上。你基本上很容易看出其中各自都怀有顺我者昌逆我者亡的心态，你基本上可以把大多数的争论者所说的话直接换成咕咕！咕咕嘎！咕咕咕咕咕咕！咕咕嘎！
如何纠正：把你的自负留在心底。太过自负是所有程序员身上的一个非技术性的最大的一个毛病。凡事要三思而行。
5.- 这不是我的错！
在我看来，这另外一个大多数程序员都会有的坏毛病是缺乏责任心。我们总在找借口… 就比如有人会说，如果在正常情况下，这个错误绝对不会出现，但说老实话，这很难让人信服。
如何纠正：犯了错误不需要去捶胸顿足，也不需要用刨腹自杀来谢罪。我们应该怀有一种健康的态度，说出这样的话：“呀，抱歉，我们现在就去改正这个错误，是我的错”，这是一种很敬业的态度，这能帮助我们树立一个好的声誉，更好的得到你的同事的尊重。
6.- 没有激情
重复的和简单的任务通常不会带来什么动力，但这些事必须要完成，当程序员被要求去完成这些事情时，通常会显得无精打采，没有效率。
如何纠正：纪律问题。很不幸，我再也想不出其它的治疗这种毛病的良方。
7.- 不成熟
如果说把对计算机编程当作做爱，那很少有计算机能得到满足。你根本就没有潜心投入，干到一半就结束了，然后倒头便睡。我发现大多数程序员对“干完”这个词很纠结。请记住，干完意味着：测试过(不仅仅只是单元测试)，文档完整，提交过，合并过…
如何纠正：这是一个很麻烦的问题，相对于完全的完成某些功能性问题而言，这些并不是显得很有必要的任务会很庞杂和难处理，通常需要你有纪律性和受过培训。也许，这最简单的能让一个程序员理解他的开发是否真正的完成的两个办法就是：相互复查和演示。
惹恼程序员的十件事编辑本段回目录
程序员应该是一个比较特殊的群体，他们因为长期和电脑打交道所养成的性格和脾气也是比较相近的。当然，既然是人，当然是会有性格的，也是会有脾气的。下面，让我来看看十件能把程序惹毛了的事情。一方面我们可以看看程序员的共性，另一方面我们也可以看看程序员的缺点。无论怎么样，我都希望他们对你的日常工作都是一种帮助。
第十位 程序注释
程序注释本来是一些比较好的习惯，当程序员老手带新手的时候，总是会告诉新手，一定要写程序注释。于是，新手们当然会听从老手的吩咐。只不过，他们可能对程序注释有些误解，于是，我们经常在程序中看到一些如下的注释：
r = n/2; //r是n的一半
//循环，仅当r- n/r不大于t
while ((r-n/r) <=t){
… …
r = 0.5 * (r-n/r); // 设置r变量
}
每当看到这样的注释——只注释是什么，而不注释为什么，相信你一定会被惹火，这是谁写的程序注释啊？不找来骂一顿看来是不会解气了。程序注释应该是告诉别人你的意图和想法，而不是告诉别人程序的语法，这是为了程序的易读性和可维护性，这样的为了注释而注释的注释，分明不是在注释，而是在挑衅，惹毛别人当然毋庸置疑。
第九位 打断
正当程序沉浸于编程算法的思考，或是灵感突现正在书写程序的时候，但却遭到别人的打断，那是一件非常痛苦的事情，如果被持续打断，那可能会让人一下子就烦躁起来。打断别人的人在这种情况下是非常不礼貌的。被打断的人就像函数调用一下，当其返回时，需要重新恢复断点时的现场，当然，人不是电脑，恢复现场通常是一个很痛苦的过程，极端的情况下可能需要从头开始寻找思绪，然后一点一点地回到断点。
因此，我看到一些程序员在需要安静不被打扰的时候，要么会选择去一个没人找得到的地方，要么会在自己的桌子上方高挂一个条幅以示众人——“本人正执行内核程序，无法中断，请勿骚扰，谢谢！”，可能正在沉浸于工作的程序被打断是多么大的开销。自然，被打断所惹毛了的人也不在少数了。
第八位 需求变化
这个事情估计不用多说了。只要是是程序员，面对需求变化的时候可能总是很无奈的。一次两次可能还要吧接受，但也顶不住经常变啊。据说敏捷开发中有一套方法论可以让程序员们享受需求的变化，不知道是真是假。不过，今天让你做一个书桌，没有让你把书桌改成餐桌，后天让你把餐桌改成双人床，大后天让你把床改成小木屋，然后把小木屋再改成高楼大厦。哎，是人都会被惹毛了的。那些人只用30分钟的会议就可以作出任何决定，但后面那几十个程序员需要搭上几百个小时的辛苦工作。如果是我，可能我也需要神兽草泥马帮助解解气了。
不过，这也正说明了，程序员并不懂得怎么和用户沟通，而用户也不懂得和程序员沟通，如果一个项目没有一个中间人（如：PM）在其中协调的话，那么整个项目可能就是“鸡同鸭讲”，用户和程序员都会被对方所惹毛了。如果要例举几个用户被惹毛的事情，估计程序员的那种一根筋的只从技术实现上思考问题的方法应该也能排进前5名。
第七位 经理不懂技术
外行领导内行的事例还少吗？领导一句话，无论对不对，都是对的，我们必需照做，那怕是多么愚蠢多么错误的决定，我们也得照做。程序员其实并不怕经理不懂技术，最怕的就是不懂技术的经理装着很懂技术。最可气的是，当你据理力争的挑站领导权威的时候，领导还把你视为异类。哎，想起这样的领导别说是骂人了，打人的冲动都有了。
其实，经理只不过是一个团队的支持者，他应该帮助团队，为团队排忧解难。而不是对团队发号施令。其实管理真的很简单，如果懂的话，就帮着做，如果不懂的话，就相信下属，放手让下属做。最怕的就是又不懂技术，还不信任下属的经理了。哎，这真是程序员的痛啊。
第六位 用户文档
用户文档本来不应该那么的令人害怕。这些文档记录了一切和我们所开发的软件有关的一些话题。因为我们并不知道我们所面对的用户的电脑操作基础是什么样的，所以，在写下这样的文档的时候，我们必需假设这个用户什么也不懂。于是，需要用最清楚，最漂亮的语言写下一个最丰富的文档。那怕一个拷贝粘贴的操作，可能我们都要分成五、六步来完成，那怕是一个配置IP地址的操作，我们也要从开始菜单开始一步一步的描述。对于程序员来说，他们在开发过程中几乎天天都在使用自己开发的软件，到最后，可能都有得有点吐了，但还得从最简单的部份写这些文档，当然容易令他们烦燥，让程序员来完成这样的文档可能效果会非常不好。所以，对于这样的用户文档，应该由专门的人来完成和维护。
第五位 没有文档
正如上一条所说的，程序员本来就不喜欢写文档，而因为技术人员的表达能力和写作能力一般都不是太好，所以，文档写的也很烂。看看开源社会的文档可能就知道了。但是，我们可爱的程序员另一方面最生气的却是因为没有文档。当然，让面说是的用户的文档，这里我们说的是开发方面的文档，比如设计文档，功能规格，维护文档等等。不过，基本上都是一样的。反正，一方面，我们的程序员不喜欢写文档，另一方面，我们的程序又会被抱怨没有文档，文档太少，或者文档看不懂。呵呵。原来在抱怨方面也有递归啊。据说，敏捷开发可以降低程序开发中的文档，据说他们可以把代码写得跟文档和示图似的，不知道是真是假。不过，我听过太多太多的程序员抱怨没文档太少，文档太差了，这个方面要怪还是怪程序员自己。
第四位 部署环境
虽然，程序员们开发的是软件，但是我们并不知道我们的程序会被部署或安装在什么样的环境下，比如，网络上的不同，RAID上的不同，BIOS上的不同，操作系统的不同（WinXP和Win2003），有没有杀毒软件，和其它程序是否兼容，系统中有流氓软件或病毒等等。当然，只要你的软件出现错误，无论是你的程序的问题，还是环境的问题，反正都是你的问题，你都得全部解决。所以，程序员们并不是简单地在编程，很多时候，还要当好一个不错系统管理员。每当最后确认问题的原因是环境问题的时候，可能程序员都是会心生怨气。
第三位 问题报告
“我的软件不工作了”，“程序出错了”，每当我们听到这样的问题报告的时候，程序员总是感到很痛苦，因为这样的问题报告等于什么也没有说，但还要程序员去处理这种错误。没有明确的问题描述，没有说明如果重现问题，在感觉上，当然会显得有点被人质问的感觉，甚至，在某些时候还掺杂着看不起，训斥的语气，当然，程序员基本上都是很有个性的，都是软硬不吃的主儿，所以，每当有这样的语气报告问题的时候，他们一般也会把话给顶回去，当然，后面自己然发生一些不愉快的事情。所以，咱们还是需要一个客服部门来帮助我们的程序员和用户做好沟通。
第二位 程序员自己
惹毛程序员的可能还是程序员自己，程序员是“相轻”的，他们基本上都是持才傲物的，总是觉得自己才是最牛的，在程序员间，他们几乎每天都要吵架，而且一吵就吵得脸红脖子粗。在他们之间，他们总是被自己惹毛。
- 技术上的不同见解。比如Linux和Win，VC++和VB，Vi和Emacus，Java和C++，PHP和Ruby等等，等等。什么都要吵。
- 老手对新手的轻视。总是有一些程序员看不起另一些程序员，说话间都带着一种傲慢和训斥。当新手去问问题的时候，老手们总是爱搭不理。
- 在技术上不给对方留面子。不知道为什么，程序员总是不给对方留面子，每当听到有人错误理解某个技术的时候，他们总是喜欢当众大声指证，用别人的“错误”来表明自己的“博学”，并证明他人的“无知”。
- 喜好鄙视。他们喜好鄙视，其实，这个世界上没有一件事是完美的，有好就有不好，要挑毛病太容易了。程序员们特别喜欢鄙视别人，无论是什么的东西，他们总是喜欢看人短而不看人长。经常挂在他们嘴上的口头禅是“太差”、“不行”等等。
程序员，长期和电脑打交道，编写出的代码电脑总是认真的运行，长期养成了程序员们目空一切的性格，却不知，这个世界上很多东西并不是能像电脑一样，只要我们输入正确的指令它就正确地运行这么简单。程序员，什么时候才能变成成熟起来……
第一位 程序员的代码
无论你当时觉得自己的设计和写的代码如何的漂亮和经典，过上一段时间后，再回头看看，你必然会觉得自己的愚蠢。当然，当你需要去维护他人的代码的时候，你一定要在一边维护中一边臭骂别人的代码。是否你还记得当初怎么怎么牛气地和别人讨论自己的设计和自己的代码如何如何完美的？可是，用不了两年，一刚从学校毕业的学生在维护你的代码的过程当中就可以对你的代码指指点点，你的颜面完全扫地。呵呵。当然，也有的人始终觉得自己的设计和代码就是最好的，不过这是用一种比较静止的眼光来看问题。编程这个世界变化总是很快的的，很多事情，只有当我们做过，我们才熟悉他，熟悉了后才知道什么是更好的方法，这是循序渐进的。所以，当你对事情越来越熟悉的时候，再回头看自己以前做的设计和代码的时候，必然会觉得自己的肤浅和愚蠢，当然看别人的设计和代码时，可能也会开始骂人了。
（全文完）
优秀程序员的十个习惯编辑本段回目录
在这个世界上，有数百万的人热衷于软件开发，他们有很多名字，如：软件工程师（Software Engineer），程序员（Programmer），编码人（Coder），开发人员（Developer）。经过一段时间后，这些人也许能够成为一个优秀的编码人员，他们会非常熟悉如何用计算机语言来完成自己的工作。但是，如果你要成为一个优秀的程序员，你还可以需要有几件事你需要注意，如果你能让下面十个条目成为你的习惯，那么你才能真正算得上是优秀程序员。
1. 学无止境。就算是你有了10年以上的程序员经历，你也得要使劲地学习，因为你在计算机这个充满一创造力的领域，每天都会有很多很多的新事物出现。你需要跟上时代的步伐。你需要去了解新的程序语言，以及了解正在发展中的程序语言，以及一些编程框架。还需要去阅读一些业内的新闻，并到一些热门的社区去参与在线的讨论，这样你才能明白和了解整个软件开发的趋势。在国内，一些著名的社区例如：CSDN，ITPUB，CHINAUINX等等，在国外，建议你经常上一上digg.com去看看各种BLOG的聚合。
2. 掌握多种语言。程序语言总是有其最适合的领域。当你面对需要解决的问题时，你需要找到一个最适合的语言来解决这些问题。比如，如果你需要性能，可能C/C++是首选，如果你需要跨平台，可能Java是首选，如果你要写一个Web上的开发程序，那么PHP，ASP，Ajax，JSP可能会是你的选择，如果你要处理一些文本并和别的应用交互，可能Perl, Python会是最好的。所以，花一些时间去探索一下其它你并熟悉的程序语言，能让你的眼界变宽，因为你被武装得更好，你思考问题也就更为全面，这对于自己和项目都会有好的帮助。
3. 理性面对不同的操作系统或技术。程序员们总是有自己心目中无可比拟的技术和操作系统，有的人喜欢Ubuntu，有的人喜欢Debian，还有的人喜欢Windows，以及FreeBSD，MacOSX或Solaris等等。看看我的BLOG(http://blog.csdn.net/haoel)中的那篇《其实Unix很简单》后的回复你就知道程序员们在维护起自己的忠爱时的那份执着了。只有一部分优秀的程序员明白不同操作系统的优势和长处和短处，这样，在系统选型的时候，才能做到真正的客观和公正，而不会让情绪影响到自己。同样，语言也是一样，有太多的程序员总是喜欢纠缠于语言的对比，如：Java和Perl。哪个刚刚出道的程序员没有争论去类似的话题呢？比如VC++和Delphi等等。争论这些东西只能表明自己的肤浅和浮燥。优秀的程序并不会执着于这些，而是能够理性的分析和理心地面对，从而才能客观地做出正确的选择。
4. 别把自己框在单一的开发环境中。 再一次，正如上面所述，每个程序员都有自己忠爱的工具和技术，有的喜欢老的（比如我就喜欢Vi编辑程序），而有的喜欢新的比如gedit或是Emacs等。有的喜欢使用像VC++一样的图形界面的调试器，而我更喜欢GDB命令行方面的调式器。等等等等。程序员在使用什么样的工具上的争论还少吗？到处都是啊。使用什么样的工具本来无所谓，只要你能更好更快地达到你的目的。但是有一点是优秀程序员都应该了解的——那就是应该去尝试一下别的工作环境。没有比较，你永远不知道谁好谁不好，你也永远不知道你所不知道的。
5. 使用版本管理工具管理你的代码。千万不要告诉我你不知道源码的版本管理，如果你的团队开发的源代码并没有版本管理系统，那么我要告诉你，你的软件开发还处于石器时代。赶快使用一个版式本管理工具吧。CVS 是一个看上去平淡无奇的版本工具，但它是被使用最广的版本管理系统，Subversion 是CVS的一个升级版，其正在开始接管CVS的领地。Git 又是一个不同的版本管理工具。还有Visual SourceSafe等。使用什么样的版本管理工具依赖于你的团队的大小和地理分布，你也许正在使用最有效率或最没有效率的工具来管理你的源代码。但一个优秀的程序员总是会使用一款源码版本管理工具来管理自己的代码。如果你要我推荐一个，我推荐你使用开源的Subversion。
6. 是一个优秀的团队成员。 除非你喜欢独奏，除非你是孤胆英雄。但我想告诉你，今天，可能没有一个成熟的软件是你一个人能做的到的，你可能是你团队中最牛的大拿，但这并不意味着你就是好的团队成员。你的能力只有放到一个团队中才能施展开来。你在和你的团队成员交流中有礼貌吗？你是否经常和他们沟通，并且大家都喜欢和你在一起讨论问题？想一想一个足球队吧，你是这个队中好的成员吗？当别人看到你在场上的跑动时，当别人看到你的传球和接球和抢断时，你的团员成员能因为你的动作受到鼓舞吗？
7. 把你的工作变成文档。 这一条目当然包括了在代码中写注释，但那还仅仅不够，你还需要做得更多。有良好的注释风格的代码是一个文档的基础，他能够让你和你的团队容易的明白你的意图和想法。写下文档，并不仅仅是怕我们忘了当时的想法，而且还是一种团队的离线交流的方法，更是一种知识传递的方法。记录下你所知道的一切会是一个好的习惯。因为，我相信你不希望别人总是在你最忙的时候来打断你问问题，或是你在休假的时候接到公司的电话来询问你问题。而你自己如果老是守着自己的东西，其结果只可能是让你自己长时间地深陷在这块东西内，而你就更本不可以去做更多的事情。包括向上的晋升。你可能以为“教会徒弟能饿死师父”，但我告诉你，你的保守会让你失去更多更好的东西，请你相信我，我绝不是在这里耸人听闻。
8. 注意备份和安全。 可能你觉得这是一个“废话”，你已明白了备份的重要性。但是，我还是要在这里提出，丢失东西是我们人生中的一部份，你总是会丢东西，这点你永远无法避免。比如：你的笔记本电脑被人偷了，你的硬盘损坏了，你的电脑中病毒了，你的系统被人入侵了，甚至整个大楼被烧了，等等，等等。所以，做好备份工作是非常非常重要的事情，硬盘是不可信的，所以定期的刻录光盘或是磁带可能会是一个好的方法，网络也是不可信的，所以小心病毒和黑客，不但使用软件方面的安全策略，你更需要一个健全的管理制度。此外，尽量的让你的数据放在不同的地方，并做好定期（每日，每周，每月）的备份策略。
9. 设计要足够灵活。 可能你的需求只会要求你实现一个死的东西，但是，你作为一个优秀的程序，你应该随时在思考这个死的东西是否可以有灵活的一面，比如把一些参数变成可以配置的，把一些公用的东西形成你的函数库以便以后重用，是否提供插件方面的功能？你的模块是否要以像积木一样随意组合？如果要有修改的话，你的设计是否能够马上应付？当然，灵活的设计可能并不是要你去重新发明轮子，你应该尽可能是使用标准化的东西。所谓灵话的设计就是要让让考虑更多需求之外的东西，把需求中这一类的问题都考虑到，而不是只处理需求中所说的那一特定的东西。比如说，需要需要的屏幕分辨率是800×600，那么你的设计能否灵活于其他的分辨率？程序设计总是需要我们去处理不同的环境，以及未来的趋势。我们需要用动态的眼光去思考问题，而不是刻舟求剑。也许有一天，你今天写的程序就要移植到别的环境中去，那个时候你就能真正明白什么是灵活的设计了。
10. 不要搬起石头砸自己的脚。程序员总是有一种不好的习惯，那就是总是想赶快地完成自己手上的工作。但情况却往往事已愿违。越是想做得快，就越是容易出问题，越是想做得快，就越是容易遗漏问题，最终，程序改过来改过去，按下葫芦起了瓢，最后花费的时间和精力反而更多。欲速而不达。优秀程序员的习惯是前面多花一些时间多作一些调查，试验一下不同的解决方案，如果时间允许，一个好的习惯是，每4个小时的编程，需要一个小时的休息，然后又是4个小时的编码。当然，这因人而异，但其目的就是让你时常回头看看，让你想一想这样三个问题：1）是否这么做是对的？2）是否这么做考虑到了所有的情况？3）是否有更好的方法？想好了再说，时常回头看看走过的路，时常总结一下过去事，会对你有很大的帮助。
以上是十条优秀程序员的习惯或行为规范，希望其可以对你有所帮助。
本文来源于网上phil的BLOG，但我在写作过程中使用了自己的语言和方法重新描述了一下这十条，所以，我希望你在转载的时候能够注明作者和出处以表示对我的尊重。谢谢！
文章：来源
