前端開發中減小重複勞動，提高效率的方法

內容來源：2018 年 6 月 23 日，餓了麼前端技術專家徐辛承在「餓了麼技術沙龍・第27彈 【前端專場】」進行《中後臺場景下的工具化和平臺化實踐》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3099 | 8分鐘閱讀

獲取嘉賓演講視頻及PPT： suo.im/4vQeeG

摘要

前端領域有兩大永恆的主題——性能和效率，中後臺場景下對性能的要求不高，但對效率的要求是極致的。在這種背景下，咱們在業務開發過程當中孵化出了幾個工具和平臺，分享下咱們的設計和思考。

背景

在任何技術領域中性能和效率一直都備受關注。中後臺項目中因爲移動化辦公還沒有普及，目前大多數仍是以PC頁面的形式展示 ，用戶使用平臺的目的也較爲單一，僅是爲了工做。

這種場景下性能通常不是關注的重點，加載時間即便是二、3秒影響也不會太大，且PC的硬件設備和網絡情況相對移動端要好不少，只要稍加註意性能就不會有什麼問題。

可是在效率（工程效率）上卻要有極致的提高，由於中臺場景中頁面會很是多。就以供應鏈場景舉例，咱們的供應鏈下有N個系統，首先是採購系統，採購完後存儲到倉庫，倉庫中有倉儲系統，以後是配送和營銷。這整一套流程須要有一個數據平臺來支撐，不管是正向仍是逆向，所以頁面數據會很是多，對開發效率有很高的要求。

工具和平臺的實踐

開發效率方面通常能想到的優化就是減小重複勞動。前端開發階段能夠經過一些工具或平臺減小開發上的重複，也能夠從整個項目鏈路來看有哪些可優化點，好比聯調、測試、線上維護等方面。針對這兩點，咱們主要作了3個實踐：IDE插件、「Mock」平臺、模板倉庫平臺。

IDE插件

通常要提升在IDE中編寫代碼的效率採用的都是IDE自己提供的snippets的方式，可是這些snippets存儲在本地，沒法進行共享。插件的形式無疑能很好的解決問題，因爲咱們的場景使用的是Element UI，因此專門定製了一個插件pickman。與大多數擁有相似功能的插件同樣，它能夠將特定的代碼片斷插入到IDE中。另外爲了減小查看文檔的耗時，咱們提供了更方便的文檔查看方式，在選中標籤以後按下cmd+1（mac）就會打開文檔中相應的頁面並展現在IDE中。

「Mock」平臺

在沒有真實數據接口的狀況下若要調試數據最多見的方法是mock.js，經過一些規則隨機生成一些相應的數據。

大體流程如上。先通過設計評審出一份接口設計文檔，以後前端根據文檔mock數據，開發過程當中與後端合做校訂協議，後端使用postman之類的工具修正接口，最後進入真實數據聯調階段。

不過上面的過程當中存在幾個問題。

一是如何維護mock數據。好比針對某個頁面生成mock數據的文件夾路徑如何存放，若是存放在js同級目錄下，上線的時候就要剔除掉這些json數據，若是是統一文件夾存儲，那麼就要針對代碼中請求路徑進行替換。另外一方面是沒法保持實時更新，致使數據陳舊無人維護，又要從新生成新的mock數據。

二是如何約束接口文檔。一般咱們是將文檔規則寫在wiki中，不過這樣很難保證真實性，好比字段數據類型是否正確、request和response順序問題。

三是如何避免髒代碼注入。

前兩個問題已被開源平臺Rap2很好解決了，該平臺主要分爲用戶和API兩個維度的管理。每一個用戶會被分配到不一樣團隊，目的是爲了權限控制，防止API濫用；API管理方面有API倉庫進行api分類。

至於髒代碼注入其實能夠經過proxy方式來解決，好比在webpack的proxy中寫入dev環境下對應的domain。另外還有一個問題沒有提到，就是如何遷移wiki，由於文檔都是在wiki中，若是要遷移已維護好的文檔成本會相對較。爲此咱們作了一個遷移工具，它會遍歷整個wiki的dom進行歸類，而後取出全部的數據轉化成json，最後將json導入到平臺中。

字段重複

平臺中API管理部分的字段重複度很高，以供貨商採購的流程來講，其中有個skuinfo（商品數據）的概念，這個skuinfo的規則是固定的，好比ID必須爲9位數字、number爲string等等。可是因爲每一個API的管理相對孤立，不一樣的人寫的API的生成規則就有可能不一樣，這形成的問題一方面是不規範，另外一方面增長了重複勞動。

因此咱們引入了實體的概念，每一個實體能夠是一個對象或屬性。它細粒度到每一個value的維度，不只實體之間能夠相互引用，API和實體間也能夠相互引用。這樣就能夠將全部重複的工做抽象成一個實體，另外還能夠對實體部分進行權限控制，這兩個措施本質上是讓每一個字段有準確、惟一的生成規則。

新的問題

縱觀整個開發流程，其實中後臺場景下QA測試的時候關注的是數據流轉的正確性，並不關注UI和UE的細節。其次因爲咱們的項目成立時間較短QA人員不足任務又比較緊張，因此初期是以黑盒測試爲主。這種狀況下爲了保證質量，就須要引入自動化測試機制，主要有三個階段模擬輸入、自動編寫測試case、驗證輸出。

基於上面的考量，能夠發現咱們須要的不只是單純的Mock平臺，而是mock加自動化測試的輔助平臺。目前咱們所能作的是給自動化測試提供輸入，由於mock階段和自動化測試階段本質上有類似性。Test case環節要由QA維護，咱們這邊能作的有限。驗證輸出環節則能夠作一些相應工做，自己mock的正向流程就是從規則生成數據，而驗證環節剛好相反是以數據驗證是否符合規則。

將來規劃

在將來規範上咱們首先要實現的是驗證輸出的部分，其次是豐富mock規則以及可視化，還會作一個更新檢測工具來驗證這次更新是否符合mock平臺的維護文檔，最後是關於業務流程的測試。

模板倉庫平臺

要想快速開發大量的1.0項目，你們一般可能會使用腳手架工具。可是這裏存在幾個問題，首先腳手架工具沒法作到快速預覽，其次對於這類工具來講頁面就是最小維度，沒法再細分到組件片斷層面，最後它主要面對的是開發者，而中後臺項目中UI和UE的規則又相對比較統一，原型圖和最終頁面十分類似，這樣的話直接經過拖拽組件造成頁面和實際編寫模板代碼其實並沒有太多差異。

基於以上緣由咱們構建一個模板倉庫平臺，經過可視化的組件拼裝，快速生成頁面代碼。目前已經支持了模板上傳和在線預覽。

以後咱們可能還會新增命令行工具，便於開發者使用。也會逐步擺脫對組件庫和框架的依賴，實現徹底的零依賴。

經驗總結

工程化

我的理解工程化所須要實現的目標有4個，可用性、可維護性、穩定性、提高效率。若想在前端工程化方面有更多的探索，效率提高這塊是重點，它基於模塊化、規範化、自動化來實現。具體實踐中咱們會從架構層面作模塊化和規範化，自動化事務由平臺負責，使用工具減小開發過程當中的耗時。

技術項目

在開發以前找出當前業務中的痛點，肯定要解決的問題。開發過程當中制定漸進加強的計劃，逐步完善項目切勿想一蹴而就，爲了縮短開發週期能夠由團隊中相對高階的同窗對項目進行模塊拆分，分配給其餘同窗。開發完成後必定要進行快速的迭代和響應，認爲時機成熟就能夠去作推廣，並使用可量化的數據來展示成果。