[[196161]]

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

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

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

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

b.或者新開(kāi)個(gè)接口，這樣就造成接口越來(lái)越多，mutation部分代碼越來(lái)越重。

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

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

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

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

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

介紹下項(xiàng)目背景：

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

項(xiàng)目用Vue+yog2編寫(xiě)，ajax請(qǐng)求部分使用vue resource

架構(gòu)改造

整個(gè)項(xiàng)目還是用Vue+yog2來(lái)寫(xiě)，針對(duì)進(jìn)入頁(yè)面分為兩種情況：

1. 第一次通過(guò)網(wǎng)站URL進(jìn)入某個(gè)頁(yè)面，我稱(chēng)為：「首次后端渲染」
2. 非首次已經(jīng)進(jìn)入頁(yè)面URL后，用戶(hù)點(diǎn)擊鏈接在項(xiàng)目?jī)?nèi)跳頁(yè)，我稱(chēng)之為：「非首次跳轉(zhuǎn)」

整個(gè)流程整理如下：兩個(gè)流程從「兩個(gè)小人」開(kāi)始看起

后端node Server代碼部分

代碼流程如下：

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

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

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

client.tpl 部分代碼：

baseAction 部分實(shí)現(xiàn)chunked

Client Vue部分代碼

client主要流程是：

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

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

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

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

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

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

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

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

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

Vuex梳理

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

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

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

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

然后，收斂vuex module

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

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

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

改造前module：

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

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

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

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

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

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

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

API顯性聲明

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

看似很方便甚至有點(diǎn)暗爽的實(shí)現(xiàn)，實(shí)則帶來(lái)了下面的問(wèn)題：

1. 接口非顯性聲明，降低可控性，造成沒(méi)法枚舉有多少接口，各個(gè)接口需要什么參數(shù)，增加維護(hù)成本
2. 安全性!后臺(tái)這個(gè)服務(wù)是完全暴漏給了前端，如果存在敏感的接口，前端js就可以直接透?jìng)骼?/li>

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

優(yōu)化

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

后端渲染使用chunked

詳見(jiàn)本文「后端node server部分代碼」和「后端渲染+SPA」

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

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

[[196162]]

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

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

緩存

緩存在node和前端Ajax API多有，后端node主要緩存的是首頁(yè)，因?yàn)槭醉?yè)需要請(qǐng)求4個(gè)接口(接口梳理后)，其中三個(gè)接口是跟用戶(hù)登錄態(tài)無(wú)關(guān)的，這三個(gè)接口可以用lru-cache緩存起來(lái)。

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

技巧

除了優(yōu)化外，我在介紹下兩個(gè)技巧：?jiǎn)雾?yè)切換view的loading和統(tǒng)一的錯(cuò)誤處理。

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

原理是：

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

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

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

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

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

總結(jié)

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

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

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

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

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

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

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

下面是重構(gòu)項(xiàng)目的團(tuán)隊(duì)內(nèi)部問(wèn)題總結(jié)：

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

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

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

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

5.增強(qiáng)debug能力，發(fā)現(xiàn)問(wèn)題直覺(jué)就能判斷出來(lái)哪個(gè)環(huán)境，然后針對(duì)性debug

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

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