我們是否對現代前端開發框架過於崇拜了？

 前端界有兩個“教派”，一個叫 Vue，一個叫 React。Vue 的成員看不起 React，React 成員鄙視 Vue，他們認為手中的“教義”就是真理，可以消滅世界一切苦難。但正如沒有絕對的真理，也沒有絕對完美的系統框架，我們需要一雙明辨是非的眼睛去解析所面對的難題，帶我們找到正確的方法，解決所面對的困難。我們需要抱著懷疑的眼光去看待現代前端開發框架，它們真的能解決我們的問題嗎？答案是肯定的，也是否定的。框架並不能獨立的發揮作用，其中開發者是一個很大的變數，而開發者這個最大的變數才是最終影響問題是否能夠被解決的重要因素。
本文從對現代前端框架的“崇拜”現象，引出了前端開發麵臨的過於強調工具本身，忽視了開發者怎麼寫好代碼才是影響代碼質量的本質問題，最後給出了一種我認為可解決業務型前端項目的代碼架構方案（也可以說是一種開發思想），希望能給大家帶來一些思路和幫助。

一、前端開發的困境

從我的經歷來看，現代前端框架的‘崇拜’導致前端開發變得更加複雜，間接導致代碼質量變差，軟體的生命周期變短。當前我們所面臨的困境是技術方案有的時候用的特別順手、高效，而有的時候卻很蹩腳、處處碰壁？有的人用著輕鬆歡快，而有的人用著煩躁不已？有的項目引入了新工具開發效率一下子就上去了，有的項目反而變得越來越複雜難以迭代？究其原因是因為我們一直在追求一種足夠簡單、足夠高效、足夠快、足夠應對複雜變化的業務場景的完美的技術方案。這已經成為了一種前端界的主流意識，每一種新框架、工具的出現都打著比前者更出眾，更牛的口號，給我們一種感覺，好像用了它，那麼一切問題就迎刃而解。但這樣的“神器”真的有嗎？我是持懷疑態度的，軟體開發是一個複雜的系統過程，這是一個開放式的問題，想用一種 “封閉式” 的方案來解決這個問題是違背真理的。
現代前端開發框架就面臨著這個問題，我們有點 “小題大作” 了，妄想用框架來解決一切問題忽略其本質解決的是視圖層渲染的問題。隨著 React/Vue 等數據驅動 UI 框架的流行，它好像成為了我們手中的一個 “神器”，好像用它可以解決開發中的一切問題。而事實上也是這樣的，如果發現有的問題沒有解決好，那麼就圍繞著這些框架擴展新工具就好，所有我們有了 React 全家桶、有了 Vue 全家桶。這樣還不夠，我們還有眾多的工具庫可自由組合使用，分不清的數據狀態管理庫、多種路由跳轉方案、豐富的組件集合、各種開發調試工具、二次封裝的全棧框架等。看似情況越來越好，一切欣欣向榮，幸福的彼岸就在眼前。事實是我們的開發者一直在負重前行，我們的系統變得很複雜（複雜到個人乃至一個團隊都沒法去掌控），我們不敢想五年後是否還能運行起來？
工具可以帶來提效，可以讓工作變得更精細，但影響成品質量的至關重要因素是使用的方式而不是工具本身。對於前端框架，我們要認識到其本身是用來解決視圖層問題的，當我們妄想用框架來解決所有問題的時候，就已經走進了誤區，忽略了本質問題。

二、這是“現代前端開發框架”的鍋？

前文我表達了“從我的經歷來看，現代前端框架的‘崇拜’導致前端開發變得更加複雜，間接導致代碼質量變差，軟體的生命周期變短。” 這裡並不是說是現代前端框架造成了這一系列的問題，事實上我非常認可前端框架給前端開髮帶來的變革，它解決了我們開發界面過程中繁瑣的 DOM 操作問題；帶來了便捷的組件式的代碼復用共用機制；這是一種正向的技術進步。問題的本質是社區帶來的 “崇拜” 文化，這是運行機制帶來的問題，前端框架只是其中某個重要的節點，我們不能因為工具沒有使用好就怪工具本身。

