技术分享

南通东方标准论一个程序员的自我修养

在《喜剧之王》中,周星驰扮演的尹天仇,一直梦想成为一名演员,而他不管是在扮演跑龙套,或者在街坊中开设演员训练班,亦或成为主角时,他对待演员的态度,始终是认真,热爱而又投入的。而那一本他随身携带的书--《演员的自我修养》,尽管不知道里面具体写的是什么,但我猜,他对待演员的态度和行为,就是书中内容显示的。

  于是,不禁问了问自己,作为一名程序员,一个“程序员的自我修养”是什么?

  尽管我们不一定要像尹天仇那么的认真对待自己的事业,但,一些基本的修养,作为一名新时代的码农,总应该是要具备的吧。不过真要说修养,方面还是挺多的,技术自我提示自不必说。但我并不打算从这个大家都觉得理所当然的技术方面入手,而是谈谈,可读性代码,这个容易被大家忽视的基本素养。

1、遵从所在团队的代码规范。

  一个高效、成熟的团队,必定有一个属于自己的代码规范,这个规范是团队的宝贵的财富,它是整个团队从各种坑中爬起来后积累的经验教训。什么是规范,它是人们从无数经验中总结出来的规则,标准。而代码规范,指导团队成员如何以最短的时间写成最高效,可读性强的代码。试想,如果成员不遵从规范,你用驼峰命名,他用下划线,这对程序的可读,将造成多大的影响。我想,应该没有一个人愿意去阅读一段,各种变量命名形式都能见得到,private, public 方法随意排序,甚至常量类都散落在各个角落的代码吧。

  代码,一个作用是让机器阅读,另一个重要的作用是让人阅读!!!

 

2、遵从行业内通用的规范

  在团队的代码规范未涉及到的,那请按照行业内的规范来编写代码。规范的一个好处是,可以明显减少学习和交流成本。在java中,当我们看到全大写的变量名时,我们就知道这是常量,而不需要去看注释,不需要去看代码逻辑。为什么这么迅速,因为行业里大家都习惯把常量用大写命名。但假如你用其他命名方式命名常量,比如team_nums命名常量,不仅不能让人迅速知道这是个常量,而且可能让人误会这是个变量,增加了团队成员学习和沟通成本,甚至可能误导他们。就见过一位仁兄,明明用的是工厂模式,偏偏按模版模式的命名方式来命名,问他,他说他知道这是工厂模式,但他觉得,更应该叫模版模式。。。我的天,,你这么任性,以后还能做朋友么?

  举个例子,我们需要根据支付类型,来生产多个支付产品,于是,我们写了个工厂类,命名为FactoryPay。当其他人看到一个类叫FactoryPay,他们会猜测,这应该是个工厂类,负责生产各种支付产品的工厂,然后按照这个猜测去阅读代码,就能比较快速的理解整个类的作用。但是,假如我取名PowerPay,别人还不知道是啥,看了半天,才明白,这是个工厂的作用。这就明显增加了他人的学习成本和维护代码的成本。

  不管你是新手还是老鸟,务必了解施行行业规范,切勿为了标新立异而违反规范。这么低端的装逼,就没必要采用了,要装也写个高端的框架来提升逼格呗。

 

3、变量、方法命名要能表达变量作用

  在程序员这个圈子很久了,就发现,程序员这货,都喜欢这套,“这个接口干嘛用的,有文档么”,“自己看代码去”。很多时候都是一脸黑。

  尽管程序员阅读别人代码技术都是一流,不管你是有没有注释,不管你是怎么循环嵌套,也不管你是怎么命名,他们都能耐心的,把代码分析个所以然来。但,对于程序员这个视时间宝贵如生命,分分钟都能创造几百万价值的群体来说,您行行好,给我们省点时间吧,把变量是干啥用的,说清楚呗,没准节省的这几分钟,多赚个几万,还能请大家出去嗨呢。

  每每看到部门的某大神,用一个神一般的变量名“flag”,我就有吐血的冲动,他还这个flag一直雪藏,不用,只是传递到第n个方法才使用,顿时心力交瘁,我的天,这个flag都是是干嘛用的啊,后来才明白,是isPay的意思,用来标识用户是否支付成功了。当时一口老血吐屏幕上,心里狂吐槽,老兄,你命名个isPay会死么,我的脑细胞这么不值钱么。到后来看到,去魔法数字,用int NUM_7 = 7,而不是MAX_MEMBERS来表示最大成员、用x y z来命名变量名,各种只有作者,或者作者后来都忘了的独特命名方式,都见怪不怪了。更有甚者,一个变量命名为passed,作用居然是“未通过”的意思,当时就石化了,作者还真是用心良苦,这都要考我细心不细心。

  一个好的变量名,能帮助阅读者了解变量的作用,也辅助了对整段代码的理解。

 

