MckeeのClub & SAKI'sブログ

熟练人员经过多年的积累加上自己的CodeSnip的总结，基本不用额外再查找资料。而一般的开发人员在开发过程中会花掉10-20%时间去查找资料。

熟练人员注意代码复用，并且时刻注意重构和抽取公用代码。一般开发人员是代码拷来拷去完成功能。

熟练人员非常注意查找，定位，标签等各种快捷键的使用，定位查找方便快捷，IDE环境也根据习惯定义到最方便状态。

熟练人员编码前先思考清楚整个流程，在头脑或纸张上规划好整个实现方式和方法函数的划分。一般人员想到哪里写到哪里。

熟练人员写了50行以上或更多代码才Debug一两次，一般人员写了几行代码就要Debug多次，完全通过Debug来验证代码正确性。

熟练人员注重代码的质量，单元测试和可维护性，注重各种业务逻辑的验证和边界条件的校验。一般人员只注重简单功能的简单完成。

熟练人员提交测试的代码BUG很少，返工工作量很小。一般开发人员由于自测不完善BUG较多，造成大量的返工工作量。

熟练人员合理分配自己的时间，规划好每天工作任务，开发过程各位专注。一般开发人员一心多用，边开发边聊Q。

熟练人员善于知识的总结和积累，形成自我的知识库和经验库。

熟练人员善于发现问题，分析不足而自我持续改进。一般人员在外力干预侠被动改进。

熟练开发人员开发重点已经专业到对业务的深刻理解，一般开发人员考虑的是开发上编程的语言和工具。

熟练人员善于从各种影响自己开发效率的因素中挤时间，善于使用各种辅助开发工具。而一般人员则不善于这种总结。

来自： http://blog.csdn.net/haoel/archive/2009/04/06/4053048.aspx

程序员是一个比较特殊的群体，他们因为长期和电脑打交道所养成的性格和脾气也是比较相近的。当然，既然是人，当然是会有性格的，也是会有脾气的。下 面，让我来看看十件能把程序员惹毛了的事情。一方面我们可以看看程序员的共性，另一方面我们也可以看看程序员的缺点。无论怎么样，我都希望他们对你的日常 工作都是一种帮助。

第十位 程序注释

程序注释本来是一些比较好的习惯，当程序员老手带新手的时候，总是会告诉新手，一定要写程序注释。于是，新手们当然会听从老手的吩咐。只不过，他们可能对程序注释有些误解，于是，我们经常在程序中看到一些如下的注释：

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等等，等等。什么都要吵。
• 老手对新手的轻视。总是有一些程序员看不起另一些程序员，说话间都带着一种傲慢和训斥。当新手去问问题的时候，老手们总是爱搭不理。
• 在技术上不给对方留面子。不知道为什么，程序员总是不给对方留面子，每当听到有人错误理解某个技术的时候，他们总是喜欢当众大声指证，用别人的“错误”来表明自己的“博学”，并证明他人的“无知”。
• 喜好鄙视。他们喜好鄙视，其实，这个世界上没有一件事是完美的，有好就有不好，要挑毛病太容易了。程序员们特别喜欢鄙视别人，无论是什么的东西，他们总是喜欢看人短而不看人长。经常挂在他们嘴上的口头禅是“太差”、“不行”等等。

程序员，长期和电脑打交道，编写出的代码电脑总是认真的运行，长期养成了程序员们目空一切的性格，却不知，这个世界上很多东西并不是能像电脑一样，只要我们输入正确的指令它就正确地运行这么简单。程序员，什么时候才能变成成熟起来……

第一位 程序员的代码

无论你当时觉得自己的设计和写的代码如何的漂亮和经典，过上一段时间后，再回头看看，你必然会觉得自己的愚蠢。当然，当你需要去维护他人的代码的时 候，你一定要在一边维护中一边臭骂别人的代码。是否你还记得当初怎么怎么牛气地和别人讨论自己的设计和自己的代码如何如何完美的？可是，用不了两年，一刚 从学校毕业的学生在维护你的代码的过程当中就可以对你的代码指指点点，你的颜面完全扫地。呵呵。当然，也有的人始终觉得自己的设计和代码就是最好的，不过 这是用一种比较静止的眼光来看问题。编程这个世界变化总是很快的的，很多事情，只有当我们做过，我们才熟悉他，熟悉了后才知道什么是更好的方法，这是循序 渐进的。所以，当你对事情越来越熟悉的时候，再回头看自己以前做的设计和代码的时候，必然会觉得自己的肤浅和愚蠢，当然看别人的设计和代码时，可能也会开 始骂人了。

