高效程序员的 7 个共同特征

导读：要想成为一个伟大的程序员，需要的可不仅仅是能够编写出可以正常运行的代码。Justin James给出了能够成为业内顶尖高手的程序员应该具有的几个典型特质。

要想成为高效的程序员，你需要具备一定的综合素质才能够让你用你所掌握的技能、经验和知识编写出有效的代码。有一些开发人员在技术方面具备一定的技巧，但他们永远无法成为高效的程序员，就是因为他们缺乏所需的其它几项特质。本文将给出成为一个伟大的程序员所必须具备的7项特质。

1. 主动学习新的技术和非技术两方面的知识

不好的程序员只有在实在不行的时候才开始进行知识学习。良好的程序员会主动学习新的技术知识。伟大的程序员不仅会自行学习新的技术知识， 而且还会学习非技术方面的知识，对各种知识来源都有一种开放的心态，而不会象有的人那样固步自封。

具体点说，不好的程序员只有在参加了采用WPF的项目时才开始学习XAML；良好的程序员一年前就学习了XAML，因为他感觉它很有意思；而伟大的程序员还阅读了WPF应用程序的设计指南、可用性（usability）理论或者什么类似的学习课程，因而他能够制作出卓尔不群的UI。

2. 务实而不教条

严格遵守那些不成文的“编程规则”往往是一种奢侈品，没有多少开发人员能够承受得起。如果你们的规格说明书不是由顶尖的开发人员编写的，也不是在顶尖的开发人员指导下编写的， 我就可以向你保证，你可能也承受不起。

我经常能够碰到一些程序员，他们无法或者拒绝做某个任务只是因为完成这个任务的做法通常不为最佳实践所接受。业务需求很少会受到实现需求所采用的技术的制约；没有人会说，“这我们不应该把这个需求写到规格说明书里，因为要实现这个需求，程序员就不得不写一段很臭的代码。”

在结束的那一天，程序员的任务是要生成一个有效的应用程序，而绝不是要求在技术方面达到十全十美。我可不是在为垃圾代码做辩护。我想说的是，总会在有些时候，你会写出一些代码，这些代码你永远不会作为范例向别人展示做事的正确方法。如果只有一种写法，那么这种代码就不是糟糕的代码 ——  但要保证你已穷尽了其它所有可能的方案。

3. 懂得如何通过研究找到答案

通过研究找到答案可不仅仅只是在搜索引擎中键入几个关键字那么简单， 也不是到Stack Overflow或者MSDN forums这类网站发个问题帖。我就碰到过在搜索引擎里根本搜不到答案的问题，然后我Stack Overflow 或者MSDN forums里发的所有问题贴都没有一个像样的答案，不过我还是解决了我所碰到的问题使得工作得以继续。我不是魔术师 —— 我只是懂得如何找到答案，如何找出问题的根本原因。

有许问题都属于情景式的问题，如果你依赖于搜索引擎或者论坛，就会在各种链接中浪费大量的时间而最终无法得到真正的答案。要学习如何进行根本原因分析，学习底层系统方面的知识才能够找到其它的线索和解决方案，还要学习如果在对问题有个全局性的认识后才对其进行深入分析。

4. 拥有激情

不喜欢这份工作，就无法成为这个行业中的顶尖高手。倒是也有一些仅仅把编程当作一份普通工作的程序员水平也还不错，但如果你的三观就是如此的话，你就不太会愿意去做能够将你引向成功的所有事情。这个观点会使很多家伙不悦，因为他们会觉得这是一种人身侮辱。“我是一个很好的程序员，但我还有其它重要的事情要做，我不能让工作成为我人生的全部。” 我完全理解；我也有别的更重要的事情。尽管我也痛恨这么说，当我们对我的工作热情高涨之时，我愿意（虽然不是渴望）抛弃我其它更重要的事情来首先完成手头的工作。要说你不愿意全情投入就无法成为高手，不算是人身侮辱，这是事实而已。

你的激情不能仅仅只在编程一个方面 —— 你必须在你的工作、你所使用的技术、你的老板、你的项目等等方面都有激情。 我目睹过一些非常好甚至很伟大的程序员其表现平平，只是因为有一些条件不太合适。比如，他们不喜欢手头的项目，或者项目中所用的技术让他们讨厌。我曾经就是一个这样的程序员，我也同这样的程序员一起共过事。无论从哪个角度讲，我都不喜欢这样的程序员。如果你发现你的情况就是如此，就需要立即解决这个问题，要么挖掘出手头的工作或项目中有意思的地方从而能让你调整心情，要么就不要接着干了。怪不值当的。

5. 将自负留在门外

许多开发人员都非常自负。仅仅是比有些人聪明、懂得多一点或者经验更丰富一点，可不是意味着和那些人相比你才是好人。你要尊重别人，真正听取并考虑别人的观点，在需要的时候向他们求助，而且还不能小瞧别人。 你还应该更加关心团队的胜败，而不是仅仅关心你在工作中的荣誉得失。

6. 具有企业家的精神

最优秀的开发人员不会是游手好闲者。对他们来讲，产品的成功不仅仅意味着他们的薪水有着落了。因为他们在工作中热情饱满，他们是为了项目有更好的发展而工作，而且会一往无前。

7. 测量两次，下刀一次。。。但测量不要多于三次

开发人员可能会犯的最糟糕的错误之一就是还不知道要干什么呢，就一猛子扎到代码里去了。（当他们把这种做法称作敏捷开发时情况更为糟糕，好像用敏捷两字就能让情况好转似的）。当伟大的开发人员跳进代码里去的时候，那是因为需求规格说明同他们以前实现过的某种做法十分相似。伟大的程序员在面临新问题时，他们会进行思考、计划和研究。

开发人员当中最最优秀的不会堕入“分析瘫痪者（analysis paralysis）”陷阱。他们懂得要对某些事情小心谨慎（比如涉及钱或个人数据时），只有这些特殊领域才适合我所说的“要测量三次”。任何超过三次的情况发生就意味着你在浪费你的时间（除非在鲜有的特例中，比如核反应堆、宇宙飞船、对冲基金会计系统）。

在某个特定的时间点就要停止计划，开始编码，然后再看看你的计划在哪些方面需要进行相应的调整，这一点非常重要。顺便说一下，这就是我为什么成为敏捷方法拥趸的原因之一。我所知道的最优秀的开发人员在计划不再合适或者发现计划有缺陷时，都会愿意将计划放弃掉。

一段旅程就这样结束了。。。

写这篇文章让我有点伤心。作为TechRepublic的撰稿人足足七年多了，很不幸现在却到了暂时卸下我作为自由撰稿人的身份的时候了，因为我们的全职工作真的是太忙了。就在去年，我不得不终止为10 Things blog和 Patch Tuesday series撰稿，现在由不得不停止Software Engineer blog了。

我爱我同TechRepublic在一起的每一段时光。我很高兴能够认识到各位读者、我的共同撰稿人以及TechRepublic的各位员工。我的编辑，Mary Weilage，一直都是我所写的软件工程师博客的幕后英雄。正是他才让我看上去不象是个傻瓜、呆子，他还在很多场合下帮我纠正了许多语法错误。

感谢所有阅读我的文章的读者。我希望将来能够再回来继续为TechRepublic撰稿。