1. 為什麼好的東西會變“壞”？

有一個比較普適的做事原則是 “小事做大，大事做小”。而在前端框架這一塊犯了一個錯誤，過於強調 “小事做大”，也可以說是 “小題大作” 了，大和小是相對的，我們現在妄想用 React/Vue 這一套方案解決整個前端開發的問題，這就是好的東西會變 “壞” 的原因。我在比較早期的時候就接觸了 React/Vue 這一類的框架，老實說當時是很驚艷的，那時的它們有很明確的定位和解決問題的邊界，它們是很純粹的視圖層工具庫（那時還沒有提到框架的概念），簡潔優雅。但隨著它們的不斷迭代和社區的推波助瀾，逐漸的走向了一條不確定的道路，越來越多的衍生工具，越來越多的概念。我承認這些東西有其優秀的地方，但好的東西並不是萬能的東西，需要適合的方法用在合適的地方，否則就變成了“惡”。

2.  框架的快速發展和開發人員緩慢吸收矛盾

軟體開發是一個複雜的系統構建過程，這裡開發人員永遠是最大的變數，前端界面對的問題就是技術方案短時間內的急速發展，1% 的創造者理論提出者，10% 的參與人員將方案推向市場，而大部分的開發者處於一個被動接受和使用的角度。這個過程會導致方案推廣出現信息丟失、帶來誤差、引出變種方案。同時也可能會給於框架維護者帶來負向的反饋，帶來缺陷。技術 “宗教” 或者說過於對某一項技術的 “崇拜” 會加速新技術推向市場的過程，推廣的過程中會出現曲解、模糊。這其中有的是無意的，有的則是故意的。這些在現代前端框架中就出現了，因為這個不健康的成長現象導致了框架的使用被推到極端，而開發者們很可能還沒有建立起敏銳的技術敏感度和判斷能力，導致出現整個前端看似蓬勃發展，但大家卻痛苦不堪的現象。

三、破除困境的方法？

1. 好的東西可能會變 “壞”，壞的東西也可能會變 “好”

好心可能會辦壞事，壞事也可能帶來出乎意料的好處。這其中發揮作用的因素之一就是做事的人這個大 “變數”。為了讓事情辦好，我們需要培養起一個技術能力高的團隊，開發者們都有意識的去關註代碼質量，關心技術架構，思考寫出更好的代碼。這是一個最原始最有效的辦法，當然這也是最難，成本最高的方案。

2. 建立擁有正向反饋能力的運行機制？

機制是一個很強大的東西，甚至能彌補影響因素帶來的負面問題。對於一個複雜系統來說，機制的作用是要大於單個因素的，機制可以調節單個因素造成的誤差，但單個因素卻很難影響整個運行機制。
怎麼建立良好的運行機制我還沒有思考出好的辦法，有想法的同學可以一起交流。雖然還沒有找到建立的方式，但我認為這是一條正確的路，值得去探索。

3. 有效訓練，代碼是“寫”出來的？

做為一個開發者，我發現有兩件事情基本上每天都會做，一不停地寫代碼、二是持續性的學習。按理來說，每天都在寫代碼，按照一萬小時定律，我們的編碼水平應該會不斷提升才對，但現實是好像有一條邊界，當我達到那條邊界後就停滯不前。有變化的持續性行為才可能會出現由量變到質變的突破，長期的無效練習不然短期的有效訓練。看了許多書籍、文章，聽了很多分享、講座，評了很多方案，用了很多新技術。但都會有一種淺嘗輒止的感覺，難道勤學不能帶來成長？

• 再多的信息也不等於知識，經由我們自己的思維轉換並以自己的理解方式吸收的才是自己的知識，將知識應用結合到日常工作中的才算是個人的能力

• 人的思考能力是有限的，而現實現象是一個複雜多維度的系統，遠超個人所能掌控的極限。正確的做法應該是由小到大，深入挖掘單個維度的現象，最後通過有序的方式組合起來就是一個複雜多維度的系統。

