[[196161]]

上周沒有更新原創(chuàng)技術(shù)文章，原因是忙著重構(gòu)一個新接手的項目，此項目因為項目技術(shù)負(fù)責(zé)人離職，雖然投入人力持續(xù)增多，前端達到4人，后端3人，但因為新參與的童鞋對代碼結(jié)構(gòu)和業(yè)務(wù)的理解，導(dǎo)致項目開發(fā)了一個多月，還有一堆問題，達不到上線要求。接手項目之后，一開始對項目業(yè)務(wù)場景和代碼進行簡單的了梳理，跟了一天項目，觀察提測后FE+RD的狀態(tài)，自己也動手改了一天代碼，不管是FE+RD包括自己都覺得實在是太難受了，小坑大坑不斷，于是決定重構(gòu)。重構(gòu)不是個人沖動，而是的的確確存在各種大大小小的問題：

1.接口太碎：項目本身按照Vue組件化開發(fā)，但是頁面每個組件獨自采用vuex+ajax請求管理自己的數(shù)據(jù)，比如：首頁由輪播圖、各種列表和用戶信息展現(xiàn)組成，導(dǎo)致首頁從上到下7~8個模塊，每個模塊都各自發(fā)自己的請求，訪問首頁需要同時發(fā)出8個ajax請求

2.因為「1」提到的，單個組件數(shù)據(jù)都是使用Vuex進行管理，導(dǎo)致Vuex的store太亂：而且FE按照組件去開發(fā)，各自跟后端RD兌接口、聯(lián)調(diào)，但是沒有人來統(tǒng)籌安排，導(dǎo)致大量重復(fù)工作;除此之外，action和mutation中的業(yè)務(wù)邏輯代碼太多，而不同頁面需要不同的數(shù)據(jù)格式，則導(dǎo)致：

a.或者在mutation當(dāng)中對數(shù)據(jù)進行重新整理

b.或者新開個接口，這樣就造成接口越來越多，mutation部分代碼越來越重。

3.一開始設(shè)計或者溝通有誤。比如：用戶信息相關(guān)的接口，需要傳入用戶id(uid)，而不是通過登錄cookie從passport獲取;第三方接口需要用戶信息，竟然請求的時候?qū)ookie發(fā)給對方(幸好cookie是http only的，沒有調(diào)通被我及時發(fā)現(xiàn))

4.重復(fù)代碼太多，抽象能力太差。一份代碼在多個地方復(fù)制，導(dǎo)致代碼改來改去最后都不知道哪里改了哪里沒改

5.命名太亂，包括url、方法名之類，還有錯別字，getAdcontent(用戶地址信息)，getmaildetail(用戶地址信息)

6.研發(fā)人員缺乏全局意識，只管自己的代碼，而不關(guān)心整個流程。由于前后投入人較多，沒人對整個項目有把控，只能面向自己的需求編程。比如：積分獲取頁面，獲取成功之后，聯(lián)調(diào)成功，但是實際在積分獲取列表頁面卻沒有相關(guān)的記錄信息;在比如：任何用戶都可以領(lǐng)走別人的獎品，原因后端沒做獎品是否是當(dāng)前登錄用戶獲取的校驗

7.問題定位能力不夠，遇見問題一調(diào)就是半天，找不到根本問題

介紹下項目背景：

此項目是一個用戶積分任務(wù)和消費項目，一些頁面需要用戶登錄，頁面主要包括：首頁、任務(wù)+列表、商品+列表、個人信息和記錄以及其他類(說明和規(guī)則等)

項目用Vue+yog2編寫，ajax請求部分使用vue resource

架構(gòu)改造

整個項目還是用Vue+yog2來寫，針對進入頁面分為兩種情況：

1. 第一次通過網(wǎng)站URL進入某個頁面，我稱為：「首次后端渲染」
2. 非首次已經(jīng)進入頁面URL后，用戶點擊鏈接在項目內(nèi)跳頁，我稱之為：「非首次跳轉(zhuǎn)」

整個流程整理如下：兩個流程從「兩個小人」開始看起

后端node Server代碼部分

代碼流程如下：

router → middleware → page/api action → model → ral請求數(shù)據(jù) 

其中在action部分，專門寫了個 baseAction函數(shù)，封裝了重復(fù)的代碼，使用時傳入用于獲取數(shù)據(jù)的model方法和處理數(shù)據(jù)的方法即可。

