为什么要写这个文章呢？是因为我觉得代码精简是有套路的，为了让自己以后少次犯共性问题，在此进行一个总结，归纳出一些日后我写代码的规范，也希望能让有心精进的同行们共勉。
本文主要分为两部分，一部分是最基本的代码封装性，这个属于我的组内规范，另一部分是优雅性，这部分主要是我自己的一些体悟，话不多说开始正题
封装性
封装的重要性不言而喻，经过提炼封装的代码一定更简洁，因此也会提高代码的易读性。封装性又体现在多个方面，在此列举下：
-
less函数的封装
-
api的封装
-
逻辑的封装
less封装
这里我们不需要对less函数进行额外扩展，只不过常用的css样式，要用封装好的less函数来替换，比如flex、ellipse、margin。
api封装
网络请求在项目需求里也是比较常见的，建议每次写需求前，盘一下设计的请求，如果已经被抽出来了，直接复用，否则在对应的地址去封装下请求方法。不要直接把请求地址写在逻辑层面。
逻辑封装
只要一段逻辑使用超过了两次，那么一定要对这段逻辑进行方法抽离。这样可以增加代码的复用，降低整体代码量，提高易读性、可维护性。
优雅
一个好的程序员是有自己的代码品味的，如果说做好封装是基础，那么怎么优雅的去写代码就是进阶。
我觉得我的代码品味也是有进步空间的哈，而且我说的有些我也做不到，但以下是我现阶段对优雅的一个理解，同行们可以尽请指正。
-
用准api，能让你的代码更优雅
-
不要提交无意义的代码
-
对于注释，要像写代码一样认真
-
从架构师的角度去写代码，在你的代码里尽量少的去声明变量和形参
用准api，能让你的代码更优雅
现有的api在这里指js的新版本api、以及项目中所用到的第三方库或者util里的工具函数。 只要你用对了api，那你一定会少写一段逻辑，因此代码会更清晰。
比如我想对数组进行转后，转化后的数组，只取原数组的某一的字段。
这种情况map明显比forEach更符合语义化，如果用forEach就需要自己去写一段处理逻辑，所以用一些现有的api，会比自己封装逻辑更易读。
再举个极端点的例子
比如我想去除数组里的假值（因为有一些是脏数据undefined，我能保证其他的都是有效字符，不会出现false、0这类的有效信息）。
这里有两种做法
- filter数组过滤
- lodash的compact
虽然filter也是es6的api，也满足语义化的要求，不过我觉得compact更好。
原因在于：filter也需要自己去写一条过滤逻辑,而compact，我们只需将要过滤的东西传入即可，对比如下。
// filter需要额外写出过滤逻辑
const allMeaningfulValue = arr.filter(item=>item)
// compact 则更像专门处理这种情况的api
const allMeaningfulValue =_.compact(arr)
不要提交无意义的代码
什么是无意义的代码呢？我认为应该是：多余的注释（后面会解释什么是好的注释）、catch块以外的console（甚至是所有的console都不应该存在于你提交的代码）、没有用到的函数、变量、模块引用。
为什么我觉得提交的代码里不应该有他们呢？原因在于他们对于程序本身不会提供任何帮助，反而会为后来的维护者带来不必要的阅读负担。为了提高易读性，我觉得有必要在提交代码前为代码减个肥！
对于注释，要像写代码一样认真
业界内写好注释应该是很多程序员的共识啊，但是呢，我觉得应该不是每个有此共识的程序员都愿意像对待代码一样去对待注释吧😂。
在我看来注释是为了帮助后续维护者去理解代码逻辑，或者命名不清晰的变量， 或者是一些有意思的吐槽【狗头保命】。既然是为了引导后续维护者去理解代码，那么在关键的逻辑处简明扼要的进行解释，在我眼里就是写注释的最高境界了。
我本身开发时间并不久，所以业务逻辑有的时候写的蛮冗杂的，为了让后续读者理解我的意思，我只能尽可能的去解释逻辑，因此会写一些长串注释，长串注释并不优雅，因为他会增加阅读者的负担。但是我觉得在大神眼里注释是配合代码帮助后人去理解他们逻辑的工具。因此我认为代码和注释如同君臣，缺一不可，同样重要。
我这里并没有写好注释的方法，因为我的注释确实不优雅，只能在这里强调下注释的重要性，以及我眼里注释的作用。
像架构师一样去写代码
这一听标题，就知道，我肯定没做到。但不妨碍我表达出什么是我眼中架构师写的代码，以及他为什么优雅。
我眼中的架构师就是开发的顶端，他们已经懂了开发中的所有奇淫巧技，更是从中悟到了自己的代码之道。换个说法，架构师之于我犹如庖丁之于解牛厨。他们的代码呢，必然是精简到了极点，一字千金，你很难从他们的代码里发现任何一处赘余。
那大师的代码呢，他好在哪里呢？我觉得他 “简” 就简在了两处，一处是我之前所有阐述的集合：代码层面精简。另一处便是 “逻辑精简”。
我觉得要做到逻辑精简到极致，应该需要一份匠心吧，本来是想觉得需要天赋，但可能后来一想，那些在某个领域很出众的大国工匠，从他们身上我能更多的体会到的是一种谦卑，而不是极具天赋者的孤傲。其实说到这我已经是妄评了，大家见笑。
之所以领悟到逻辑精简呢，也是我leader为我做过的一次codeReview，我发现按他所说换一种写法的话，我能少写一个公共逻辑的入口形参。在我努力去清洁代码的时候，能去掉一处逻辑冗余，当时是让我大受震撼。我认为我的leader是站在了很高的高度去为我指了一次错误，因此为了写出更好的代码，为了避免逻辑冗余，我们应该从更高的层级上去重新审视自己的代码，没准真能为自己做一次逻辑精简呢。
我总结的就这么多，以后我会以本文我的阐述作为我自己开发的纲领，当然，同行们应该清楚，不是每次开发都会给你足够的时间去写好代码，我们写代码肯定是以完成任务为主，不过如果工期足够，我会尽可能的去精进我的代码。
日拱一卒，功不唐捐，望同行们共勉。
