前端工程化衡量準則

小編說：前端工程化這個概念在近兩年被廣泛地提及和討論，究其原因，是前端工程師所負責的客戶端功能邏輯在不斷複雜化。本文介紹了前端工程化的衡量準則以及3個階段。

如果說互聯網時代是前端工程師的舞台可能有些誇大其詞，但前端工程師絕對撐起了互聯網應用開發的「半壁江山」。傳統網站、手機應用、桌面應用、微信小程序等，前端工程師已經不是幾年前被謔稱的「切圖仔」了。以往的「寫demo，套模板」模式已經嚴重拖累了前端開發以及整體團隊的開發效率。在這樣的時代背景下，前端工程化便應運而生了。

雖然前端工程化是最近幾年才興起的一個方向，但工程化並不是一個新詞。前端工程師普遍不熟悉的其他開發領域很早就具備了高度的工程化，比如Web伺服器端開發。在前端業務邏輯比較簡單的年代，前端資源通常作為伺服器端資源的一種「附屬品」，Web開發者沒有意識到且也沒有必要為前端制定專門的工程化方案。前端需求和邏輯的不斷加重是催生前端工程化的環境因素，前端相關技術、規範和工具的發展是前端工程化得以實施的必要前提。

前端工程化的衡量準則

前端工程化的主要目標是解放生產力、提高生產效率。通過制定一系列的規範，藉助工具和框架解決前端開發以及前後端協作開發過程中的痛點和難點問題。

前後端分離是前端工程化方案的指導方針，這三者也就成為衡量前端工程化方案是否合格的重要因素。具體的衡量標準就是我們常說的3個字：快、准、穩。

1．從開發角度衡量工程化主要體現在「快」。

開發速度是Web產品迭代最迫切提升，也是催生開發人員與產品經理、項目經理以及測試人員之間矛盾的主要因素，自然也是衡量前端工程化方案最直觀、最明顯的標準。工程化方案的核心目標之一就是在保證質量的前提下，儘可能提高產品的開發速度。

2．從測試角度衡量工程化主要體現在「快」和「准」。

測試的「快」體現在前端工程師和伺服器端工程師並行開發完成之後的集成測試階段。我們從測試角度分析前後端分離時提到了完備且合理的單元測試通過後，集成測試階段是不應該存在邏輯性錯誤的。但人不是機器，不可能考慮得面面俱到。從這個角度考慮，工程化要解決的就是盡量減少低級的邏輯錯誤，降低集成測試階段消耗的時間成本。

測試的「准」體現在集成測試階段對問題的準確定位。工程化不僅僅是冷冰冰的工具和平台，同時也需要嚴格的分工制度。通過明確責任人，對測試出現的問題進行快速準確的定位。

3．從部署角度衡量工程化主要體現在「穩」。

部署是一個完整迭代周期的最終階段。經歷了漫長的開發和測試，團隊中的所有成員都希望自己的產品能夠第一時間完美無誤地出現在用戶面前。部署並不是簡單地把文件「放到」線上就可以了，還需要考慮用戶客戶端的緩存是否影響了新版本的展現、考慮測試用例沒有覆蓋100%情況下的危機處理、考慮不同地區開放不同版本等。如果你想將Web產品穩穩地呈現給用戶，部署環節必須把好最後也是最關鍵的一關。

前端工程化的3個階段

1．本地工具鏈——工程化不等同於工具化

你也許會有這樣的念頭：所謂的前端工程化不就是把一系列工具進行整合嗎？工程化的核心難道就是工具化？

雖然對前端工程化的論述中反覆提到了「工具」這個詞，但工程化的核心並非工具。前端工程化是以規範工作流程為手段，以工具為實現媒介，其最終目的是為了提高研發效率以及保證Web產品的線上質量。如果給前端工程化一個明確定義的話，較恰當的定義如下：前端工程化是一系列工具和規範的組合，規範為藍本，工具為實現。其中規範又包括：

項目文件的組織結構，比如使用目錄名稱區分源文件和目標文件。

源代碼的開發範式，比如使用既定的模塊化方案。

工具的使用規範，比如工程化自身的配置規範。

各階段環境的依賴，比如部署功能的實現需要目標伺服器提供SSH許可權。

工具的作用是將規範具化為具體功能並且在一定程度上將開發者限定在既有規範內。前端工程化的初級階段便是將各類工具的功能進行整合，為業務開發人員提供統一規範的工具棧。我們不妨將此階段的前端工程化稱為本地工具鏈形態。此形態下的所有工程化功能模塊，包括構建、本地伺服器、部署等，均在本地環境下工作。

本地工具鏈形態的工程化方案解決的問題，降低了業務開發人員學習、使用工具的成本。這個方案將複雜的功能需求全部交給工具鏈內部解決，你可以將這個形態的方案想像成一隻擁有高度內部複雜度的「八爪魚」，其伸出的觸手是內部功能開放給業務開發人員使用的介面。

工具鏈的統一，另一個好處是鞏固了流程的規範性，開發者使用統一的工具鏈、遵循統一的規範進行業務代碼的編寫，利於多人協作與程序的維護。

2．管理平台——進一步淡化差異、加深規範

本地工具鏈形態的工程化雖然解決了前端開發以及前後端協作開發中的部分痛點問題，但由於所有的功能模塊均在本地環境工作，因此必然會受到環境差異性的影響，比如操作系統類型、版本、內核等。這些因素會在一定程度上影響構建產出代碼的一致性。

除環境因素的影響，本地工具鏈形態的工程化還存在安全性隱患。舉個例子，部署功能模塊負責將構建產出的文件部署到測試或者線上伺服器，部署過程中必然涉及許可權問題。對安全性要求不高的測試環境也就罷了，但如果人人都可以向生產環境部署文件則必然存在很大的安全隱患。所以，許可權必須嚴格控制，這就造成本地工具鏈的部署模塊的可用性大大降低。

講到這裡，前端工程化的下一進化形態便豁然開朗了：集中管理的雲平台。管理平台形態的工程化做到了以下幾點。

淡化環境差異性，保證構建產出的一致性。

許可權集中管理，提高安全性。

項目版本集中管理，便於危機處理，比如版本回滾等。

管理平台形態將各個功能模塊的執行環境集中化，從各模塊實現角度來講與本地工具鏈基本一致。

3．持續集成——前端工程化的目標是融入整體

即使進化到管理平台形態，前端工程化方案所解決問題的本質仍然只是將前端工程師與伺服器端工程師的工作解耦。這雖然提高了兩方的工作效率，但其各自的工作流卻是孤立的。前端有了構建和部署，後端也有了相應的階段，兩方的工作流是分離的，最終的融合工作仍然難以避免煩瑣的人工操作。舉個例子，如果需要生產環境版本回滾，前後端工程師分別對自己所維護的代碼進行操作，並且必須保證回滾操作的同步性，這期間難以避免人工上的溝通。

不論前端工程化的功能如何完備，規範如何嚴謹，需要謹記的是，前端工程化必然是整體Web工作流中間的一個子集方案。前端工程化最終的完美形態，必然與整體工作流結合，作為持續集成方案中的一環。謹記這條原則可以在探索完美方案過程中少走彎路。

GIF/1K

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！