【進階】前端幸福感是怎樣煉成的（下）

前言

上一篇總結了前端對外溝通輸出以及外在幸福感的煉成，這一篇主要是對內在幸福感的總結。博文首發於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，是在優化，我仍是在繼續提高。