【进阶】前端幸福感是怎样炼成的（下）

前言

上一篇总结了前端对外沟通输出以及外在幸福感的炼成，这一篇主要是对内在幸福感的总结。博文首发于ysom.github.io

【进阶】前端幸福感是怎样炼成的（上）

内在的幸福感影响因素有不少，总结最主要有如下几类：

• 重复业务多，键盘只用ctrl+cv，空有搬砖感，毫无成就感
• 搬砖搬得多，稍微来加点挑战性的，逻辑绕不过，就说顶不住
• 面对技术的高速迭代，无从下手，茫然失措，最后迷失方向脱离前端坑路

总结出问题，那就能够很容易找到解决方法了

减小重复工做，提升编码质量

你们在工做中确定会常常遇到重复的、或者功能相似的业务，通常的操做估计就是一顿cv，疯狂复制粘贴，完事。可是这种就是单纯的体力活，长此以往，就会以为枯燥乏味，没新鲜感、成就感，慢慢就会对工做失去热情。

这种状况，简而言之，在多处地方出现的代码，能被copy来使用的，就要想一下是否能够抽离逻辑，封装复用。而封装通常分为两种状况，配置和组件

配置

CSS

咱们开发某一个端的应用时，常常会有相应的主题色，页面结构会有经常使用的布局样式，按钮等等也会有经常使用主题样式，对于这些经常使用的样式，咱们能够经过写成统一的css变量和class，放在一个tools文件来实现样式复用，这里采用less预处理器

// tools.less

// 主题类
@happy-theme: orange;
@sad-theme: gray;
@danger-theme: red;

// 布局类
.flex-align {
    display: flex;
    align-items: center;
}
.flex-between {
    display: flex;
    justify-content: between;
    align-items: center;
}
.flex-center {
    display: flex;
    justify-content: center;
    align-items: center;
}
复制代码

// test.vue

<template>
    <!-- 将div设置成flex居中布局 -->
    <div class="test-div flex-center"></div>
</template>	
<style lang="less">
    @import 'tools.less';
    // 将div背景颜色设置成happy主题
    .test-div {
        background: @happy-theme;
    }
</style>
复制代码

能够看到，引入了该工具文件实现样式复用，后续若是需求有变动，须要更换样式主题的时候，也只需在一个地方更改便可

JS

一般咱们调用后端接口的时候，后端会根据不一样状况来返回不一样的响应res code，好比0001表示请求成功，正常返回数据，0002表示请求成功，无数据，1000表示请求失败等，显然这里也能够作成配置

const CODELIST = [
    '0001': 'suc',
    '0002': 'no data',
    '1000': 'error'
]

axios.get('/getData', {params: {}}).then(res => {
    if (CODELIST[res.code] === 'suc') {
        ...
    } else if (CODELIST[res.code] === 'no data') {
        ...
    } else {
        ...
    }
})
复制代码

将返回码映射成文件，与不一样项目不一样团队对接的时候，也只是修改映射表就搞定了~

组件

说到组件你们应该也都不陌生了，组件化思想如今更是绽开光彩，那么重合的功能业务，咱们就能够封装成组件，供不一样的页面使用

好比后台管理端页面，常见的结构就是表单查询+工具栏菜单+表格列表+分页，若是有10个页面（真实状况每每不止），咱们是否是要建立10遍重合度90%以上的代码？这个时候要考虑能不能抽离逻辑，作成一个组件，而后往这个组件传参数，来让它实现不一样的功能。esay-page组件源码

// parent.vue
<template>
	<easy-page ref="easyPage" :fomrData="form" :columns="columns"
	    :layout=['form', 'toolbar', 'table', 'pagination'] :getApi="getApi">
	    <template slot="form">
	        <!-- 自定义表单代码 -->
	    </template>
	    <template slot="toolbar">
	        <!-- 自定义工具栏代码 -->
	    </template>
	</easy-page>
</template>

<script>
	export default {
	    const columns = [
	        {label: '序号', prop: 'index'},
	        {label: '编号', prop: 'id'}
	    ]
	    data () {
	        return {
	            form: {},
	            columns,
	            getApi: '/getData'
	        }
	    }
	}
</script>
复制代码

