程序员的自我修养

时间:2024-03-29 20:21:31编辑:奇事君

程序员的必要修养有哪些

一、注意细节,尤其是最小的细节
“差不多”、“很接近”是只能在做马蹄铁时用的词,在软件开发中,95%的正确仍然是不能用,一个“差不多”能用方法或一个使图片很“接近”居中的CSS样式都是不合格、不能用的。这剩下的5%对于整个软件的有效性十分重要,能造成完全相反的结果。
二、 学无止境
起初这句话听起来会很迷人,你会很喜欢!我喜欢学习新事物!尤其是当你来自于一个无聊的工作或像钉马掌这样永远不变的事情时。然而,经过了一段时间后,你会发现,这变成了一条永不停息的知识河流,如果你不喜欢水,你会感觉困在了无尽无边的知识瀑布前,无法停止,也无法穷尽。我每天大概有学到10-20种新的东西,我喜欢这些!我的弟弟却希望事情永远不会变化,始终如一,他对我说他永远都不愿意去学编程。
三、 面对压力、紧张和限定期限
没错,每个人都喜欢使用软件,但你喜欢面对任务的最后期限和最终目标吗?需要什么时候完成?做完这些要花多少时间?我们能在这段时间里完成更多的任务吗?是否还记得要注意细节?你怎么办?急匆匆的完成?加班加点希望能多完成一些?在理想世界里,编程是一个很有趣的活动,我们写出代码,让它们完成很酷的事情,吃着批萨,喝着可乐。而在现实生活中,有的是压力,虽然不是时刻都这样,但事情会比那种做一个30分钟的简单在线辅导要不同的多。我喜欢挑战我的极限,我渴望成长,变成一个更棒的程序员,所以我不介意。
你面对时间限制和工作压力会怎样?如果你想回避这些压力,那你将无法成为一名程序员。
四、有组织能力
我知道有些程序员的生活一塌糊涂,看起来他们似乎没自我组织能力,但我说的不是这些,我是说管理好工作流程的能力。比如,能否迅速容易的在你的计算机里找到一个东西?我认识的优秀的程序员通常能迅速的定位一个需要的文件,能够用工具或脚本帮他们处理繁杂的事物,这些都是高效的工作。
当你学到了一个新东西时,你是否把它写下来?你是否喜欢想出办法来替你完成那些重复的工作?你能很好的安排各种不同的任务吗?
五、好奇心
当我还是十几岁时,教堂里的一位夫人几乎每月都会对我说一次,她说我应该停止问那么多为什么,她说这让人讨厌。虽然受了批评,最终我还是清楚的认识到,优秀的程序员总是在问“为什么?”这个应用的工作原理是什么?那个横跨街道的建筑是怎么建起来的?程序员之间的对话听起来总是像这样开始的:“很奇怪他们为什么要这样做…?”以前我以为问这么多为什么是很奇怪的表现,但现在我明白,至少是在软件开发中,这是一个好的品质。
六、学习能力
我知道,很多的程序员都上过大学,出自高校的,但这不是我要说的。优秀的程序员总是在钻研程序代码和文档,来弄清楚东西的工作原理,他们不会敲开老板办公室的们说:“我需要找专业老师,学习这款新软件”。优秀的程序员在不断的学习,不断的靠自己研究出事情的原委——不论是有高学历还是没有学历。
七、人际交往能力
这在程序员中不是一个普遍的特征。真正优秀的程序员善于与人交往,但大多数程序员缺乏这些能力。如果你善于沟通,你的老板、你的公司会非常喜欢你。而且,不要因为他们不会编码就瞧不起他们。


一个程序员需要有怎样的自我修养?

作为一名程序员,一个“程序员的自我修养”是什么?
尽管我们不一定要像尹天仇那么的认真对待自己的事业,但,一些基本的修养,作为一名新时代的码农,总应该是要具备的吧。不过真要说修养,方面还是挺多的,技术自我提示自不必说。但我并不打算从这个大家都觉得理所当然的技术方面入手,而是谈谈,可读性代码,这个容易被大家忽视的基本素养。
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、坚持并捍卫上面的准则
经常能听到,有些公司是代码行数来定义绩效的,但作为一个有操守,并秉承基本自我修养的程序员,我们绝不能为了各种诱惑或者胁迫,甚至是自己的惰性、个性,而放弃写出简洁清晰,可读的代码。


以上的几点,并不是严格的意见或者建议,只是提醒广大程序员同胞们,在痴心与高端的技术时,千万不要忘了,代码不仅机器要阅读,人也需要阅读。就算你写出再复杂的代码,但它让人完全无法阅读,这有什么用呢。这就如同,你很牛逼很牛逼,但别人听不懂你说的话,还不是没用。如果你真的写出了可读性强的代码,但你也不应该鸣鸣得意,我觉得,写出一段优美,健壮,可读性高的代码,是一个程序员最基本的自我修养。


上一篇:gbk内码查询

下一篇:华文行楷