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

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

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

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

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

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

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

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

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

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

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

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

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

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

普通的工程师堆砌代码,优秀的工程师优雅代码,卓越的工程师简化代码。如何写出优雅整洁易懂的代码是一门学问,也是软件工程实践里重要的一环。

想要成为什么样的工程师呢?新年伊始,和大家聊聊写代码那些事儿。

首先想问问大家,在工作中你有没有遇到这两个场景?

场景一:接手了别人的项目, 想要修改功能时却发现程序里充斥着各种无法理解的逻辑、改完之后莫名其妙的bug一个接一个,接手了这个项目后便开始漫无目的的加班。

场景二:当你看到一段不符合自己价值观的代码,理所当然认为写的烂,于是删掉了那段代码,用自己认为更好的方法重新写了一遍,觉得挽救了这个项目。但当对这部分业务逻辑熟悉了之后,发现所删代码中的处理方式是最恰当的。

工作中,对于烂代码和好代码的定义,真的是千人千面。现实环境的变化,也影响着你我对于代码“好”与“坏”的判断标准。软件开发有着不同的生命周期,一个典型的软件生命周期,大致可以划分计划、分析和设计、代码实现、测试、运营和维护这六个阶段当我们说代码质量的时候,说的是这整个生命周期, 比如说,代码写得快,可是测试起来一大堆问题,就不是好代码。所以最适合当前现实环境的代码,才是最优秀的代码。

人人都想写出好的代码,但并不是人人都能写出好的代码,想要写出优秀的代码,必须要养成好习惯。

640?wx_fmt=jpeg

良好的编程习惯意味着你可以用更少的努力:时间和精力的投入,产生更干净、简洁、智能的代码。

其实对于大多数的程序员来说,大部分工作就是crud,说句实在话,在公司里,如果我们很难追求所谓的技术驱动,那么我们一定能够做的是,对代码的态度,优雅干净

关于如何写好代码,我在网上调研了一圈,靠谱的资料非常少,**范学雷**老师的《代码精进之路》非常体系化,故在此推荐给大家。

范学雷老师,现在是 Oracle 的主任工程师,也是 OpenJDK 和 Java 安全的评审成员。他是1998年参加工作的,20多年了一直在一线从事编程工作,并且有非常丰富的代码评审经验,编程界元老级人物了,有这样过往的前辈来写这样一个专栏,最合适不过了。

这个专栏,看了目录,提炼了一下:

思维上:可以帮助你重塑代码价值观,提升识别“好坏”代码的能力,从而提升编程敏感度,比如你会对这样的问题更加了解。

  • 什么样的代码更容易出问题?

  • 什么样的代码会招惹麻烦?

  • 什么样的代码出力不讨好?

  • 什么样的代码小问题闯大祸?

方法实操:专栏紧贴工作实际场景,会告诉你如何消除代码的安全隐患,并且教你一些高频代码问题的最优处理和预防方案,这些都是非常实用的。

更具体的目录往下看

640?wx_fmt=png


一个好奇的人