寫在前面

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

（面向過程視角下的）前端工程 = 過程 + 過程間的銜接

其中，過程旨在解決效率問題，而過程間銜接關注更多的是體驗問題，前端工作流相關的所有工程設施都可以按這個標準來劃分，要麼是過程，要麼是銜接

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

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

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

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

• 過程邊界不清晰，缺少層次結構：很容易產生一大堆拉拉扯扯的零散工具/平臺，如效能日誌匯出工具、效能分析診斷工具、效能監控平臺、效能資料視覺化平臺

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

一.前端工程中的 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 中後臺等等，一個流程環節在不同場景對應各自的實現

因此，不同的角色能夠在一套系統中完成各自的工作，同樣的研發模式能夠產出不同型別的前端應用程式

四.總結

從面向物件的角度來看，前端工程是物件和物件間的關係及互動行為：

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

物件的數量直接關係到體驗，物件間依賴關係的複雜度決定著效率。因此，要麼減少主體物件需要關注的頂層物件數量，要麼簡化物件間的依賴關係

參考資料

• 面向物件程式設計思想之（一）概述
• 面向物件程式設計思想之（二）解決問題的方法
• 面向物件程式設計思想之（三）面向物件程式設計的特點
• 面向物件程式設計思想之（四）類與物件（例項）的關係

&n