怎么样才是好的程序员

转载自:http://wangyuanzju.blog.163.com/blog/static/1302920091130104953863/

要判断一个程序员是不是好的程序员，主要看他写的代码，因为程序员最重要的事是写代码。

即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感 。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。

再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性 。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。

如上，即便你不懂他所用的语言，不却关心程序的逻辑，对好的程序员还是差的程序员就能做到八九不离十的判断 。程序的好坏几乎总是取决于它们是否“漂亮”，不“漂亮”而好的程序，除了C++ STL源码，我再也没见过（如果你稍仔细看，STL的源码虽然不够“漂亮”，但仍然满足这里提出的一致性原则）。而又好又“漂亮”的代码则随处可见，如Linux Kernel，InnoDB，JDK，JUnit等等。

如果再仔细阅读，就能更准确。好的程序员写的代码，好似浑然天成，简单而直白 。函数通常较短小，函数的名称准确的反映函数要完成的工作。逻辑简单而自然，让你读的时候由衷的发出“啊，就应该是这样”的感叹，而差的程序员的代码经常让你发出“怎么是这样？这是再干什么呀？”的疑问。好的程序员会在紧要关头加以画龙点睛般的注释，差的程序员要么没注释，要么注释只是代码的重复，纯粹是废话，更差的是注释是错的，是误导。

好的程序员未必是“语言律师”，即那种非常清楚的了解语言的各个细节，在编程时到处使用的家伙。好的程序员也不常“炫技”，在代码中精心构造一些独具匠心的片断，他们偶而会，但大多数时候总是用直白的语言来表述。

从代码也可以看出一个程序员的团队协作精神 。注意团队合作的程序员，会严格按照团队规范写代码，而风格与团队规范不一致的程序员则很可能欠缺团队精神。注意团队合作的程序员会注意给模块的对外接口加以重要的说明，如前置条件、后置条件、参数能否是NULL等等，不注意团队合作的程序员懒于处理这些细节。

好的程序员与差的程序员的生产力差别巨大，项目的周期越长，项目越复杂，项目对质量的要求越高，好的程序员的价值就越大。好的程序员与差的程序员，管理成本也差别巨大，好的程序员只需要与他共同确定设计，代码可以不看，差的程序员的代码经常需要经过多次review，且仍有可能达不到理想的质量。

要成为好的程序员，首先要树立要成为好的程序员的志向，再勤加练习，天长日久，就会越来越好，这些人不怕老。没有志向永远成不了好的程序员，这些人若不在老去之前成为经理就会变成废人。

通过两个小时的笔试和半个小时的面试对于判断程序员来说是不够的。通过笔试与面试，你可以判断一个程序员是否具备算法与数据结构等基础知识，可以判断他对编程语言的特性是否掌握，可以判断他对技术是否关注，然而要知道他能否真的能很好的完成工作，不写代码是不够的。

那些显得对技术充满热情的，未必是好的程序员。这些人可能非常乐意从事有新意的工作，但后续的编码、测试、调试、文案工作则可能让他们感到厌烦。他们可能会提出好的创意，但却经常不能够有始有终的将其完成。公司不需要多少这样的人。

因此招聘的方式需要改善。招聘是最重要的，因为进来后就难以出去，即便是试用。转正条件白纸黑字写的很清楚，只要合格就可以转正，要达到合格并不是很困难。今年部门里进了很多新人，并不是人人都很优秀，但确实也都合格，自然也应该转正。

改善招聘的方法，就是让他写程序，可以出两道题，一道让他写程序，一道让他重构一个已有的较长的程序，一天之内完成。假使可以考他半个月，那么重构是不太需要的，但一天的时间太短，通过重构可以考察阅读并理解代码，并通过重构“化腐朽为神奇”的能力。那些不愿意写别人的代码，不愿意接受别人的代码，经常要重来一遍的人是不理想的。

今年有两个人采用了类似的方法。有一位简历很优秀的人，做了两道编程题被拒了，有一位简历及面试一般的人，通过编程测试，录用了。我感觉比单纯的笔试与面试要准确。