1） The only "best practice" you should be using all the time is "Use Your Brain".
唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式，框架，那些著名的方法、模式、框架只代码赞同他们的人多，并不代表他们适合你，你应该更多的去使用你的大脑，独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想，那才是“best practice”。事实上来说，那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2）Programmers who don't code in their spare time for fun will never become as good as those that do.
如果你对编程没有感到一种快乐，没有在你空闲的时候去以一种的娱乐方式去生活，无论是编程，还是运动，还是去旅游，那么你只不过是在应付你的工作，无时无 刻不扎在程序堆中，这样下来，就算是你是一个非常聪明，非常有才华的人，你也不会成为一个优秀的编程员，要么只会平平凡凡，要么只会整天扎在技术中成为书 呆子。当然，这个观点是有争议，热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3）Most comments in code are in fact a pernicious form of code duplication.
注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和code是重复的，毫无意义。

4）XML is highly overrated.
XML 可能被高估了。XML对于Web上的应用是不错的，但是我们把其用到了各种地方，好像没有XML，我们都不会编程了。

5）Not all programmers are created equal.
这是那些junior经理或是流程爱犯的错，他们总是认为，DeveloperA == DeveloperB，只要他们的title一样，他们以为他们的能力、工作速度、解决问题的方法，掌握的技能等等都是一样的。呵呵。更扯的是，在某些时候，就算是最差的程序员，他们也会认为其比别人强十倍，这就是现代的SB管理。

6）"Googling it" is okay!
Google 只会给你知识，并不会教给你技能。那里只有“鱼”，没有“渔”，过度的使用Google，只会让你越来越离不开他，你越来越去要去立马告诉你答案，而你越 来越不会自己去思考，自己去探索，去专研。如果KFC快餐是垃圾食品对我们的身体没有好处，那么使用Google也一种快餐文化对我们的智力发展大大的没 有好处。

7）If you only know one language, no matter how well you know it, you're not a great programmer.
如果你只懂一种语言，准确的说，如果你只懂一类语类，如：Java和C#，PHP和Perl，那么，你将会被局限起来，只有了解了各种各样的语言，了解了不同语言的不同方法 ，你才会有比较，只有了比较，你才会明白各种语言的长处和短处，才会让你有更为成熟的观点，而且不整天和别的程序在网上斗嘴争论是Windows好还是 Unix好，是C好还是C++好，有这点工夫能干好多事了。世界因为不同而精彩，只知道事物的一面是有害的。

8）Your job is to put yourself out of work.
你的工作不是保守，那种教会徒弟，饿死师父的想法，不但是相当短浅的，而且还是相当脑残的。因为，在计算机世界里，你掌握的老技术越多，你就越没用，因为 技术更新的太快。你对工作越保守，这个工作就越来越离不开你，你就越不越不能抽身去学新的东西，你也就越来越OUT了。记住：If you can't be replaced then you can't be promoted!

9）Design patterns are hurting good design more than they're helping it.
很多程序员把设计模式奉为天神，他们过度的追求设计模式以至都都忘了需求是什么，结果整个系统设计被设计模式搞得乱七八糟，我们叫这种编程为“设计模式驱 动编程”，正如第一点所说，如果你不懂得用自己的大脑思考的话，知其然，不知所以然的话，那么你不但得不到其好处，反而受其所累。

10）Unit Testing won't help you write good code.
准确地说，我们可以认为这是Test-Driven开发，其实，这种开发就是先写unit test case，这样的开发方式的主要目的是，为了防止你不会因为一个改动而引入Bug，但这并不会让你能写出更好的代码。这只会让你写出不会出错的代码。同第一点，这样的方法，只不过是防止糟糕的程序员，而并不是让程序员或代码质量更有长进。反而，通过Unit Test会为程序员的为自己代码做辩解的一种托辞。

在一个小公司里，对于一个刚工作的程序员来说，作用和意义重大；在这个人员有限、资源有限的办公环境下，你会被一人当多人使！你会接到开发项目来做，你会 有机会接触各方面的知识；和同事之间能够相互学习和探究技术；但是如果你去了一家大公司，一旦有开发项目，身为新手的你，不会在考虑范围之内，因为人家有 的是强人，给你做的话不怕你做不好，更怕你耽误时间~ 还有一点很重要，如果你有问题想去请教他人，你感觉人家会有耐心跟你讲解么？别忘记了这里是大公司，人家请的都是大牛，大牛都很忙~~

来自: www.ituring.com.cn

缺乏根据代码推导的能力

　　根据代码推导意味着能够跟踪执行路径（“在脑子里运行程序”），并且明白代码的目标是什么。

　　症状表现

1. 存在“莫名代码”，或是对程序目标毫无成效，但却在拼命维护的代码（比如，初始化了却从未使用的变量，调用了和目标无关的函数，产生了未被使用的输出等等）
2. 将等效函数多次执行（例如：多次调用 save ()函数，“只是为了确定真的保存了”）
3. 通过撰写多余代码覆盖掉出错代码的结果，来修复缺陷
4. “车轱辘话代码”（yoyo code），即将一个值转换成一种不同的表示，然后又把它转换成原始的样子。（例如：将一个十进制数转换成一个字符串，又转回一个十进制数，或用空白填充一个字符串，又对它做空白修剪操作）
5. “推土机式代码”（bulldozer code），表面上看是把代码块打散成若干子程序的重构动作，但是这些打散后的若干子程序却完全不可能在另一种环境中复用（因为它们之间有很高的耦合，不能分开使用）

