面向對象視角下的前端工程體系

關注「前端向後」微信公衆號，你將收穫一系列「用心原創」的高質量技術文章，主題包括但不限於前端、Node.js以及服務端技術

寫在前面
從面向過程的角度來看前端工程，就是各個過程，以及過程之間的銜接：

（面向過程視角下的）前端工程 = 過程 + 過程間的銜接
其中，過程旨在解決效率問題，而過程間銜接關注更多的是體驗問題，前端工做流相關的全部工程設施均可以按這個標準來劃分，要麼是過程，要麼是銜接

反過來從問題角度看，體驗問題可以經過銜接來緩解，好比打通上下游工具/平臺、寫個批處理工具、搭個管理平臺，效率問題則必須經過更優、更快的過程來解決，好比協做模式升級、構建速度優化

但面向過程的劃分也存在一些問題，例如：

• 一些類似的過程橫跨多個生產環節：打包工具跨開發、構建階段，調試套件跨開發、測試階段，迭代管理跨全流程

• 過程之間須要大量的銜接：一些工具須要配合使用，如腳手架與公共庫、編輯器與構建工具、調試套件

• 過程邊界不清晰，缺乏層次結構：很容易產生一大堆拉拉扯扯的零散工具/平臺，如性能日誌導出工具、性能分析診斷工具、性能監控平臺、性能數據可視化平臺

既然如此，不妨換個視角觀察，從面向對象的角度來看

一.前端工程中的 OO 概念
對象
對象，是對前端應用生產活動中各個實體的抽象，其中一些對象是主體（好比充當不一樣角色的人），另外一些是客體（好比工具、平臺等各類具體事物）

對象之間經過一系列交互行爲來完成前端應用的開發和交付：

1. 產品經理：從現實生活中的問題發現用戶需求，並將用戶需求轉化成產品需求

2. 設計師：根據產品需求設計 UI 效果和交互操做流程，以設計稿的形式輸出

3. 後端工程師：根據產品需求設計數據模型，實現數據讀寫，約定先後端數據協議

4. 前端工程師：根據產品需求還原設計稿，並根據先後端數據協議實現交互功能，產出前端應用程序

5. 測試工程師：對前端應用程序進行充分測試，保證產品需求獲得了一致知足

6. 運維工程師：將質量可靠的前端應用程序部署到生產環境

7. 運營專員：將已上線的前端應用程序推廣給用戶

與面向過程的視角不一樣，這裏更關心的是對象和對象間的交互行爲，之前端開發工做爲例：

• 面向過程視角：如今處於開發階段，我要經過模塊拆分、編碼、調試等步驟來完成開發任務，接着項目進入下一階段

• 面向對象視角：我是前端工程師，我須要產品經理、設計師、後端工程師提供的產品需求、設計稿和數據協議，產出前端應用程序給到測試工程師

也就是說：

（面向對象視角下的）前端工程 = 對象 + 對象間的關係及交互
其中，對象的數量關係到體驗，對象數量越多，主體須要關注的東西越多，體驗越差，對象依賴關係的複雜度決定了效率，對象關係越複雜，交互越多越繁瑣，效率越低

接口
接口，是在前端應用生產過程當中的一些抽象產物，不直接體如今最終交付物中，例如：

• 協議/約定

• 規範

這些抽象產物定義了對象間通訊的消息格式，讓人與人、工具與工具、工具與人都可以緊密協做

抽象類
抽象類，也是前端應用生產過程當中的一些抽象產物，定義了不一樣對象之間的關聯和交互方式，例如：

• 研發模式

• 技術方案

• 流程標準

• 工具鏈

與接口不一樣，這些「抽象類」可以約束多個對象之間的聯動關係，而接口要約束的是兩個對象之間的一次交互行爲

二.面向對象的前端工程設計
審視前端生產活動
先將視角爬升到白雲之上足夠高的地方，再看前端生產活動：

現實問題（用戶需求） -> 前端生產活動 -> （解決方案）前端應用程序
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 中後臺等等，一個流程環節在不一樣場景對應各自的實現

所以，不一樣的角色可以在一套系統中完成各自的工做，一樣的研發模式可以產出不一樣類型的前端應用程序

四.總結
從面向對象的角度來看，前端工程是對象和對象間的關係及交互行爲：

一些人，經過一些交互，生成一些中間產物，最終交付前端應用程序

對象的數量直接關係到體驗，對象間依賴關係的複雜度決定着效率。所以，要麼減小主體對象須要關注的頂層對象數量，要麼簡化對象間的依賴關係