前端領域模型，重構前端研發模式

作者 | 燭象

來源 | 釘釘前端團隊

無論是小程序還是 H5，前端 (GUI 編程) 的展現形態的變化性一直是前端開發效率變革上最大的攔路虎，本文擬抽象一個新的概念「前端領域模型」，對研發模式進行重新思考，以探討如何降低前端研發人力、提升開發體驗爲目標。

Part I 對規範 / 規則的論述

"無規範不成方圓"，規範的一致遵守能收斂噪音，達到一致性。在軟件工程的領域，當規範演變成規則後，軟件開發的持續交付會因爲規則的遵守而得以保持垂直、正交，熵的變化也能有可見的收斂。

在前端開發的過程中，我把開發過程抽象成如下的公式:

  1. 前端項目 = PageCompose(前端頁面)

  2. 前端頁面 = ComponentCompose(Data(數據) + UI(展現) + Interaction(交互))

  3. PageCompose ≈ Router(路由) Or Navigation(導航)

  4. ComponentCompose ≈ Layout(佈局編排)

目前市面上大部分的解決方案很多都是專注在其中某一個維度的方案解決，大致有以下幾類:

UI 解決方案:

Data 解決方案

PageCompose 解決方案

整體的解決方案:

以上列舉的有名的框架或者庫，是全球開發者用腦袋進行的投票，是值得研究和學習的典範。

作爲以上解決方案的重度使用者，我非常強烈的感知到了規範和規則在軟件開發過程中的巨大指引作用，這些規範和規則主要體現在如下幾個點:

  1. 體驗極佳的 api 設計: 明確的 IO(入參和返回)。

  2. 明確的 objective 目標: 自律性極強，在某個解決方案領域做深做強。

  3. 單一的使用及設計規範: 單一的強規範約束讓使用者 "一處學會，遍地會用"，這是一款技術產品傳播非常重要的點。

Part II 前端領域研發模式的探討

"工欲善其事，必先利其器"，良好的研發模式是軟件持續交付的重要保障。前端是軟件開發中交付密度最高的場景，高頻的變更和發佈嚴重威脅着前端穩定性，因此 "優秀" 的研發模式對前端開發而言極其重要，在 John Ousterhout 的著作《A Philosophy of Software Design》提到 軟件設計的核心在於降低複雜性，這裏面的我想說的 "優秀" 更多的也將專注在 降低前端複雜性。

大部分前端的研發流程有着相似的分層結構:

現代前端開發已經有非常成熟的數據驅動 (Data Driven Development) 開發框架 React/Vue、在 UI 組件庫、函數庫、網絡庫、異步處理、數據處理等領域也有非常多的優秀沉澱。然而，在生態如此繁盛的今天，前端開發在很多業務、很多公司依舊是最大的人力瓶頸，前端人效提升一直是令人頭大的命題。

究其原因，筆者認爲有以下幾個急需攻克的難題:

1.UI 層 (前端界面) 複用性極差: 前端 UI 代碼大量採用 VM(view + model)的方案，面向多樣化的設計稿進行開發，代碼差異化無法收斂。

2.Data 層 (數據處理) 複用性極差: 服務端通信給前端的數據雖然已經是視圖對象 (view object)，但是仍舊帶有鮮明的領域(Domain) 屬性，數據結構的差異化直接導致數據處理邏輯的複用性無法收斂。

舉個例子。上圖是非常經典的產品展示頁面，然而這 2 個頁面分屬於不同的產品線，開發人員的物理隔離和 UI 上的些微差異性，直接導致彼此可複用的前端代碼是 0%，需要 2 個前端人員才能完成需求。

再深究下。以上前端代碼複用度極差的後果，我們能歸咎於產品、設計、運營等同學嗎？或者說，產品、設計、運營同學，他們難道沒有碰到類似的困擾？多次的重複工作，帶來的效率問題始終是難以迴避的問題。

對於前端開發來說，我想提出一個研發流程上的新概念: 前端領域模型 來解決以上的問題。

Part III 前端領域模型的探討

前端領域模型 (FrontEnd Domain Model): 面向 業務領域 抽象的 UI 模型。

前端領域模型抽象出來後將會對整個研發流程進行一個重構，流程節點將會增加如下藍色區域。

如上圖，研發流程重構後，前端開發中的 「業務 UI」 是面向 「FDO」 進行編程，把業務的個性化轉嫁給了 Adapter，從而達到「業務 UI」複用 (Low Code) 的目的。

在實際開發中，前端同學需要做的就是「選擇合適的業務 UI 模板」 -> 「實現 (implement) 對應的 FDO」即可快速上線一個業務模塊。

這種開發模式解決的最大的問題是軟件開發的持續交付，通過將前端複雜度進行顆粒度的合理拆分，讓每個需求迭代產生的複雜度，從指數級變成了線性。

Before: 業務迭代的複雜度 ≈ ViewModel 的複雜度 = view 複雜度 * Model 複雜度

After: 業務迭代的複雜度 ≈ Model 的複雜度 + View 的複雜度

複雜度的降低帶來的收益，不僅僅是前端效率的提升，更是前端穩定性的提升。

Part IV 進一步開放，甚至商業化？

對於大公司如騰訊、阿里、字節，開放平臺在整個業務體系有着極高的戰略意義。大量的生態 ISV，如何開發出符合要求的應用，最直接的體現就是 前端 UI 的一致性。

藉助如上的研發流程創新，通過制定高質量的前端領域模型 (FDO) 規範，生態 ISV 可以較輕鬆的複用和遵守對應的 UI 開發規範，進行適當的改造即可快速開發出符合要求的應用，不僅僅是成本降低，更是效率的提升。

這裏面的空間，可以想象下，對人力成本的解放有着重要的意義。

Part V 結語

本文是我在實際前端研發流程中，結合團隊的實踐進行的一些思考，算是一個拋磚引玉。

業內關於研發效率中的物料 (Low Code) 已經有非常多的討論和實踐。我嘗試從另一個角度 「前端領域模型」來看待研發流程的調優和標準化。通過 規範化的研發分層 將複雜度進行拆解，已達到 高質量的持續交付。

關於引入的這個新概念 FDO 以及如何在團隊落地，我們已經有一些實踐，證明確實在研發效率上帶來了較好的提升。當然，我覺得還可以有很明確的路徑做得更好。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9B1CqaYbM6l5r5bF3x98FQ

猜你喜歡