記一次Vue項目的重構
上周沒有更新原創技術文章，原因是忙著重構一個新接手的項目，此項目因為項目技術負責人離職，雖然投入人力持續增多，前端達到4人，后端3人，但因為新參與的童鞋對代碼結構和業務的理解，導致項目開發了一個多月，還有一堆問題，達不到上線要求。接手項目之后，一開始對項目業務場景和代碼進行簡單的了梳理，跟了一天項目，觀察提測后FE+RD的狀態，自己也動手改了一天代碼，不管是FE+RD包括自己都覺得實在是太難受了，小坑大坑不斷，于是決定重構。重構不是個人沖動，而是的的確確存在各種大大小小的問題：
1.接口太碎：項目本身按照Vue組件化開發，但是頁面每個組件獨自采用vuex+ajax請求管理自己的數據，比如：首頁由輪播圖、各種列表和用戶信息展現組成，導致首頁從上到下7~8個模塊，每個模塊都各自發自己的請求，訪問首頁需要同時發出8個ajax請求
2.因為「1」提到的，單個組件數據都是使用Vuex進行管理，導致Vuex的store太亂：而且FE按照組件去開發，各自跟后端RD兌接口、聯調，但是沒有人來統籌安排，導致大量重復工作;除此之外，action和mutation中的業務邏輯代碼太多，而不同頁面需要不同的數據格式，則導致：
a.或者在mutation當中對數據進行重新整理
b.或者新開個接口，這樣就造成接口越來越多，mutation部分代碼越來越重。
3.一開始設計或者溝通有誤。比如：用戶信息相關的接口，需要傳入用戶id(uid)，而不是通過登錄cookie從passport獲取;第三方接口需要用戶信息，竟然請求的時候將cookie發給對方(幸好cookie是http only的，沒有調通被我及時發現)
4.重復代碼太多，抽象能力太差。一份代碼在多個地方復制，導致代碼改來改去最后都不知道哪里改了哪里沒改
5.命名太亂，包括url、方法名之類，還有錯別字，getAdcontent(用戶地址信息)，getmaildetail(用戶地址信息)
6.研發人員缺乏全局意識，只管自己的代碼，而不關心整個流程。由于前后投入人較多，沒人對整個項目有把控，只能面向自己的需求編程。比如：積分獲取頁面，獲取成功之后，聯調成功，但是實際在積分獲取列表頁面卻沒有相關的記錄信息;在比如：任何用戶都可以領走別人的獎品，原因后端沒做獎品是否是當前登錄用戶獲取的校驗
7.問題定位能力不夠，遇見問題一調就是半天，找不到根本問題
介紹下項目背景：
此項目是一個用戶積分任務和消費項目，一些頁面需要用戶登錄，頁面主要包括：首頁、任務+列表、商品+列表、個人信息和記錄以及其他類(說明和規則等)
項目用Vue+yog2編寫，ajax請求部分使用vue resource
架構改造
整個項目還是用Vue+yog2來寫，針對進入頁面分為兩種情況：
- 第一次通過網站URL進入某個頁面，我稱為：「首次后端渲染」
- 非首次已經進入頁面URL后，用戶點擊鏈接在項目內跳頁，我稱之為：「非首次跳轉」
整個流程整理如下：兩個流程從「兩個小人」開始看起
后端node Server代碼部分
代碼流程如下：
- router → middleware → page/api action → model → ral請求數據
其中在action部分，專門寫了個 baseAction函數，封裝了重復的代碼，使用時傳入用于獲取數據的model方法和處理數據的方法即可。
render部分，針對頁面第一次請求需要將頁面數據放在HTML片段中chunk輸出，而不是通過ajax請求(為什么不用vue ssr，可以看下歷史公眾號文章《Vue SSR 從入門到Case Study》，之后單頁內跳轉是ajax請求)。詳細代碼如下：
client.tpl 部分代碼：
baseAction 部分實現chunked
Client Vue部分代碼
client主要流程是：
- vue router → created時期 判斷是否有頁面數據 →
- 提交mutation（有數據），dispatch action（異步拉取數據）→ state觸發修改，頁面dom生成
這部分流程圖主要展現是Vuex和Vue resource部分的代碼，通過Vuex的dispatch action，觸發Vue resource的異步請求，等返回數據則commit mutation。
后端渲染+SPA單頁應用
經過改造后整個流程變成：
1.「首次后端渲染」：此時需要后端渲染主要HTML+頁面數據，利用chunked，先將不依賴后端數據部分返給瀏覽器，頁面數據和后面的HTML拿到數據后再返給瀏覽器。 client.tpl被「一分為二」：HTML[0] + HTML[1]
a.將頁面通用的css和js lib庫，放在HTML[0]中，首先返回，瀏覽器先解析下載
b.業務代碼初始化代碼放在HTML[1]， 等到獲取到后臺API數據一起返回
2.「非首次跳轉」：這是一個單頁應用的流程，用戶點擊鏈接，實際走的是vue的router，然后出發vue頁面渲染，URL是通過history pushState mode更改實際URL，這時候如果強刷或者復制url在瀏覽器打開，又走「首次后端渲染」
a.vue頁面渲染需要的數據是通過vue-resource發起ajax請求，拿到數據之后commit mutation改變state
Vuex梳理
之前代碼每個組件都單獨ajax請求自己的數據，導致Vuex的module特別多特別亂，而且后端api接口太多太碎，不好維護。最后開發的童鞋自己都在群里抱怨，找個action或者mutation都不知道在哪個文件內，需要搜代碼。。
首先做約定，明確什么時候使用Vuex：
頁面view相關的數據才使用Vuex來管理，頁面功能性ajax(例如簽到、兌換)不要使用vuex;「首次后端渲染」和「非首次跳轉」的view數據都通過commit mutation來修改state，最終映射到DOM表現上;功能性ajax則在組件內自己發請求實現，保持組件內聚;
P.S：這就是「貧血組件」和「充血組件」的區別，本身組件內的狀態和邏輯都放在全局store管理，會增加store復雜度，降低效率(代碼性能和開發效率)
然后，收斂vuex module
收斂是根據業務頁面做的，前文提到：
頁面主要包括：首頁、任務+列表、商品+列表、個人信息和記錄以及其他類(說明和規則等)
其中需要數據的有：首頁、任務(詳情、列表)、商品(詳情、列表)和個人中心四個。
改造前module：
改造后module針對業務梳理的四個大頁面內容，保留了四個：
減少mutation數據處理邏輯
復用后端接口數據格式，減少mutation數據處理邏輯
改造前很多action存在下面的代碼(注意箭頭部分)：
其中這個循環主要做兩件事情：修改 type、修改 img_url為 url，實際根本沒有必要：
- 修改 type：實際這已經是頁面view層的邏輯了，在vue的模板或者computed中做更合適
- 修改 img_url為 url：這里實際是產品的封面圖，改成 url反而更不合適了，而且導致了數據不一致
代碼可以直接用 item即可!即不需要做額外的循環處理，保證數據一致性，避免前端的二次設計
API顯性聲明
之前所有的api都是走了一個 proxy，通過node轉發一下，直接到了后臺API接口，代碼如下：
看似很方便甚至有點暗爽的實現，實則帶來了下面的問題：
- 接口非顯性聲明，降低可控性，造成沒法枚舉有多少接口，各個接口需要什么參數，增加維護成本
- 安全性!后臺這個服務是完全暴漏給了前端，如果存在敏感的接口，前端js就可以直接透傳利用
改造后的代碼放在model層，供「首次后端渲染」和「非首次單頁」ajax請求使用：
優化
除了做代碼重構改造外，還在間隙中做了一些優化，這里記錄一下：
后端渲染使用chunked
詳見本文「后端node server部分代碼」和「后端渲染+SPA」
數據復用
很多頁面設計會在首頁和列表頁面存在有產品的title、圖片和簡單的一些meta，例如下圖：
點擊鏈接進去詳情頁面可以直接利用，這部分數據我們做了復用。
實現方法是：頁面點擊的時候，將該條數據內容commit給下一個頁面的mutation。
緩存
緩存在node和前端Ajax API多有，后端node主要緩存的是首頁，因為首頁需要請求4個接口(接口梳理后)，其中三個接口是跟用戶登錄態無關的，這三個接口可以用lru-cache緩存起來。
前端的ajax api緩存是在 get請求增加的，可以根據實際情況用，根據url作為key，使用sessionStorage存儲(同時cache類自己實現了緩存時間)
技巧
除了優化外，我在介紹下兩個技巧：單頁切換view的loading和統一的錯誤處理。
在單頁跳轉內，下一個view需要API請求獲取數據，然后才能渲染，這時候需要加載個loading顯示(或者做個切換動效)。
原理是：
1.利用eventBus，在router中添加兩個事件 closeLoading和 vue.action.error，分別用于「關閉loading」和「展現頁面數據錯誤的錯誤頁」
l2.oading展現在router的 beforeEach的鉤子內實現，loading的事件在vuex的action獲取數據成功之后發送
3.錯誤的觸發有vuex 的 action / mutation 來發送事件
eventBus也不用自己寫，可以直接用Vue實例的 $on、 $emit、 $once等就夠了，代碼如下：
- import Vue from 'vue'
- export default new Vue()
總結
重構主要做的事情是：
1.統一接口請求，重新梳理API;
2.收斂Vuex store設計(包括mutation/action的聚合，state簡化);明確Vuex的使用邊界
3.明確組件職責邊界，劃分「充血組件」與「貧血組件」
4.抽象封裝重復的代碼邏輯
5.做了一些簡單優化
說下成果：項目已經delay很久，從4月初到5月初已經一個月了還沒上線，接手項目是五一前，整個重構共2個人力用了三天完成95%的工作，目前已經提測，
下面是重構項目的團隊內部問題總結：
1.項目開發中一定要有大局意識，雖然現在項目多是分組件來的開發方式，但是開發前要跟大家交代清楚約定、規范，什么該做什么不該做;
2.技術負責人多 check 代碼，防止錯誤的道路上越行越遠;
3.要有全局意識，關注整個流程，不要只看到自己的「一畝三分地」，比如：在某個商品頁面，購買/兌換成功了，不要認為沒有問題了，可能記錄頁面還沒有展現(后臺接口沒有入庫);
4.Don’t repeat yourself!看見重復代碼就渾身難受，「抽象」能力是工程師的基本能力。
5.增強debug能力，發現問題直覺就能判斷出來哪個環境，然后針對性debug
【本文為51CTO專欄作者“三水清”的原創稿件，轉載請通過微信公眾號聯系作者獲取授權】
