为什么书写优美的代码?

2019/11/04 web

敬畏每一行代码,敬畏每一份托付

自己慢慢像标题这个方向靠拢,代码并不是跑起来就没有问题了。后期维护,同事 review ,同事接手等等都是需要我们考虑。因为自己代码中问题太多,才意识到自己代码有多大的问题。我们的每一次经历都塑造着我们,经历多了自然就懂了。或许这就是工作若干年和初入职场的萌新的区别

代码曝光

如果不是代码在同事面前一次又一次的曝光,他们一次又一次的指出问题,我还一直自认为自己代码写的很不错,自己发现不了自己的问题。被曝光的问题,布局样式写的不合理,数组操作下标,标签乱嵌套,同事看着很不舒服,虽然这些最终都没有影响程序的运行,但是这和我的初衷相违背。不是我想要的简单的代码,同事一眼就能看懂。场景对换,有时候我也会接手同事的代码,看到代码一脸懵比,表情无比痛苦,一脸沉重,心里在默默的哔哔哔。最近我也在看一些同事写的代码,有些的好的我会借鉴,也有写的不怎么样的,看着我难受。每一次合并 master 领导都会对代码进行 review ,有问题会指出最好是重写。当然不想代码被打回,所以好好写,写出优美的代码

己所不欲勿施于人,我们的每一次经历都塑造着我们,质变积累量变,总有一天我会写出优美的代码

为什么要书写优美的代码

关于如何书写优美的代码,网上搜一搜,很多写的很不错的文章,并且附带代码。开箱即用,我想说一点不一样的东西。自己是很难发现自己的问题,在别人身上找问题,在反思自己或许是一个很好的方式,从别人的不足和自己的不足中学习,积累,提高是一个程序员成长的必修课。

优秀的代码源于我们对细节的热爱和执着,一个小问题的小小的改进办法,都有可能会给你的代码质量带来巨大的提升和改变。

每一行代码,都体现着程序员的修为,思考问题的深度,甚至是处理问题的习惯和态度,代码是我们交流和处世的名片。作为一个技术类的工种,我们没有理由不去思考如何写出优秀让人惊叹的代码,写好我们自己的名片。

优秀的代码是投入少,收益大,投资回报高。最适合当前环境的代码,才是最优秀的代码。我们的产出必须大幅度大于公司对我们的投入,否则就有随时被扫地出门的风险,必须在单位时间内创造更多的价值,否则真的是没有功劳,只有徒劳。

不要当我写这行代码的时候只有我和上帝知道这行代码的意思,一年后,只有上帝知道。这就很难受了

程序猿的存在不是为了写代码,而是为了解决现实问题,实现现实价值,思维能力和行为能力很重要。

化繁为简,通俗易懂的代码,才是我们追求的好代码,编写代码的过程其实是简单到复杂再到简单。复杂是代码质量的敌人。 越复杂的代码,越容易出现问题,并且由于复杂性,我们很难发现这些隐藏的问题。在写代码的时候一定要把逻辑理清楚,否则到后面越改越乱。

写一篇文章要层次清楚,段落分明,写代码也是这样,杂志排版,要布局合理阅读舒畅,代码的编排也要这样

开发需求时间紧,哪有时间整理代码,确实是这样的,干净整洁的代码带给我们的远远不止格式上的赏心悦目,他更能提高我们编程速度与效率,因为代码的层次结构,格式部署,是我们对自己思维的整理,也是我们思考逻辑的展现。整理代码其实就是给代码分块,又臭又长的代码会误导我们,不好理解,不好阅读。

整理代码的时候,目标要单一,一个代码块只能有一个目标,我曾在项目代码里面犯过这个问题,领导指出之后进行重新整合了。代码块数量要适当,基础代码块最好不要超过25行,太长太复杂不好阅读。代码块是一个完整的信息块。一个代码块要表达一个相对完整的 意思,不能一个意思没说完就分块了,就像话说了半句一样;

注释就是对代码的解释。注释不需要运行,它是用来提高代码的可读性和可维护性的。不好的注释会使代码变得更糟糕,使人更抓狂。我们有时候会过度依赖解释,从而放弃了潜在的替代方案,比如更准确的命名,更清晰的结 构,更顺畅的逻辑等等。 注释,被我们用成万能的狗皮膏药,有时会让代码更糟糕。

