阅读 2776

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

前言

上一篇总结了前端对外沟通输出以及外在幸福感的炼成,这一篇主要是对内在幸福感的总结。博文首发于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,是在优化,我还是在继续提升。

关注下面的标签,发现更多相似文章
评论