跳到主要內容
黯羽輕揚每天積累一點點

面向对象视角下的前端工程體系

免費2020-09-03#Frontend Engineering#前端工程#前端工程的定义#前端工程演进#前端工程化#前端研发流程

從面向对象的角度來看，前端工程是對象和對象間的關係及交互行為

寫在前面

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

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

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

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

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

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

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

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

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

一。前端工程中的 OO 概念

對象

對象，是對前端應用生產��動中各個實體的抽象，其中一些對象是主體（比如充當不同角色的人），另一些是客體（比如工具、平臺等各種具體事物）

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

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

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

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

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

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

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

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

與面向過程的視角不同，這裡更關心的是對象和對象間的交互行為，以前端開發工作為例：

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

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

也就是說：

（面向对象視角下的）前端工程 = 對象 + 對象間的關係及交互

其中，對象的數量關係到體驗，對象數量越多，主體需要關注的東西越多，體驗越差，對象依賴關係的複雜度決定了效率，對象關係越複雜，交互越多越繁瑣，效率越低

接口

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

  • 協議/約定

  • 規範

這些抽象產物定義了對象間通信的消息格式，讓人與人、工具與工具、工具與人都能夠緊密協作

抽象類

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

  • 研發模式

  • 技術方案

  • 流程標準

  • 工具鏈

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

二。面向对象的前端工程設計

審視前端生產活動

先將視角爬升到白雲之上足夠高的地方，再看前端生產活動：

現實問題（用戶需求） -> 前端生產活動 -> （解決方案）前端應用程序

P.S. 前端生產活動，指的是前端項目從需求到發布上線的整個生命週期

即，通過前端應用程序解決現實問題，中間的生產活動就是前端工程所關注的領域

如果把前端工程看作一個系統，其運作原理大致是這樣：

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

輸入用戶需求，輸出前端應用程序，前端工程一直以來所要解決的問題無非兩個：

  • 效率：減少一些人、減少一些交互、規範化一些中間產物

  • 體驗：簡化一些交互、減少一些中間產物

P.S. 當然，質量是前提條件，就像 CAP 中的 P，實屬沒得選。所以傷及質量的效率、體驗提升不在討論範圍內

建模前端工程

首先，識別出系統中的所有主體對象：

  • 項目經理

  • 產品經理

  • 設計師

  • 前端工程師

  • 後端工程師

  • 測試工程師

  • 運維工程師

  • 運營專員

那麼頂層應該是前端生產平臺，定義了研發模式和流程標準，讓這些角色能夠協同工作：

-----------------------------------------------------
|                    前端生產平臺                    |
-----------------------------------------------------
| 項目中心 | 研發中心 | 發布中心 | 監控中心 | 運營中心 |
-----------------------------------------------------

第二層是 5 大中心，承載前端應用程序在生命週期不同階段的生產活動，關鍵類如下：

  • 項目中心：項目、迭代及其相關資源類（需求文檔、設計稿、數據協議）

  • 研發中心：腳手架、物料池、IDE、構建工具、調試器、測試套件等類

  • 發布中心：部署服務類

  • 監控中心：應用數據報表、報警服務類

  • 運營中心：用戶數據報表、配置後臺類

其中，以源碼編輯為中心的研發工作臺已經成為趨勢，前端工作流相關的工具、平臺與 [定製化端 IDE/雲 IDE](/articles/定製化 ide 的核心價值/#articleHeader8) 提供的開發環境充分融合，集中解決過程間銜接的體驗問題

另一方面，傳統的前端研發模式也正在發生變革，例如：

  • 工具化/自動化設計還原：設計師直接產出可用的前端代碼，而不再輸出設計稿，減少了反覆確認視覺效果的低效交互

  • 基於標準組件的低代碼開發模式：將中間產物規範化，脫離全套開發工具（腳手架、IDE、構建工具等）也能產出前端應用程序，同樣減少了一些對象間的交互，效率有所提升

整個前端工程系統都是為了更快捷地交付前端應用程序，從這個角度來看，研發模式上的這些變革也是順理成章的

三。抽象、封裝、繼承與多態

抽象

抽象的目的是增加靈活性和通用性（抵抗變化），前端工程中有 3 種常見的抽象：

  • 從諸多同類客體對象抽象出通用模型：跨容器框架（如 Rax）、跨引擎接口（如 React Native JSI）、標準容器

  • 從中間產物抽象出標準協議：跨端組件、通用 API

  • 從對象交互活動中抽象出規範流程：研發模式、技術方案（如 [Lottie](/articles/lottie 動畫簡介/)）

其中，抽象層的作用分為兩種：

  • 把變化的部分圈起來：抽象層以下能夠靈活變化，抽象層之上對這些變化沒有感知

  • 將不變的部分固化：流程固定不變，但流程中的某些環節可替換，就像 模版方法模式

封裝

封裝的目的是資訊隱藏，就像一個櫃檯窗口，隔開了後廚與前廳，用來區分實現者和使用者

在前端工程中按關注點的是平臺維護者和用戶，例如：

  • IDE：是對前端開發相關的整套工具環境的封裝，包括腳手架、編輯器、調試器、依賴管理工具、構建工具等在內

  • 構建工具：是對本地開發、測試/正式部署等環節所需的資源處理步驟的封裝，包括源碼編譯、資源優化、源碼/產物靜態檢查等步驟

  • 發布服務：是對正式、測試環境下的部署、灰度發布、回滾等功能的封裝，讓測試工程師、產品經理無需專業的運維知識也能完成前端應用的部署和發布

封裝能夠有效減少頂層對象數目，將內部的依賴隱藏起來，主體對象需要關注的對象更少，不必了解內部具體交互細節也能輕鬆完成一些複雜工作

繼承

繼承的目的是複用現有對象的屬性或行為，前端工程中常見的複用形式有：

  • 工具包：將相對完整的工程能力打包成 CLI/GUI 工具或 IDE 插件包，可集成到其它工程體系中

  • SDK：將工程能力中可複用的部分抽離出來，允許在此基礎上二次開發和擴展

其中，IDE 插件包是一種相對新的複用形式，比定製 IDE 和 GUI 客戶端的成本更低，也不失為一種好的選擇

多態

多態的目的是擴展，從前端工程上看，多態體現在：

  • 面向角色的定製：比如產品經理、前端工程師對應的系統主頁不同

  • 面向場景的橫向拓展：比如小程序、Web、移動端、PC 中後臺等等，一個流程環節在不同場景對應各自的實現

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

四。總結

從面向对象的角度來看，前端工程是對象和對象間的關係及交互行為：

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

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

參考資料

評論

暫無評論，快來發表你的看法吧

提交評論