经过这样一个组件，就能够实现简单的表单查询+工具栏+表格+分页，经过参数也能够控制页面结构。

还有相似上传功能，element-ui等UI库已经帮咱们实现了不少，可是业务每每没有那么简单，咱们须要基于已经实现的功能去进行二次封装

// easy-upload.vue
<template>
    <el-upload></el-upload>
</template>

<script>
    export default {
        props: {
            // ... 接收二次封装须要的参数
        },
        data () {
            return {}
        }
    }
</script>
复制代码

// parent.vue
<template>
    <easy-upload :setting="setting"></easy-upload>
</template>

<script>
    import EasyUpload from 'easy-upload.vue'
    export default {
        data () {
            return {
                setting: {
                    // ... 自定义参数
                }
            }
        }
    }
</script>
复制代码

一次封装，就能在多处进行灵活性更强的使用，而在二次封装的过程当中一些逻辑处理，可比搬砖有趣多了

学习数据结构，拓展思惟

不少前端同事都会在google、百度、知乎等提问，“前端是否应该学习数据结构”，“前端学算法有用吗”等等问题，我以为问这种问题，是还没从根本上理解代码存在的意义，每个开发工程师都是经过代码跟机器打交道的，而数据结构就是数据、代码的一种结构化，是数据组织方法，不学数据结构，不学算法，怎么跟机器进行更深层次的交流？跟机器交流比如跟人沟通，好的语言组织能让咱们事半功半，适合的数据结构也能让性能更加优越。

说到底，咱们的业务都是基于各类不一样的数据结构来完成的，只不过有一些平时写的逻辑较简单，会忽略了其实也是用到数据结构来实现的，不学数据结构，不学算法，不会知道能够用双端队列来作回文字符串检查，不会知道能够用循环链表来实现小时候爱玩的“击鼓传花”游戏，不会知道撤销、回滚是怎么实现。

回到总结，数据结构不是学不学的问题，是要往多深学，起码最基本的栈、队列、链表、树、图等都要了解，至于深度，就取决你对本身的要求以及工做中的需求。

阅读源码，提升逻辑

提升幸福感的另外一件事，就是阅读源码了。可能有人会问，啥，阅读源码幸福？不是很痛苦？是的，源码一开始看确实很痛苦，尤为是优秀的项目通常架构比较复杂，想看也不知从何下手，可是咱们能够见招拆招，从部分模块看起，好比vue中，能够看双向绑定，能够看响应式设计等等，从某个模块看起，能有效下降源码阅读难度。

并且一个优秀的框架、库是通过了时间和用户的考验，阅读源码也是咱们近距离接触大神的途径，咱们能够从源码中看出大神他们的设计思想，思考方法，开发逻辑等等，咱们本身创造不了牛逼框架，还学习不了？

关注行情，了解趋势

当今这个时代，努力奔跑只能保持原地不动，而停滞不前就会逐步落后

前端的发展你们有目共睹，可谓是突飞猛进，这个时候的咱们，只能多多关注技术发展，来扩充本身的眼界，否则别人问起什么是大前端，何时是前端微服务，咱们都是一脸懵逼，眼界将会决定咱们在这条路上能走多远，走多久，若是没有幸福感，没有兴趣支撑咱们前进，心越空，越容易被焦虑感填满，咱们很容易就会被洪流冲走，心中有方向，前进才不会迷失。

定时review，作一个“铲屎官”

最后要讲的一点，无论开发的时候对本身写的代码有多熟悉，都要写上注释，这是为后面本身或者同事review的时候作好前置工做。还有就是要定时对本身的代码作review，或者让朋友、同事帮咱们review，由于无论啥时候，咱们回过头来看本身的代码，都有一种在看shi的感受，对吧？而review的过程，就是一个铲shi的过程，手握review铲，哪里有shi铲哪里，老板不再用担忧我巨坑了！一边review一边骂本身当时为啥那么sb，写出这么shi的代码，一边优化提升本身的能力，因此，review能够帮咱们更好地认识本身，也能更好地提升本身~

结语

本篇从几个方面作了提高内在幸福感的总结，也是这一年多来的心得体会，可能总结不是很到位，会有不少遗漏，但就像上面说的，当我之后回过头来看这篇文章的时候，我是在review，是在优化，我仍是在继续提高。