发布网友 发布时间:2022-04-22 07:32
共5个回答
热心网友 时间:2022-06-17 18:54
作为一名程序员,一个“程序员的自我修养”是什么?
尽管我们不一定要像尹天仇那么的认真对待自己的事业,但,一些基本的修养,作为一名新时代的码农,总应该是要具备的吧。不过真要说修养,方面还是挺多的,技术自我提示自不必说。但我并不打算从这个大家都觉得理所当然的技术方面入手,而是谈谈,可读性代码,这个容易被大家忽视的基本素养。
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、坚持并捍卫上面的准则
经常能听到,有些公司是代码行数来定义绩效的,但作为一个有操守,并秉承基本自我修养的程序员,我们绝不能为了各种*或者胁迫,甚至是自己的惰性、个性,而放弃写出简洁清晰,可读的代码。
以上的几点,并不是严格的意见或者建议,只是提醒广大程序员同胞们,在痴心与高端的技术时,千万不要忘了,代码不仅机器要阅读,人也需要阅读。就算你写出再复杂的代码,但它让人完全无法阅读,这有什么用呢。这就如同,你很牛*很牛*,但别人听不懂你说的话,还不是没用。如果你真的写出了可读性强的代码,但你也不应该鸣鸣得意,我觉得,写出一段优美,健壮,可读性高的代码,是一个程序员最基本的自我修养。
热心网友 时间:2022-06-17 18:55
链接:http://pan.baidu.com/s/1p1G4NCUtPNVvkkXE7qxFbQ
程序员进阶攻略。如何才能持续成长,是每一个程序员都绕不开的话题。入行之初,你可能会困惑于技能选择的方向和掌握的方法;编程前期,你可能会苦恼于Bug的调试与修复;技术水平达到瓶颈期,你可能又急于寻求突破和上升。除此之外,职业倦怠了,如何去面对?技术停滞了,如何去解决?人到中年,是选择工作还是选择生活?换工作?换城市?换方向?如是种种,磨蚀着曾经的乐观和现在的不甘,是放任自流还是逆流而上?
课程目录:
开篇词 (1讲)
开篇词 | 程序行知:走在同样的路上,遇见自己的风景
征途:启程之初 (4讲)
01 | 初心:为什么成为一名程序员?
02 | 初惑:技术方向的选择
03 | 初程:带上一份技能地图
04 | 初感:别了校园,入了江湖
*:程序之术 (10讲)
05 | 架构与实现:它们的连接与分界?
......
热心网友 时间:2022-06-17 18:55
对技术负责和关注。程序员需要对自身职业相关的技术有足够的了解,注意主流技术用法和技巧,留意新技术的新特性。技术都是随着版本提升越来越好用的,不能只守着毕业的那一套知识体系。
对业务和数据了解。技术再好,也只是单纯的程序算法问题。对公司的业务模式足够的理解,才能清楚程序是该干什么,什么数据有什么作用,什么样做法存在什么样的问题。
对公司的软件产品和各岗位职责有一定的了解。一套软件服务,一般涉及到开发测试售前售后,出了问题,要知道问题出现在哪,也许客户反映的问题根本不是开发上存在的问题
热心网友 时间:2022-06-17 18:56
要轻松写意地处理“变幻莫测”的日常工作,要及时实现“不进则退”的职业进阶,都需要坚持自我修养,自我修养的内容非常广泛,我们的学习能力,研究能力,逻辑能力,抽象能力,都需要不断打磨,而且要定期将自己的知识体系全面梳理一遍,既能查遗补缺,又能开解疑难,豁然开朗。
热心网友 时间:2022-06-17 18:56
作为一个在方维码了10年代码的程序猿说下我自己的看法:一个开发人员随着年龄和经验的增长,所参与的项目,再也不是靠一个人或者几个人就能完成的。系统的重构、代码的重构、工作的交接、对新进人员的培训等等类似的事情,会越来越多的遇到,这些事情无一例外都会把已经写过的代码重新或者重复阅读,如果在初始编写代码时,就做到完整、清晰明了的代码注释,对后续工作会有巨大的帮助。不仅提高工作效率,还能增强合作好感。事实上,就算只是自己看自己的代码,如果有注释,也能加深印象,缩短代码查找时间。因此,任何开发人员,都应该养成良好的代码注释习惯。优秀的代码注释应该能做到:每一个函数、每一个属性甚至是变量的划分,都可以找到对应的解释。
多使用越来越被IDE支持的XML注释方式,不仅有注释文字,更有详细的参数描述。
对程序结构、模块、组成部分划分等也加以注释。