怎么才能写出让人拍手叫好的代码？？？

··· 优秀程序猿的演变过程

怎么才写出高质量的代码呢 怎么提高业务代码的能力呢 这个问题也困扰了我很久 我也想成为让人赞叹的秃顶少年
同时也在思考这个问题 因为自己的代码也不荣乐观 鄙人呢 也想写出让人拍手称赞的代码 

所以这篇文章就来大概的分享一下 怎么把 “乐色代码” 成功的进价成 “神仙代码！

神仙代码~

细节之中自有天地，整洁成就卓越代码  ---  《代码整洁之道》副标题

什么是神仙代码呢 ？ 神仙代码无非就是让人看的舒服 看的明白 看的拍手说好的代码 这里就通过这几天的了解和分析可以总结以下几点！！ 后续会继续补充

• 自描述的代码（可读性的代码）

  我认真思考了一下感觉这个的优先级应该是最重要的，其实当你的代码能被其他人轻易的看懂的话，那么你就已经成功一半了，为什么这么说呢 因为优秀的代码大部分是可以自描述的，好过于文档和注释，当我们平时去看大神写的代码或者去git上面去看开源的项目时，有的地方基本没注释但是吧，结构清晰明了，看的特别舒服。所以感觉还是有必要自己写完的代码自己回头看看或者让其他人帮忙看看的。

• 命名

  命名的意义就是保证别人通过名称一眼就能知道这个变量保存的是什么，或者这个方法是用来做什么的。必要的时候可能你思考这个方法的命名 可能比写这个方法的是时间还有长。如果一个方法命名为 a b c 等等的 那么后面维护的人可能就要崩溃了，这里告诉大家一个小网站 CODELF 这个网站就是专门命名的，但是命名这方面吧，还是靠自己，实在想不出来了，可以去这个网站搜一下。

• 代码的灵活性 复用性

  当我们添加一个新的功能代码的时候，原有的代码已经预留好了扩展点，我们不需要修改原有的代码，只要在扩展点上添加新的代码即可。这个时候已经说明这段代码是比较灵活的了。 同样的 几个几乎相同的需求摆在你面前的话，你尽量要减少重复代码的编写，复用已有的代码。当一段代码足够的灵活且复用性强的话，也可以证明这段代码是足够优秀的。

• 统一风格

  统一风格这方面吧 也是比较重要的，但是这指的统一风格 大部分可能指的都是团队开发，如果是一个团队是在一起进行开发的话，风格又不统一的话，会出现很多的问题，举个栗子，代码格式的问题，很多人应该都有过这样的经历 拉个代码下来全都是报错，这里可能就是有人的格式化的方式和大家不统一，所以代码中所有的空格 换行 等等就会变掉。这个呢 就需要团队开发前，需要大家在一起把注释、命名、缩进空格、语句格式、规模、语言特殊项，等等的规范商讨并且统一。个人感觉团队还是有必要制定统一的团队编码规范并严格遵守。

• 思先于行

  在实际的软件开发周期中，设计的时间通常不会比编码的时间短。我们先不要急于动手写代码，而是一开始仔细的分析和设计。与其写出一段漏洞百出的代码，倒不如仔细分析再写出鲁棒的代码。感觉大部分劣质的代码大部分都是因为太着急了没有自己的思考而导致的，反正质量和速度往往很少能二者兼得。所以等需求完全下来后，静下心来，慢慢思考，那么优质的代码不就出来了吗。

• 代码的鲁棒性

  鲁棒性这个词其实也是刚刚才了解到的，看到这个词没懂什么意思，后面去了解一下，鲁棒是英文 Robust 的英译，有时也翻译成健壮性。所谓的鲁棒性是指程序能够判断输入是否合乎规范要求，对不和要求的输入予以合理的处理。容错性是鲁棒性的一个重要体现。不鲁棒的代码在发生异常事件的时候，比如用户输入错误的用户名、视图打开的文件不存在或者网络不能连接，就会出现不可预见的行为，或者干脆整个代码崩溃。这样的代码对于用户而言，不就是一个定时炸弹吗!

