摘要
前端領域有兩大永恆的主題——性能和效率，中後臺場景下對性能的要求不高，但對效率的要求是極致的。在這種背景下，我們在業務開發過程中孵化出了幾個工具和平臺，分享下我們的設計和思考。
背景
在任何技術領域中性能和效率一直都備受關注。中後臺項目中由於移動化辦公尚未普及，目前大多數還是以PC頁面的形式展現 ，用戶使用平臺的目的也較爲單一，僅是爲了工作。
這種場景下性能一般不是關注的重點，加載時間即使是2、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個，可用性、可維護性、穩定性、提升效率。若想在前端工程化方面有更多的探索，效率提升這塊是重點，它基於模塊化、規範化、自動化來實現。具體實踐中我們會從架構層面做模塊化和規範化，自動化事務由平臺負責，使用工具減少開發過程中的耗時。
技術項目
在開發之前找出當前業務中的痛點，確定要解決的問題。開發過程中制定漸進增強的計劃，逐步完善項目切勿想一蹴而就，爲了縮短開發週期可以由團隊中相對高階的同學對項目進行模塊拆分，分配給其他同學。開發完成後一定要進行快速的迭代和響應，認爲時機成熟就可以去做推廣，並使用可量化的數據來展現成果。
聲明：該文觀點僅代表作者本人，搜狐號系信息發佈平臺，搜狐僅提供信息存儲空間服務。