4、不要show英语,乡下的孩子伤不起唉

  LZ所在的团队,英语一直都是团队的硬伤,但总是能看到,某位仁兄,加上大把大把的英文注释,有些变量名也取些高大上的复杂的英语单词。敢问,你这么高的逼格,以后我们怎么和你玩啊。(那位仁兄其实就是LZ,年轻时唉,罪过罪过)

  代码是用来沟通的,传递作者意图的,都看不懂,怎么沟通交流。建议英语好的童鞋,英语能力可以放到阅读英文书籍中展示,在代码中,如果团队英语能力很弱,避免使用英文,变量命名也尽量按照团队英语水平来命名

 

5、添加必要的注释

  正如上面LZ说的,经常遭遇“你仔细看看代码,就知道干嘛用的”这样的神回复。尽管阅读代码是每个程序员的强项,但必要的注释,比如逻辑比较复杂的地方,添加必要的注释,对提升团队成员阅读熟悉代码的效率是有很大帮助的。试想,一个类,几百行,没有一行注释,对于阅读者来说,阅读它将是一个多么恐怖的事。

 

6、注释保持简洁,避免没有必要的注释

  即看过一行注释都没有的代码,也看过注释比代码还要多的程序。一个是让人生不如死,一个是让人痛不欲生。(唉,有时不仅感叹,在程序员界混,真的是难)。

LZ就经常看过,一大段注释,啰嗦了半天,要不就是没表达清楚重点,要不就是只为说明它是个循环的作用!!!譬如i++这样的代码,有必要加个“每个计数增加1”这样的注释么,这完全是把读者定位为非程序员啊,或者就是严重鄙视读者的编程水平。

  注释是帮助阅读的人更好的理解程序的逻辑,只是辅助,如果不重视通过命名等方式来传递代码的作用,而是依赖于注释,这就是本末倒置了。而且,冗长啰嗦的注释,这到底是帮助人理解,还是阻碍人理解啊,是读程序还是读小说啊。 

 

7、拥有自己的编码规范

  规范是为了让团队更快的理解、熟悉代码的,同理,拥有自己的一套规范,就能帮助其他人更快的理解我们所写的功能,减少学习和沟通成本。 

 

8、代码清晰简洁的表达出作者的意思

  在我们每次写完一段代码时,一定要问问自己,代码是否表达清楚了我的意思,是否需要添加些注释,名字取得是否恰当了,别人在阅读时是否吃力。。每每看到别人一团糟的费解的代码,就时刻提醒自己,一定要把代码写好咯,我也确实是这么做的,一遍又一编的检查,看变量名、方法名是否表明了它的用途,是否有些不必要的、只是为了提升逼格的代码,别人是否能在短时间内看懂。所有的这些,只是为了写出一段更优美的代码。

 

9、坚持并捍卫上面的准则

  经常能听到,有些公司是代码行数来定义绩效的,但作为一个有操守,并秉承基本自我修养的程序员,我们绝不能为了各种诱惑或者胁迫,甚至是自己的惰性、个性,而放弃写出简洁清晰,可读的代码。

  

  以上的几点,并不是严格的意见或者建议,只是提醒广大程序员同胞们,在痴心与高端的技术时,千万不要忘了,代码不仅机器要阅读,人也需要阅读。就算你写出再复杂的代码,但它让人完全无法阅读,这有什么用呢。这就如同,你很牛逼很牛逼,但别人听不懂你说的话,还不是没用。如果你真的写出了可读性强的代码,但你也不应该鸣鸣得意,我觉得,写出一段优美,健壮,可读性高的代码,是一个程序员最基本的自我修养。如果这个追求都没有,那和咸鱼有啥区别呢。虽然常被外人看来邋里邋遢,不善交流,但我们的的代码优美,每段代码都清晰简洁的表达了心中的想法,这不也很好么。代码作为程序员间交流沟通的媒介,一定要保持它的高效沟通的属性,切不要为了自己的个性,而牺牲它的可读性。在此,建议大家业余时间阅读些比如《clean code》、《how to be a better programmer》等相关书籍