• 错误处理

  因为前面讲到了鲁棒性,所以这边就提一下代码中为数不多出现的错误处理,目前我们对于代码中的错误处理还是比较少的，那一般的错误处理有哪些呢？对于我们前端来说，我们可做的异常捕获还真不少。总结一下，大概如下：JS 语法错误、代码异常、 axios请求异常、静态资源加载异常、Promise异常、Iframe异常、跨域Script error、崩溃和卡顿,这些都是比较致命的错误,其中有的错误如果一旦出现的话,可能就会导致项目崩溃,但是这一块还是我们往往这块不被注意到的地方,也是比较重要的

• 阅读学习交流分享

  总结绝大多数开发者的日常，对新功能开发的迫切远远大于重构一个旧的功能，导致很多代码都没有很好的版本迭代。慢慢的，破旧、破损的模块让人觉得似乎无人照管，于是别人也不再关心，最终自己也参与破坏活动，走上一条打补丁的不归路。其实从一开始，我们就应该抱着一种重视自己的代码的态度来写代码，而不是想着先完成功能，以后再来重构优化。

• 自我约束（军规）

  我这里指的自我约束是自己给自己制定一些针对于写代码时的一些军规。这个方法也是前不久才学到的，之前也没想到。自己制定了这些军规后需要自己对自己强制性执行，比如一个函数不能超过100行, 一个函数内不能有很多的if等等都是需要自己去针对于自己的欠缺之处来制定对应的军规来约束自己。

乐色代码~ 痛点

影响团队合作，降低效率。对于共同完成项目的团队而言，如果没有统一的代码规范，最终整合代码时可能会出现看不懂命名或者阅读过程不断询问的情况，导致团队效率低下，甚至造成成员之间的矛盾。例如 git push -f，把别人的劳动成果全部覆盖掉，出现一次大家就直接可以给他准备后事了，猪队友啊......

提高维护成本。代码不规范导致可读性降低，后期的代码维护会耗费更多人力.一旦代码越来越多，最后的维护就难以为继，会给很多人带来很大的困扰。

引发各种 bug。如果输入输出参数、异常处理等没有规范，很容易导致大量低级 bug，还很难找到 bug 的原因。

不利于代码审查，甚至造成安全漏洞。代码审查是纠正代码错误，保证开发周期安全顺利进行的重要一步。如果代码不规范，就会加重代码审查的工作量和难度，导致代码审查工作没有根据还浪费时间。某些情况下，代码不规范还会造成安全漏洞，此前 Morpheus 智能合约爆出的重大安全漏洞，就是大小写错误造成的。要是有一天你们的项目因为你的一个大小写出错了，那就直接提桶跑路吧

不利于程序猿自身的成长。有些人可能没有意识到代码规范的重要性，有些人意识到了但由于项目时间紧、流程繁琐等原因而不去遵循。这跟当前开发流程与安全之间的关系很像。很多人为了速度而牺牲前期的必要流程，却给后续的工作带来了更多麻烦。其实，规范的代码有利于提升开发水平。

总结

X，哪个蠢货写的代码！一看注释，提交.....如果你发现你之前的代码很low，说明你已经进步了。

当然了俗话说的好 只要代码写的好，女朋友不难找，没有对象的程序猿可能要反思一下自己的代码写的够不够好了

你忍心蜗居在不到10平米的小屋里吗? 	
你忍心看着自己的女友和你奋斗一辈子还供不起一套房吗? 
你忍心看着你父母缩衣节食把仅有的一点养老金帮你还房贷吗?
这里才是实现你梦想的地方!!!
梦想大舞台 有梦你就来!!!
浙江大华技术股份有限公司-软研-智慧城市产品研发部招聘高级前端！！！！！
欢迎大家来聊，有意向可发送简历到 chen_zhen@dahuatech.com