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

在任何技術領域中效能和效率一直都備受關注。中後臺專案中由於移動化辦公尚未普及，目前大多數還是以PC頁面的形式展現 ，使用者使用平臺的目的也較為單一，僅是為了工作。

這種場景下效能一般不是關注的重點，載入時間即使是2、3秒影響也不會太大，且PC的硬體裝置和網路狀況相對移動端要好很多，只要稍加註意效能就不會有什麼問題。

但是在效率（工程效率）上卻要有極致的提升，因為中颱場景中頁面會非常多。就以供應鏈場景舉例，我們的供應鏈下有N個系統，首先是採購系統，採購完後儲存到倉庫，倉庫中有倉儲系統，之後是配送和營銷。這整一套流程需要有一個資料平臺來支撐，無論是正向還是逆向，因此頁面資料會非常多，對開發效率有很高的要求。

開發效率方面一般能想到的優化就是減少重複勞動。前端開發階段可以通過一些工具或平臺減少開發上的重複，也可以從整個專案鏈路來看有哪些可優化點，比如聯調、測試、線上維護等方面。針對這兩點，我們主要做了3個實踐：IDE外掛、“Mock”平臺、模板倉庫平臺。

一般要提高在IDE中編寫程式碼的效率採用的都是IDE本身提供的snippets的方式，但是這些snippets儲存在本地，無法進行共享。外掛的形式無疑能很好的解決問題，由於我們的場景使用的是Element UI，所以專門定製了一個外掛pickman。與大多數擁有類似功能的外掛一樣，它可以將特定的程式碼片段插入到IDE中。另外為了減少檢視文件的耗時，我們提供了更方便的文件檢視方式，在選中標籤之後按下cmd+1（mac）就會開啟文件中相應的頁面並展示在IDE中。

在沒有真實資料介面的情況下若要除錯資料最常見的方法是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個，可用性、可維護性、穩定性、提升效率。若想在前端工程化方面有更多的探索，效率提升這塊是重點，它基於模組化、規範化、自動化來實現。具體實踐中我們會從架構層面做模組化和規範化，自動化事務由平臺負責，使用工具減少開發過程中的耗時。

在開發之前找出當前業務中的痛點，確定要解決的問題。開發過程中制定漸進增強的計劃，逐步完善專案切勿想一蹴而就，為了縮短開發週期可以由團隊中相對高階的同學對專案進行模組拆分，分配給其他同學。開發完成後一定要進行快速的迭代和響應，認為時機成熟就可以去做推廣，並使用可量化的資料來展現成果。