四、我們需要合適的代碼架構方案？

我設計過許多底層框架工具，如果要說其中最困難的地方在哪，那就是框架設計者必須考慮到框架本身和使用的開發者間的對立關係（框架和開發者是一個資源爭奪的關係，他們爭奪的是軟體中的計算量，或者簡單的說是代碼量）。處理好這種關係，讓它達到一個動態平衡的過程是設計者要解決的本質問題。

這裡我將介紹一種架構方案，該方案在前端框架的基礎上進行了延伸，有效的解決了業務型（業務邏輯比較重）前端類需求的複雜度問題。

該方案目前還是理論設計和驗證階段，還沒有在真實業務中落地，大家可以帶著辯證的眼光來看待。
若認可該方案，可以互相交流；若不喜，請勿噴。

三是一個很好的數字，我認為一個架構方案能夠解決好三個系統性問題就可以算是一個優秀的方案，而這裡介紹的方案則圍繞如下三個原則而來。

• 分層
• 組合

• 單向依賴

在大的層面藉助分層的思想將事情分類隔離開，每一層直接通過介面聯結工作，降低整個系統的複雜度。比如客戶端就不用關心後端介面的具體實現，只要介面如預期工作就好。在每一層的實現中則可以通過模塊組合的形式最終得到完整的功能。因為前端具有高頻變化的特性，所以更建議使用組合而不是面向對象繼承的方式來組織代碼邏輯，繼承的模式應該更適用於穩固的結構。分層分模塊之後，需要通過線連接起來才能得到一個完整的應用，單向依賴可以避免得到一個無序的網狀結構導致邏輯難以理順。在思考上面提到的三個原則的過程中，我發現現存的 MVP 架構模型就很好的做到了，基於 MVP 架構做一點優化就得到了我認為好的一種架構設計。關鍵的問題還是我們怎麼和自己的開發思維、業務特性結合起來的問題。除了架構原則方面，我們再分析一下代碼編寫本質的東西，什麼原因會導致代碼質量變差？以及如何去解決？

1. 什麼原因會導致前端代碼變差？

前端開發中一個比較核心的問題是視圖的開發，這個問題被框架有效的解決了，當不用去直接操作 DOM 後，開發體驗得到了極大的提高。但存在的問題或者說帶來的一個誤導是視圖的開發就是全部，所以我們變成了組件式編程，帶來的後果就是所有的代碼聯繫過於緊密。我認為以視圖為中心的代碼組織模式會隨著迭代的進行導致代碼越來越混亂，而且邏輯代碼與視圖層耦合會導致所有的代碼如同一碗麵條一樣雜亂不開。

• 視圖是變化頻率比較高的，以視圖為中心的代碼組織方式就如同以視圖作為房子的底座去建房，導致的結果就是每次視圖變化了你就需要費很大的勁去調整房子的其它部件以適應底座的變化，所謂牽一發而動全身正是如此。

• 以視圖作為代碼主體還有一個問題就是視圖不能完整的反應業務需求，有部分的業務邏輯是與視圖無關的。隨著業務邏輯的比重越大就會出現頭重腳輕的現象。

• 數據狀態管理工具可以解決業務邏輯變重的問題嗎？我認為是否定的，數據狀態管理工具並沒有脫離視圖框架的本質，只是將組件內的局部狀態管理模式轉換為了全局狀態管理的模式。類似於有了一個中心的倉庫放置閑置的物品，並不會降低管理物品的難度，關鍵的地方應該在於一套科學合理的閑置物品分類管理方案，將雜亂無章的巨型倉庫變成物美一樣的大型超市。

基於上述分析，我認為的一個解決之道就是要將視圖層獨立出來，視圖與邏輯隔離，實現動靜分離。

2. 前端的主要關註點是什麼？

