(转)首先为人编写程序,其次才是计算机

Posted by Tango on October 15, 2015

“首先是为人编写程序,其次才是计算机”,这是软件开发的基本要点,软件的生命周期贯穿于产品的开发、测试、生产、发布、用户使用、版本升级和后期维护等长期过程中,只有易读、易维护的软件代码才具有生命力。

在实际的软件开发过程中,可能是由于工作很忙的原因,很多开发人员只注重实现程序的基本功能,而忘记了编程规范,因此写出来的代码只能让计算机看懂,人要看懂很不容易。更有甚者,有些项目组为了赶进度,明确要求组员以实现产品功能为主,代码能够运行起来就可以了。低要求产生低质量的代码,既然“上头”都这样要求了,那还有必要写出“让人能够读懂”的代码吗?

如果不为人编程,带来的后果是?

在我参与过的软件开发项目中,有些时候,版本的开发时间非常的紧。在最初的会议上,开发经理就明确要求优先保证功能的实现,其它的留待以后优化。而当软件版本发布之后,就再也没有人提程序优化的事情了。下次有新需求的时候,大家才会发现上一个版本的程序写得是多么的糟糕。但没有人想到要先对程序进行优化甚至重构之后再实现新的需求,而是“破罐子破摔”,继续在低质量的代码上编写低质量的代码。如此一个恶性循环,最后的程序是千疮百孔,已无力回天。

在忽视代码质量的情况下,项目进度是赶上了,产品也交付出去了,一切看来是OK的,但问题也就来了。前方产品故障频发,后方开发人员不停地扑火。这个时候,他们才发现之前别人写的代码很难读懂,甚至连阅读自己写的代码都十分的困难,真是悔不当初。如果开始的时候能够将代码写规范一点,文档配备齐全一点,何至于此?

“好”的代码和“不好”的代码给人的感觉是千差万别。当我们看到优美的代码时,会有一种想继续研究下去的欲望,甚至会有一种觉得很享受的感觉。相反,当我们看到丑陋的代码时,就会咬牙切齿,因为它不仅不利于阅读,还会浪费我们很多时间,降低我们做事的效率。

一般说来,“好”的代码和“不好”的代码给我们的印象有如下几种:

排版工整 VS 排版不工整

我们打开一个代码文件的时候,最先看到的就是其排版怎样,这也是最直观的感觉。当代码排版工整时,我们很容易找出其条理和逻辑,会很快理解其到底要实现什么功能;而排版不工整的时候,我们的眼睛会觉得很累,进而影响了我们的思维。

命名规范 VS 命名不规范

在看完排版之后,我们就会看到每个函数和变量的命名。由于一般项目的代码行数都比较多,我们不可能花很多时间去理解每个函数和变量到底是何用意,到底是拿来做什么的。这就要求我们在编码的时候,使函数和变量的命名具有自说明性,让它们自己告诉读者是做什么用的,而不是要别人花大量时间去研读后才能知道。这在一定程度上反映了开发人员的态度和专业化程度。

例如,一个处理消息的函数,命名为ProcessMsg和FunctionA,哪个更好呢?显然是前者。我们只要一看到其名字,就知道它是做什么用的。

再如,有三个变量,命名为ReturnValue、MaxNum、SumOfTwoNum,我们就能一下子明白它们有何用途。第一个变量用于作为返回值,第二个变量用来存放最大数,第三个变量用来存放两个数之和。这太明显了,你都可以不用去问元芳,自己就能搞清楚。而如果同样三个变量,命名为i、j、k,你就无法一眼看出它们到底有什么用,还要花大量的时间去阅读代码,甚至用几个小时的时间,你还不知道它们有何用途。这时,你的老大来问你事情做得怎样,你照实一说,他便说你无能。其实你是“哑巴吃黄连”,怪就怪别人没有把代码写好。

注释得当 VS 注释不得当

阅读代码,我们还会注意到其是否有注释,注释多还是少。这也是很直观的。

如果代码实现的功能较为复杂,那么添加注释是必不可少的。在恰当的地方,使用恰当的注释,能够让读者觉得思路豁然开朗,他们会默默地在心里感激你。注释过少或没有注释是不行的,就像我们吃饭一样。如果一碗青菜里面什么也没有,你会觉得很乏味,没有食欲。如果放上一点辣椒酱,就会觉得食欲倍增。不管你信不信,反正我是信了。

