编者注：本文为历史博文归档；涉及 JDK、框架与工具链版本请以当前官方文档为准。引用外链图片可能失效，阅读时请注意时效性。

高效程序员的 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 撰稿。

J.Ja

原文地址：http://www.techrepublic.com/blog/programming-and-development/seven-traits-of-effective-programmers/6750

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处和本文链接。
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

说明：本文原文发表于 2013 年左右，文中提及的 WPF、XAML、MSDN Forums 等技术栈及社区平台具有时代特征。部分外链可能因网站结构调整而失效，阅读时请结合当前技术环境参考。