render部分，針對頁面第一次請求需要將頁面數(shù)據(jù)放在HTML片段中chunk輸出，而不是通過ajax請求(為什么不用vue ssr，可以看下歷史公眾號文章《Vue SSR 從入門到Case Study》，之后單頁內(nèi)跳轉(zhuǎn)是ajax請求)。詳細(xì)代碼如下：

client.tpl 部分代碼：

baseAction 部分實現(xiàn)chunked

Client Vue部分代碼

client主要流程是：

vue router → created時期 判斷是否有頁面數(shù)據(jù) → 
提交mutation（有數(shù)據(jù)），dispatch action（異步拉取數(shù)據(jù)）→ state觸發(fā)修改，頁面dom生成 

這部分流程圖主要展現(xiàn)是Vuex和Vue resource部分的代碼，通過Vuex的dispatch action，觸發(fā)Vue resource的異步請求，等返回數(shù)據(jù)則commit mutation。

后端渲染+SPA單頁應(yīng)用

經(jīng)過改造后整個流程變成：

1.「首次后端渲染」：此時需要后端渲染主要HTML+頁面數(shù)據(jù)，利用chunked，先將不依賴后端數(shù)據(jù)部分返給瀏覽器，頁面數(shù)據(jù)和后面的HTML拿到數(shù)據(jù)后再返給瀏覽器。 client.tpl被「一分為二」：HTML[0] + HTML[1]

a.將頁面通用的css和js lib庫，放在HTML[0]中，首先返回，瀏覽器先解析下載

b.業(yè)務(wù)代碼初始化代碼放在HTML[1]， 等到獲取到后臺API數(shù)據(jù)一起返回

2.「非首次跳轉(zhuǎn)」：這是一個單頁應(yīng)用的流程，用戶點擊鏈接，實際走的是vue的router，然后出發(fā)vue頁面渲染，URL是通過history pushState mode更改實際URL，這時候如果強刷或者復(fù)制url在瀏覽器打開，又走「首次后端渲染」

a.vue頁面渲染需要的數(shù)據(jù)是通過vue-resource發(fā)起ajax請求，拿到數(shù)據(jù)之后commit mutation改變state

Vuex梳理

之前代碼每個組件都單獨ajax請求自己的數(shù)據(jù)，導(dǎo)致Vuex的module特別多特別亂，而且后端api接口太多太碎，不好維護。最后開發(fā)的童鞋自己都在群里抱怨，找個action或者mutation都不知道在哪個文件內(nèi)，需要搜代碼。。

首先做約定，明確什么時候使用Vuex：

頁面view相關(guān)的數(shù)據(jù)才使用Vuex來管理，頁面功能性ajax(例如簽到、兌換)不要使用vuex;「首次后端渲染」和「非首次跳轉(zhuǎn)」的view數(shù)據(jù)都通過commit mutation來修改state，最終映射到DOM表現(xiàn)上;功能性ajax則在組件內(nèi)自己發(fā)請求實現(xiàn)，保持組件內(nèi)聚;

P.S：這就是「貧血組件」和「充血組件」的區(qū)別，本身組件內(nèi)的狀態(tài)和邏輯都放在全局store管理，會增加store復(fù)雜度，降低效率(代碼性能和開發(fā)效率)

然后，收斂vuex module

收斂是根據(jù)業(yè)務(wù)頁面做的，前文提到：

頁面主要包括：首頁、任務(wù)+列表、商品+列表、個人信息和記錄以及其他類(說明和規(guī)則等)

其中需要數(shù)據(jù)的有：首頁、任務(wù)(詳情、列表)、商品(詳情、列表)和個人中心四個。

改造前module：

改造后module針對業(yè)務(wù)梳理的四個大頁面內(nèi)容，保留了四個：

減少mutation數(shù)據(jù)處理邏輯

復(fù)用后端接口數(shù)據(jù)格式，減少mutation數(shù)據(jù)處理邏輯

改造前很多action存在下面的代碼(注意箭頭部分)：

其中這個循環(huán)主要做兩件事情：修改 type、修改 img_url為 url，實際根本沒有必要：

• 修改 type：實際這已經(jīng)是頁面view層的邏輯了，在vue的模板或者computed中做更合適
• 修改 img_url為 url：這里實際是產(chǎn)品的封面圖，改成 url反而更不合適了，而且導(dǎo)致了數(shù)據(jù)不一致

代碼可以直接用 item即可!即不需要做額外的循環(huán)處理，保證數(shù)據(jù)一致性，避免前端的二次設(shè)計

API顯性聲明