但是,注释也不能过多,不能将有用的代码掩盖住了,不能够喧宾夺主,让真正实现功能的代码成了陪衬。

为人编程:如何才能写出让“人”看得懂的好代码

那么,我们如何写出让“人”能够看懂的“好”代码呢?这个过程不能一蹴而就,要循序渐进,要从我做起,从身边做起,不断地提升个人编程的境界。

个人认为可以考虑从以下几个方面入手:

第一,对新入职的员工进行软件编程规范的培训。在刚开始工作中的时候,让他们严格参照编程规范来编写代码。越早开展编程规范的训练,越是能够早地养成编写规范代码的习惯,写出的代码也就越清晰。顺便说句题外话,很多IT公司没有这方面的意识,只顾对企业文化进行培训,以为这样就能够让员工的忠诚度增加。实际上,这只是个异想天开的做法。

第二,定期在项目组开展编程规范方面的主题讨论,强化大家的意识。老员工写出的代码对新员工有示范的作用,如果老员工写出的程序都是可读性很差的,那么新员工会怎么想呢?他们又会怎么做呢?很多开发人员每天只顾埋头苦干,却忽略了一些最基本的东西,因此能力很难再次得到提升。在编写完代码之后,不要就以为事情做完了,还要编写一些项目文档,如详细设计文档、单元/集成测试文档等。在这些文档里面,把自己的思路写清楚,方便以后自己或他人查阅起来能够很快理解程序思路。

第三,开发人员严格按照公司制定的编程规范来书写代码。变量如何命名?函数如何命名?注释如何写?代码如何排版?这些都有严格的要求,作为一个合格的软件开发工程师,编写规范的代码是基本的要求。当我们阅读到书写优美的代码的时候,是不是心里面会觉得很爽?从某种程度上来说,代码编写的规范程度可以体现一个程序员的态度和专业素养。

第四,项目组要严格执行同行评审流程。大部分IT公司为了提高产品的质量,都有一个叫做“同行评审”的流程,也就是让项目组成员相互检查各自的成果,大家相互学习、取长补短、共同提高。但是,可能是中国文化的影响,大家都比较顾及面子,因此不愿意将对他人真实的想法表达出来,也使得“同行评审”流于形式。当然,也许你对别人的程序确实没有意见,那就另当别论了。对他人开诚布公地提意见并不是冒犯,而是大家相互学习的一种很好的方式。

第五,最重要的是,个人要有编写规范代码的意识,要不断地学习各种提高编程能力的技术。不管别人对你怎么说,如果你本人不想把程序写好,那么纵使万般外力,又如何?程序员虽然工作很忙,但也要抽时间来学习新的技术,这样才不会被新技术淘汰掉。

“KISS”(Keep It Simple Stupid)

在刘未鹏老师的文章《编程的首要原则》(http://mindhacks.cn/2009/03/09 … mming/)中,提倡编程的首要原则是“KISS”(Keep It Simple Stupid)。“KISS”意味着程序有以下特征:

  • 排版工整、变量命名规范、注释得当。
  • 逻辑清晰、接口定义清楚、函数封装得体。
  • 可扩展性强、便于维护。

“KISS”同时也是实现程序“正确性”的最佳途径,因为简单意味着无错,或者是即使有错误也能够被及早发现。遵循“KISS”原则,那么设计程序时采用的便是最简单直接的方法,逻辑清晰,不管是对于作者本人,还是对程序进行评审的人而言,都能够迅速理解程序实现的功能,bug很难生存。

如何检验一套程序是否是好的程序?我认为,如果一个新手能够很快将程序看懂并理清程序的逻辑,那么这个程序就是好程序。

总结

“长风破浪会有时,直挂云帆济沧海”,对于很多人来说,编写出能够让计算机读懂的程序就已经足够了,但如果想要成为一位优秀的软件开发工程师,那么就要力求写出让“人”能够很容易看懂并领会的代码。这是一个长期的过程,大家要有“万里长征”的准备,要有“愚公移山”的精神。

本文转自:http://www.daxixiong.com/?/article/6