前面說了以視圖為中心的前端代碼組織方式存在弊端，那麼好的方式應該是什麼呢？回歸業務的本質，以業務為中心，視圖只是業務流程的界面表現方式。UI 是一個單純的東西，我覺得不能算是業務邏輯，前端中的業務邏輯應該是業務流程與界面的聯結表現，這裡有一個主輔的區別。做為前端的你是否也曾有過疑問，有時候前後端的邊界不是很清晰，有的功能可以端上做，也可以在服務端做。客戶端和服務端的對立也影響著客戶端技術的發展，從而保留著服務端的影子。思考一個問題，如果前端摒除了視圖部分，那麼前後端的代碼還會有什麼區別呢？這麼想著將後端那一套長期穩定的架構帶到前端也不是不可能。MVC/MVP 架構是在後端開發中比較成熟的方案，我認為應用到前端也是可行的， 關鍵是要和前端現有的技術方案結合起來。

3. React Hook/Vue Composition API 帶來的開發思維轉變？

React Hook 不僅僅是對 Class 組件的替代，Vue Composition API 也不僅僅是 Options API 的語法升級，我覺得是更本質的編程思維上的改變。
以如下的 swr 示例代碼為例：

function useUser(id) {
  const { data, error } = useSWR(`/api/user/${id}`, fetcher)

  return {
    user: data,
    isLoading: !error && !data,
    isError: error,
  }
}

從上面我們可以看到 useSWR的引入就如同引入一個普通的 util函數一樣，這裡考慮的不是組件初始化的時候做什麼？組件刷新的時候做什麼？而是純粹的思考數據的變化流程，即變成計算的問題。這其實也是一種視圖與邏輯層分離的思想，將業務邏輯聚焦到了 useSWR hook 中（包含了請求、載入中間態、錯誤太的處理）。但可惜的是目前 hook 並不完美，還存在如不可在條件式語句中使用、重覆渲染的問題。Vue Composition API 的目前也還沒有成為主流方式，一切都還在摸索中。社區上已經有眾多基於此的數據狀態更新方案，我相信，未來會出現更多基於此的前端代碼架構方案。

4. 以業務邏輯為核心的架構方案 - （A）

該方案暫以 A 命名，A 方案的適用場景是中型的頁面為主，拆分出來的子模型、子邏輯模塊在不超過 20 個，看起來不多，其實已經滿足了大部分頁面的開發需求。

如果與上述場景不匹配在需要基於 A 方案調整，主要在於每一層內部的有序組合方案問題，以及各層間通信方式的優化。
如果發現數據層邏輯層過大可考慮直接上 DDD。面對複雜場景，與沒有架構指導相比，採用了非理想的架構方案情況也會更好。

4.1. 基於 MVP 模型的演進架構介紹

1. 各部分之間的通信，都是雙向的。

2. View 與 Model 不發生聯繫，都通過 Presenter 傳遞。

3. View 非常薄，不部署任何業務邏輯，稱為"被動視圖"（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那裡。

我們可以拓展為如下分層架構（保留 MVP 的優點）

• 基於 MVP 的分層架構（理解好分層的邊界是分層方案是否有效的重要因素） 

• 數據層（Model）- 業務邏輯依賴的數據實體（可參考 DDD 實體的定義）

• 邏輯層（Presenter）- 處理業務邏輯

• 視圖層（View）- 處理前端的界面交互

• 每一層基於組合的方式構成完整功能 

• 數據層由多個子模型組合而成

• 邏輯層由多個子邏輯模塊組合而成（由組合成的主邏輯模塊與其它層交互）

• 視圖層由多個組件組合而成

• 單一的依賴關係降低耦合度，流程更清晰

4.2. A 方案的一些弊端分析

首先是分層架構帶來的判斷力需求，真正實踐的時候就會發現邊界變得模糊，不知道代碼該寫在哪一層，這是極有可能發生的。對於這種情況，我認為可以按照先求 “完成”，再求“完美” 的方式來走，用實踐來積累正確合理的適合自己團隊的方式。

其次是過渡抽象，這也是大多數方案存在的，有時候顯得明明可以一步到位的事情非要循規蹈矩。

把大象裝到冰箱需要幾步：

1. 打開冰箱
2. 大象走進冰箱
3. 關閉冰箱

也可以一步到位，大象自己走進冰箱。