之前所有的api都是走了一個 proxy，通過node轉(zhuǎn)發(fā)一下，直接到了后臺API接口，代碼如下：

看似很方便甚至有點暗爽的實現(xiàn)，實則帶來了下面的問題：

1. 接口非顯性聲明，降低可控性，造成沒法枚舉有多少接口，各個接口需要什么參數(shù)，增加維護成本
2. 安全性!后臺這個服務(wù)是完全暴漏給了前端，如果存在敏感的接口，前端js就可以直接透傳利用

改造后的代碼放在model層，供「首次后端渲染」和「非首次單頁」ajax請求使用：

優(yōu)化

除了做代碼重構(gòu)改造外，還在間隙中做了一些優(yōu)化，這里記錄一下：

后端渲染使用chunked

詳見本文「后端node server部分代碼」和「后端渲染+SPA」

數(shù)據(jù)復(fù)用

很多頁面設(shè)計會在首頁和列表頁面存在有產(chǎn)品的title、圖片和簡單的一些meta，例如下圖：

[[196162]]

點擊鏈接進去詳情頁面可以直接利用，這部分?jǐn)?shù)據(jù)我們做了復(fù)用。

實現(xiàn)方法是：頁面點擊的時候，將該條數(shù)據(jù)內(nèi)容commit給下一個頁面的mutation。

緩存

緩存在node和前端Ajax API多有，后端node主要緩存的是首頁，因為首頁需要請求4個接口(接口梳理后)，其中三個接口是跟用戶登錄態(tài)無關(guān)的，這三個接口可以用lru-cache緩存起來。

前端的ajax api緩存是在 get請求增加的，可以根據(jù)實際情況用，根據(jù)url作為key，使用sessionStorage存儲(同時cache類自己實現(xiàn)了緩存時間)

技巧

除了優(yōu)化外，我在介紹下兩個技巧：單頁切換view的loading和統(tǒng)一的錯誤處理。

在單頁跳轉(zhuǎn)內(nèi)，下一個view需要API請求獲取數(shù)據(jù)，然后才能渲染，這時候需要加載個loading顯示(或者做個切換動效)。

原理是：

1.利用eventBus，在router中添加兩個事件 closeLoading和 vue.action.error，分別用于「關(guān)閉loading」和「展現(xiàn)頁面數(shù)據(jù)錯誤的錯誤頁」

l2.oading展現(xiàn)在router的 beforeEach的鉤子內(nèi)實現(xiàn)，loading的事件在vuex的action獲取數(shù)據(jù)成功之后發(fā)送

3.錯誤的觸發(fā)有vuex 的 action / mutation 來發(fā)送事件

eventBus也不用自己寫，可以直接用Vue實例的 $on、 $emit、 $once等就夠了，代碼如下：

import Vue from 'vue' 
export default new Vue() 

總結(jié)

重構(gòu)主要做的事情是：

1.統(tǒng)一接口請求，重新梳理API;

2.收斂Vuex store設(shè)計(包括mutation/action的聚合，state簡化);明確Vuex的使用邊界

3.明確組件職責(zé)邊界，劃分「充血組件」與「貧血組件」

4.抽象封裝重復(fù)的代碼邏輯

5.做了一些簡單優(yōu)化

說下成果：項目已經(jīng)delay很久，從4月初到5月初已經(jīng)一個月了還沒上線，接手項目是五一前，整個重構(gòu)共2個人力用了三天完成95%的工作，目前已經(jīng)提測，

下面是重構(gòu)項目的團隊內(nèi)部問題總結(jié)：

1.項目開發(fā)中一定要有大局意識，雖然現(xiàn)在項目多是分組件來的開發(fā)方式，但是開發(fā)前要跟大家交代清楚約定、規(guī)范，什么該做什么不該做;

2.技術(shù)負(fù)責(zé)人多 check 代碼，防止錯誤的道路上越行越遠(yuǎn);

3.要有全局意識，關(guān)注整個流程，不要只看到自己的「一畝三分地」，比如：在某個商品頁面，購買/兌換成功了，不要認(rèn)為沒有問題了，可能記錄頁面還沒有展現(xiàn)(后臺接口沒有入庫);

4.Don’t repeat yourself!看見重復(fù)代碼就渾身難受，「抽象」能力是工程師的基本能力。

5.增強debug能力，發(fā)現(xiàn)問題直覺就能判斷出來哪個環(huán)境，然后針對性debug

【本文為51CTO專欄作者“三水清”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文