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

YSOM_穀雨發表於2019-11-19
前端

前言

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

相關文章