從上述的例子來看，沒什麼毛病，但現實系統會更複雜，可能完整的步驟多餘 10 步、涉及多個參與對象、參與對象間可能有交互，那麼按照嚴格的指導手冊一步步來就很有必要。最後就又變成了業務場景具體分析的問題，與架構方案是否匹配。如果評判標準難以統一，評判成本過高，即沒法輕易的下結論是否適合用？好像不用也行？用也 OK？如果沒有明確的原因說明不必要採用，那麼我建議是直接使用好了，否則無需採用。
另一個負面影響則是框架成本（研發成本、維護成本、推廣成本、業務接入成本）問題，這是避免不了的。

五、總結

• 現代前端開發框架的出現引領了前端界的變革，但我們不能過於“崇拜”它，它主要解決的是複雜交互開發的問題，在用於開發業務邏輯複雜的需求上並不完美，可以將其當做純視圖層的解決方案。
• 沒有絕對完美的技術方案，這裡面涉及太多的影響因素，開發者是其中的一個大的 “變數”，具備良好架構思維的開發者編寫出的代碼也許就是好的代碼，本身就是一種技術架構方案的反饋。而技術方案的設計產出則是追求的一種普適、易用的方案。

• 設計普適的通用技術方案要由小到大，再由大到小；追求解決核心問題而不是全量的問題，平衡好和開發者間的對立關係；可接受範圍內的負面成本並不影響整個方案的決策。

六、示例

下麵是一個偏真實的代碼架構拆分示例：

如上述示例圖，我們需要獲取商品數據然後以列表的形式展示到頁面上，按照 A 方案，我們可以對該功能做如下的拆解。

1. 常規寫法偽代碼：

export default class PortalPage extends Component {
    registerModels () {
        return [
            {
                namespace: 'PortalGoodModel',
                state: {
                  pageNum: 1,
                  pageSize: 10,
                  hasNextPage: true,
                  goodsData: []
                },
                reducers: {
                  updateGoodsData (state, payload) {
                    // 更新數據操作
                  }
                }
              }
        ]
    }
  
    state (state) {
        return {
          ...state,
          // 是否有數據，純 UI 內部狀態
          noResultPageVisible: state.PortalGoodModel.goodsData.length
        }
    }
  
    ready () {
        this.getPageData();
    }

    async getInfo () {
        const locationInfo = await this.dispatch({type: 'PortalLocationModel/updateInfo'})
        return locationInfo;
    }

    async getPageData (type) {
        const { adCode, userAdCode, longitude, gpsValid } = await this.getInfo();
        
        if (!(adCode && userAdCode && longitude) || !gpsValid) {
            // 定位失敗
            if (type === 'onErrorRetry') {
                utils.toast('請開啟定位');
                this.dispatch({
                    type: "PortalLocationModel/updateLocationStatus",
                    value: 'error'
                })
            } 
        } else {
            this.dispatch({
                type: "PortalLocationModel/updateLocationStatus",
                value: 'success'
            });
            const requestParams = utils.getRequestParams({
                pageData: this.$page.props,
                location,
            });
    
            const res = await fetch(requestParams);
            if (res.code !== 1) {
                // 請求錯誤處理
            } else {
                const result = this.processResult(res);
                this.dispatch({
                  type: 'PortalGoodModel/updateGoodsData',
                  ...result
                });
            }
        }
    }
}

觀察上面的代碼我們會發現 getPageData中柔和了數據模型操作、業務邏輯、視圖的代碼。這裡已經是簡化的，真實的業務會有更多邏輯以非線性的結構交叉在一起，複雜度會在不知不覺中提升。

2. A 架構拆分偽代碼

2.1 模型層示例

構建如下的商品模型，模型層與邏輯層的本質區別就是模型層是更原子的數據操作，可類比後端的資料庫，或者領域模型中的實體抽象定義。邏輯層會依賴模型層已構成完整的業務邏輯，而模型層是獨立的，不會依賴邏輯層的任何東西。