　　补救措施

　　为了克服这方面的不足，程序可以采用 IDE 自带的调试器作为辅助，如果该调试器提供了单行步进能力的话。例如，在 Visual Studio 中，就可以在出问题的代码区块的开头设置一个断点，并通过按“F11”键单行步进，并检查变量值的前后变化——直到你理解代码是要做什么事为止。如果目标 环境中没有调试器这种功能特性，那就找一个有这种特性的来练手。

　　我们的目标是达到这么一个状态，你可以不再需要调试器就可以在脑子里来跟踪代码走向，并且你有了足够的耐心来根据程序状态来思考代码在做什么。回报是识别冗余和无用代码的能力，以及从已有代码中发现缺陷，并且不必从头重新实现一遍整套算法。

　　未能透彻理解语言的程序设计模型

　　面向对象的程序设计是一个语言模型的例子，其他的还有函数式或声明式程序它们中的每一个都与面向过程的或是命令式的程序设计有着显著的不同，正 如面向过程的程序设计与汇编或是基于 GOTO 的程序设计有着显著的不同一样。还有一些语言，它们从属于一种主要的程序设计模型（比如面向对象的程序设计），但是同时也引入了一些它们提供的改进，比如 列表解析、泛型、鸭型型别（译注： 即用相同的接口和大部分输出响应来模拟某种型别，实际上有所不同的型别，用语取自谚语“如果它叫唤时像只鸭子、吃食时像只鸭子、连跛脚都像只鸭子，那它就是只鸭子”）等等。

　　症状表现

1. 不择手段地使用各种语法来打破当前使用的模型，尔后采用命令式/过程式风格来书写余下的程序
2. （面向对象）试图调用未实例化类中的非静态函数和变量，并且难以理解为何通不过编译（译注：即分不清类和对象）
3. （面向对象）写一大堆“xxxxxManager”类，里面包含所有操作类的方法，但这些类却没有自己的方法。（译注： 即仍然把类看作 struct，未能掌握用类自己的方法——C++中叫做成员函数——来操作类数据的新模型）
4. （关系型）将数据库当作一个对象存储，在客户代码中完成所有的连接和关系模塑
5. （函数式）为相同的算法创建多个函数版本来操作不同型别和操作数，而非将高层抽象的函数传递给一个泛化的实现
6. （函数式）手动缓存确定性函数（译注：即对于同样输入返回同样结果的函数）的返回结果，即使平台会自动完成这件事（例如 SQL 和 Haskell）
7. （纯函数式）使用从别人程序里复制-粘贴的代码来处理与I/O和单子
8. （声明式）采用命令式代码逐个地设置变量的值，而不使用数据绑定

　　补救措施

　　如果你的技能缺乏是无效教学或研究的产物，那么另一个老师就是编译器本身。要学习一种新的程序设计模型，在效果方面无与伦比的方法就是启动一个 新工程并将自己投入在应用那些全新结构上，别管它们是什么，也别管看上去傻不傻。你还需要练习使用你熟悉的一切来解释该模型的特性，用语不妨粗糙一些，然 后不断重复地构造你的新词汇表，直到你同样掌握了新特性的精妙之处为止。例如：

• 第1阶段：“面向对象就是带有方法的记录型别”（译注：记录即C-style struct）
• 第2阶段：“面向对象中的方法，就是在一个小程序里运行的函数，这个小程序带有自己专属的全局变量”
• 第3阶段：“这些全局变量被称为域，其中有些带有私有访问层级，在这个小程序之外是看不到它们的”
• 第4阶段：“为元素搞私有和公有访问层级的名堂，这个思想是要隐藏实现细节，并且只暴露一个干净的接口，即所谓封装”
• 第5阶段：“封装意味着我的业务逻辑不必被实现细节所污染”

　　第5个阶段看起来对所有语言都适用，因为它们的确是想要程序员理解到这一步，这样他们就可以表述程序的目的，而不会将它埋藏在如何实现的具体做法中。再举函数式程序设计作为另一例：

• 第1阶段：“函数式程序设计就是把确定性函数链接在一起”
• 第2阶段：“当所有的函数都成了确定性的，它们在要求输入结果之前不必被执行，并且只须需要多少结果就执行多少部分即可。即所- 谓缓式评估求值和部分评估求值”
• 第3阶段：“为了支持缓式评估求值和部分评估求值，编译器要求我以对单个参数做变换的形式撰写函数，有时变换的结果是另一个函数。即所谓柯里化”
• 第4阶段：“当所有的函数都完成了柯里化后，编译器就可以运用一个约束求解器来决定最佳执行计划了”
• 第5阶段：“通过让一个约束求解器来决定机器细节，我撰写程序时就可以只描述我想要什么结果，而非怎样得到结果了”