如果api已经被废弃,随着时间的推移她的实现可能会存在各种各样的问题,包括严重的安全问题,需要承担这些风险也很多,我们应该尽早的废弃该接口

很多api的设计有检查参数有效性的方法,如果没有参数通过检验,就会报错,影响代码的正常执行,所以建议给默认参数,es6的语法是支持的

对于软件开发者来说,组织代码是一项基本技能,也是我们需要养成的好习惯。组织代码有许多不同的习惯和策略,我们要学会辨别这些策略中哪些是有效的,哪些是有害的

和其他技能一样,最快的提升方法是仔细思考一下为什么我们要做出这样的选择,而不是其他的。知其然远远不够,还要知其所以然。

提高协作效率的最高技巧不是提高沟通技巧,而是要减少沟通的数量,提高沟通的质量,尤其是要减少数量。如果你参加了工作,没完没了的会议,没完没了的文案,都会加深你对这条原则的理解。软件的设计也是这样,外部接口,要少、要小、要描述清楚。

代码的性能并不是可以多块 地进行加减乘除,而是如何管理内存、磁盘、网络、内核等计算机资源, 越早考虑性能问题,我们需要支付的成本就越小,带来的价值就越大

有过面试经验的小伙伴,你们有没有注意到,正确和有效地编码是面试官考察的两个重点? 招聘广告可不会提到,程序员要能够编写正确的代码和有效的代码。但是一些大的企业,会考察算法,其中一条重要的评判标准就是算法够不够快。他们可能声称算法考察的是一个人的基本功,是他的聪明程度。但是如果算法设计不够快,主考官就会认为我们基本功不够扎 实、不够聪明。 你看,算法快慢大多只是见识问题,但很多时候,会被迫和智商联系起 来。这样做既无理,也无聊,但是我们也没有办法逃避开来,主考官可能也没有更好的办法 筛选出更好的人才。

我们要养成一个习惯,看到声明的变量,就要琢磨这个变量能不能声明成不可变的量。这样就可以避免很多不必要的线程同步,让代码的效率更高,接口更容易使用。在阻塞的这段时间里,做的事情越少,阻塞时间一般就会越短

不知道你有没有这样的情况,学习技术时,我们对基本概念熟视无睹,只想将宝剑尽快握在手,哪管宝剑何时该挥出的教导。学会技术后,基本概念就会回来找我们算旧账,出错一次剑,就记一笔账。账本慢慢变厚的过程,也是我们向基本概念靠拢的过程。当我们掌握了最基本的概念后,开始慢慢还账,账本再越变越薄。我现在就是在还账阶段

第一个习惯是,要尽早地考虑性能问题。如果你最早接触的是需求制定,就从需求开始考虑;如果你最早接触的是软件架构,就从架构层面开始考虑;如果你最早接触的是软件设计,就从软件设计开始考虑;如果你最早接触到的是代码,代码也有很多性能问题可以考 虑。总之,要主动、尽早地考虑效率问题

第二个习惯是,性能的实践经验需要日积月累。性能的实践经验和技术丰富繁杂,大到产品蓝图,小到每一行代码,中间还有软件的架构、选型、部署等诸多环节,都有很多的最佳实践可以积累。而且这些最佳实践,也会随着时间的推移发生变化,比如说会出现更好的技术方案,曾经的技术满足不了新需求等。所以,我们也要随时更新我们的储备,摒弃过时的经验

送给自己的一句话:

有一种优秀是在看到自己的脆弱、在明知未来的结果后仍能勇敢的往前走。在面对人生逆境之时,接纳现状并且展现了最好的自己。一个人最终会持续的去做一件事,绝大原因是来自内心深处的感同身受,而这种感同身受便是使命。


一名伪程序猿——sunseekers,曾被bug虐的体无完肤,却依旧待他如初恋。

如果我改过的某一个bug,吐槽过的某一个需求,写过的某一行代码

曾在你的心里荡起涟漪,那至少说明在逝去的岁月里,我们在某一刻,共同经历着一样的情愫。

有时候,虽然素未谋面。却已相识很久,很微妙也很知足。


如果你喜欢我写过的某一个文字,请支持我,鼓励我,你的鼓励是我最大的动力来源

当然恰好你也喜欢我的话,我们可以互相关注,相互学习的哟!

sunseekers

Search

    Table of Contents