關注「前端向後」微信公衆號，你將收穫一系列「用心原創」的高質量技術文章，主題包括但不限於前端、Node.js以及服務端技術
寫在前面
從面向過程的角度來看前端工程，就是各個過程，以及過程之間的銜接：
（面向過程視角下的）前端工程 = 過程 + 過程間的銜接
其中，過程旨在解決效率問題，而過程間銜接關注更多的是體驗問題，前端工作流相關的所有工程設施都可以按這個標準來劃分，要麼是過程，要麼是銜接
反過來從問題角度看，體驗問題能夠通過銜接來緩解，比如打通上下游工具/平臺、寫個批處理工具、搭個管理平臺，效率問題則必須通過更優、更快的過程來解決，比如協作模式升級、構建速度優化
但面向過程的劃分也存在一些問題，例如：
-
一些相似的過程橫跨多個生產環節：打包工具跨開發、構建階段，調試套件跨開發、測試階段，迭代管理跨全流程
-
過程之間需要大量的銜接：一些工具需要配合使用，如腳手架與公共庫、編輯器與構建工具、調試套件
- 過程邊界不清晰，缺少層次結構：很容易產生一大堆拉拉扯扯的零散工具/平臺，如性能日誌導出工具、性能分析診斷工具、性能監控平臺、性能數據可視化平臺
既然如此，不妨換個視角觀察，從面向對象的角度來看
一.前端工程中的 OO 概念
對象
對象，是對前端應用生產活動中各個實體的抽象，其中一些對象是主體（比如充當不同角色的人），另一些是客體（比如工具、平臺等各種具體事物）
對象之間通過一系列交互行爲來完成前端應用的開發和交付：
-
產品經理：從現實生活中的問題發現用戶需求，並將用戶需求轉化成產品需求
-
設計師：根據產品需求設計 UI 效果和交互操作流程，以設計稿的形式輸出
-
後端工程師：根據產品需求設計數據模型，實現數據讀寫，約定前後端數據協議
-
前端工程師：根據產品需求還原設計稿，並根據前後端數據協議實現交互功能，產出前端應用程序
-
測試工程師：對前端應用程序進行充分測試，保證產品需求得到了一致滿足
-
運維工程師：將質量可靠的前端應用程序部署到生產環境
- 運營專員：將已上線的前端應用程序推廣給用戶
與面向過程的視角不同，這裏更關心的是對象和對象間的交互行爲，以前端開發工作爲例：
-
面向過程視角：現在處於開發階段，我要通過模塊拆分、編碼、調試等步驟來完成開發任務，接着項目進入下一階段
- 面向對象視角：我是前端工程師，我需要產品經理、設計師、後端工程師提供的產品需求、設計稿和數據協議，產出前端應用程序給到測試工程師
也就是說：
（面向對象視角下的）前端工程 = 對象 + 對象間的關係及交互
其中，對象的數量關係到體驗，對象數量越多，主體需要關注的東西越多，體驗越差，對象依賴關係的複雜度決定了效率，對象關係越複雜，交互越多越繁瑣，效率越低
接口
接口，是在前端應用生產過程中的一些抽象產物，不直接體現在最終交付物中，例如：
-
協議/約定
- 規範
這些抽象產物定義了對象間通信的消息格式，讓人與人、工具與工具、工具與人都能夠緊密協作
抽象類
抽象類，也是前端應用生產過程中的一些抽象產物，定義了不同對象之間的關聯和交互方式，例如：
-
研發模式
-
技術方案
-
流程標準
- 工具鏈
與接口不同，這些“抽象類”能夠約束多個對象之間的聯動關係，而接口要約束的是兩個對象之間的一次交互行爲
二.面向對象的前端工程設計
審視前端生產活動
先將視角爬升到白雲之上足夠高的地方，再看前端生產活動：
現實問題（用戶需求） -> 前端生產活動 -> （解決方案）前端應用程序
P.S.前端生產活動，指的是前端項目從需求到發佈上線的整個生命週期
即，通過前端應用程序解決現實問題，中間的生產活動就是前端工程所關注的領域
如果把前端工程看作一個系統，其運作原理大致是這樣：
一些人，通過一些交互，生成一些中間產物，最終交付前端應用程序
輸入用戶需求，輸出前端應用程序，前端工程一直以來所要解決的問題無非兩個：
-
效率：減少一些人、減少一些交互、規範化一些中間產物
- 體驗：簡化一些交互、減少一些中間產物
P.S.當然，質量是前提條件，就像CAP 中的 P，實屬沒得選。所以傷及質量的效率、體驗提升不在討論範圍內
建模前端工程
首先，識別出系統中的所有主體對象：
-
項目經理
-
產品經理
-
設計師
-
前端工程師
-
後端工程師
-
測試工程師
-
運維工程師
- 運營專員
那麼頂層應該是前端生產平臺，定義了研發模式和流程標準，讓這些角色能夠協同工作：
第二層是 5 大中心，承載前端應用程序在生命週期不同階段的生產活動，關鍵類如下：
-
項目中心：項目、迭代及其相關資源類（需求文檔、設計稿、數據協議）
-
研發中心：腳手架、物料池、IDE、構建工具、調試器、測試套件等類
-
發佈中心：部署服務類
-
監控中心：應用數據報表、報警服務類
- 運營中心：用戶數據報表、配置後臺類
其中，以源碼編輯爲中心的研發工作臺已經成爲趨勢，前端工作流相關的工具、平臺與定製化端 IDE/雲 IDE提供的開發環境充分融合，集中解決過程間銜接的體驗問題
另一方面，傳統的前端研發模式也正在發生變革，例如：
-
工具化/自動化設計還原：設計師直接產出可用的前端代碼，而不再輸出設計稿，減少了反覆確認視覺效果的低效交互
- 基於標準組件的低代碼開發模式：將中間產物規範化，脫離全套開發工具（腳手架、IDE、構建工具等）也能產出前端應用程序，同樣減少了一些對象間的交互，效率有所提升
整個前端工程系統都是爲了更快捷地交付前端應用程序，從這個角度來看，研發模式上的這些變革也是順理成章的
三.抽象、封裝、繼承與多態
抽象
抽象的目的是增加靈活性和通用性（抵抗變化），前端工程中有 3 種常見的抽象：
-
從諸多同類客體對象抽象出通用模型：跨容器框架（如Rax）、跨引擎接口（如React Native JSI）、標準容器
-
從中間產物抽象出標準協議：跨端組件、通用 API
- 從對象交互活動中抽象出規範流程：研發模式、技術方案（如Lottie）
其中，抽象層的作用分爲兩種：
-
把變化的部分圈起來：抽象層以下能夠靈活變化，抽象層之上對這些變化沒有感知
- 將不變的部分固化：流程固定不變，但流程中的某些環節可替換，就像模版方法模式
封裝
封裝的目的是信息隱藏，就像一個櫃檯窗口，隔開了後廚與前廳，用來區分實現者和使用者
在前端工程中按關注點 的是平臺維護者和用戶，例如：
-
IDE：是對前端開發相關的整套工具環境的封裝，包括腳手架、編輯器、調試器、依賴管理工具、構建工具等在內
-
構建工具：是對本地開發、測試/正式部署等環節所需的資源處理步驟的封裝，包括源碼編譯、資源優化、源碼/產物靜態檢查等步驟
- 發佈服務：是對正式、測試環境下的部署、灰度發佈、回滾等功能的封裝，讓測試工程師、產品經理無需專業的運維知識也能完成前端應用的部署和發佈
封裝能夠有效減少頂層對象數量，將內部的依賴隱藏起來，主體對象需要關注的對象更少，不必瞭解內部具體交互細節也能輕鬆完成一些複雜工作
繼承
繼承的目的是複用現有對象的屬性或行爲，前端工程中常見的複用形式有：
-
工具包：將相對完整的工程能力打包成 CLI/GUI 工具或 IDE 插件包，可集成到其它工程體系中
- SDK：將工程能力中可複用的部分抽離出來，允許在此基礎上二次開發和擴展
其中，IDE 插件包是一種相對新的複用形式，比定製 IDE 和 GUI 客戶端的成本更低，也不失爲一種好的選擇
多態
多態的目的是擴展，從前端工程上看，多態體現在：
-
面向角色的定製：比如產品經理、前端工程師對應的系統主頁不同
- 面向場景的橫向拓展：比如小程序、Web、移動端、PC 中後臺等等，一個流程環節在不同場景對應各自的實現
因此，不同的角色能夠在一套系統中完成各自的工作，同樣的研發模式能夠產出不同類型的前端應用程序
四.總結
從面向對象的角度來看，前端工程是對象和對象間的關係及交互行爲：
一些人，通過一些交互，生成一些中間產物，最終交付前端應用程序
對象的數量直接關係到體驗，對象間依賴關係的複雜度決定着效率。因此，要麼減少主體對象需要關注的頂層對象數量，要麼簡化對象間的依賴關係