// 這裡使用 dva 做為建模工具，你可以用其它的狀態工具或者純 js 對象都可以
export default {
  namespace: 'PortalGoodModel',
  state: {
    pageNum: 1,
    pageSize: 10,
    hasNextPage: true,
    goodsData: []
  },
  reducers: {
    updateGoodsData (state, payload) {
      // 更新數據操作
    }
  }
}

// 該 presenter 會與視圖關聯，提供給視圖使用的介面
// PortalPresenter.js
export default class PortalPresenter {
    getPageData (obj) {
        // 獲取地理位置信息是 PortalLocationPresenter 做的，而拿到地理信息後
        // 該怎麼去用則是另一個模塊的事情
        this.$PortalLocationPresenter.onLocation({
            success: () => {
                this.$PortalGoodsPresenter.fetchData(obj)    
            }
        })
    }
}

這裡值得說明的是，前端開發的同學可能更適應交互模型的思維（與界面的接近度高），所以這裡並不強制建立一個獨立的子模型，與代碼物理上的隔離相比，我覺得邏輯上的隔離更有必要。

2.2 邏輯層示例

邏輯層與視圖層的邊界判斷標準是該狀態是否在業務邏輯中需要，若需要則應該在模型層建模，在邏輯層編寫依賴邏輯，視圖層轉換為渲染需要的 UI State

• 提供 getPageData介面給視圖層使用

• 拆分出獲取地理位置和獲取商品數據的子邏輯模塊

• 子邏輯模塊之間、邏輯層與視圖層之間以介面的形式通信

如下為核心邏輯模塊，該模塊負責與視圖間的通信交互：

地理信息處理模塊：

// PortalLocationPresenter.js
export default class PortalLocationPresenter {
    async getInfo () {
        const locationInfo = await this.dispatch({type: 'PortalLocationModel/updateInfo'})
        return locationInfo;
    }

    async onLocation (obj) {
        const { adCode, userAdCode, longitude, gpsValid } = await this.getInfo();
        // 定位失敗
        if (!(adCode && userAdCode && longitude) || !gpsValid) {
            this.dispatch({
                type: "PortalLocationModel/updateLocationStatus",
                value: 'error'
            })
            obj?.fail();
        } else {
            this.dispatch({
                type: "PortalLocationModel/updateLocationStatus",
                value: 'success'
            })
            obj?.success();
        }
    }
}

如下為處理商品數據邏輯的子模塊：

export default class PortalGoodsPresenter {
    name = 'PortalGoodsPresenter'
    async fetchData (obj) {
        // 請求參數處理
        const requestParams = utils.getRequestParams({
            pageData: this.$page.props,
            location,
        });

        const res = await fetch(requestParams);
        if (res.code !== 1) {
            obj?.fail()
        } else {
            const result = this.processResult(res);
            this.dispatch({
              type: 'PortalGoodModel/updateGoodsData',
              ...result
            });
          obj?.success();
        }
    }
}

2.3 視圖層示例

• 做純 UI 的渲染操作，回歸 ui = fn(state)的本質

• 視圖層使用邏輯層提供的獲取數據介面去拿到數據

• 獲取非同步數據過程中涉及的 UI 操作依然在視圖層處理 

• 如定位失敗的 toast 提示

• 如是否顯示空數據的 UI （該 UI 邏輯層永遠也用不到）

{
  state (state) {
    return {
      ...state,
      // 是否有數據，純 UI 內部狀態
      noResultPageVisible: state.PortalGoodModel.goodsData.length
    }
  }
  ready () {
    this.getPageData();
  },
  getPageData (info = {}) {
    this.$presenter.getPageData({
      type: info.type,  // 獲取數據類型
      fail (errorInfo) {
        if (errorInfo.type === 'locationError') {
          // from 代表調用類型
          if (info.from === 'onErrorRetry') {
            utils.toast('請開啟定位');
          }
        }
      }
    });
  }
}

拆分後的代碼會更聚焦，每一層做的事情隔離開，依賴關係也會更清晰。

作 者 |  楊勝福(華華)

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Do-we-worship-the-modern-front-end-development-framework-too-much.html