無論做業(yè)務需求還是做平臺需求的同學，隨著需求的不斷迭代，通常都會出現(xiàn)邏輯復雜、狀態(tài)混亂的現(xiàn)象，維護和新增功能的成本也變的十分巨大，苦不堪言。下圖用需求、業(yè)務代碼、測試代碼做對比：

圖中分了 3 個階段：

• 階段 1：正常，都是線性增長。
• 階段 2：需求數(shù)正常增長，業(yè)務代碼行數(shù)開始增長，測試代碼行數(shù)大幅度增長。
• 階段 3：業(yè)務代碼行數(shù)開始大幅增長，測試代碼行數(shù)劇增（超出屏幕），而需求數(shù)開始下降。

這可以很好的表達出，從業(yè)務最開始，到長期迭代后，復雜度提升帶來的問題。做一個相同的需求，最開始可能 1 天就可以搞定，但長期迭代后，可能要 3 天，甚至更多，這并不是開發(fā)人員主觀上導致的，而是代碼狀態(tài)的維護成本太高，做到最后經(jīng)常會出現(xiàn)牽一發(fā)而動全身。也側(cè)面抑制了業(yè)務的迭代速度。

所以對于長期迭代的產(chǎn)品，切記不要簡單做，否則都是給后面挖的坑。

當然，看問題還是要去看本質(zhì)。
根據(jù)復雜度守恒定律（泰斯勒定律），每個應用程序都具有其內(nèi)在的、無法簡化的復雜度。這一固有的復雜度都無法依照我們的意愿去除，只能設法調(diào)整、平衡。而現(xiàn)在前端的復雜度拆分主要包括：框架、通用組件、業(yè)務組件和業(yè)務邏輯，如下圖所示：

上圖中可以看到，當把框架和通用組件建設完成后，能夠承擔的復雜度基本穩(wěn)定了，未來無輪再怎么改善或者更換其他框架，也很難再去突破天花板，對業(yè)務的復雜度的改變也微乎其微了（如果你的業(yè)務經(jīng)歷過底層框架更換，你就能體會到它到底對你的業(yè)務復雜度有沒有帶來變化了）。

我們就要去思考，到底哪里還能把復雜度給降下來。換個角度，是不是可以從業(yè)務共有的 “業(yè)務邏輯” 側(cè)去進行突破？
目前發(fā)現(xiàn)的，做業(yè)務側(cè)提效的方案中，很少有從 “業(yè)務邏輯” 視角為出發(fā)點去做的，更多的是聚焦在場景化上的提效。

把視角聚焦到 “業(yè)務邏輯” 側(cè)，這里就要看所有業(yè)務中都會面臨的問題，是什么讓業(yè)務復雜度提升上去了。這里主要存在兩點，如下：

• 代碼層面
  • 各種各樣的業(yè)務狀態(tài)導致的 flag 變量的劇增：即便是自己，寫多了這種變量，也很難清楚的知道每個 flag 是干什么用的。
  • 各種判斷業(yè)務狀態(tài)的 if/else：if/else 嵌套地獄估計在很多大型的業(yè)務產(chǎn)品中都能看到吧。還有內(nèi)部的各種邏輯判斷，如 isA && isB || !(isC || !isD && isE)，完全看不懂，即便問 PD，時間久了她也不知道了。還有因此可能導致一些意識不到的 Bug。
• 協(xié)作層面
  • 做業(yè)務的同學很難有全局業(yè)務視角，所以面對 PD 的需求很難有話語權。如果需求設計不合理，只能等到你做完了，在 UAT 的階段才能發(fā)現(xiàn)，然后 PD 會給你提一個新需求，讓你再去修正（雖然是 PD 的問題，但缺乏避免 PD 犯錯的途徑）。
  • 測試同學，測試的內(nèi)容范圍，多數(shù)情況下，取決于前端同學給定的測試范圍。而很多時候代碼的改動，前端也不確定到底哪些頁面會受影響。所以要么導致測試同學測試不完整，要么導致測試同學需要全量回歸，這可是非常巨大的測試成本。
  • 當其他前端開發(fā)人員，參與到項目中時，面臨這種復雜的項目也是頭大，需要花費很大的成本梳理清楚業(yè)務與代碼的關聯(lián)。導致合作或者交接項目時，困難。

我們需要通過發(fā)現(xiàn)的這些問題，來尋找合適的解決方案。

1. 解決代碼層面的問題

代碼層面的問題，主要來源于 flag 變量過多，及 if/else 的嵌套及大量分支，導致難以修改和擴展，任何改動和變化都是致命的。其實這類問題，在設計模式中是有合適的方案——狀態(tài)模式。

1.1. 狀態(tài)模式

狀態(tài)模式主要解決的是，當控制一個對象狀態(tài)轉(zhuǎn)換的條件表達式過于復雜時的情況。把狀態(tài)的判斷邏輯轉(zhuǎn)移到表示不同狀態(tài)的一系列類當中，減少相互間的依賴，可以把復雜的判斷邏輯簡化。

狀態(tài)模式是一種行為模式，在不同的狀態(tài)下有不同的行為，它將狀態(tài)和行為解耦。

從類圖中可以看到，狀態(tài)模式是多態(tài)特性和面向接口的完美體現(xiàn)，State 是一個接口，表示狀態(tài)的抽象，ConcreteStateA 和 ConcreteStateB 是具體的狀態(tài)實現(xiàn)類，表示兩種狀態(tài)的行為，Context 的 request() 方法將會根據(jù)狀態(tài)的變更從而調(diào)用不同 State 接口實現(xiàn)類的具體行為方法。

狀態(tài)模式的好處是，將與特定狀態(tài)相關的行為局部化，并且將不同狀態(tài)的行為分割開來。這樣這些對象就可以不依賴于其他對象而獨立變化了，未來增加或修改狀態(tài)流程，就不是困難的事了。

當一個對象的行為取決于它的狀態(tài)，并且它必須在運行時刻根據(jù)狀態(tài)改變它的行為時，就可以考慮使用狀態(tài)模式了。

1.2. 狀態(tài)機

狀態(tài)機，全稱有限狀態(tài)機（finite-state machine，縮寫：FSM），又稱有限狀態(tài)自動機（finite-state automaton，縮寫：FSA），是現(xiàn)實事物運行規(guī)則抽象而成的一個數(shù)學模型，并不是指一臺實際機器。狀態(tài)機是圖靈機的一個子集。它是一種認知論。從某種角度來說，我們的現(xiàn)實世界就是一個有限狀態(tài)機。

有限狀態(tài)自動機在很多不同領域中是重要的，包括電子工程、語言學、計算機科學、哲學、生物學、數(shù)學和邏輯學。有限狀態(tài)機是在自動機理論和計算理論中研究的一類自動機。在計算機科學中，有限狀態(tài)機被廣泛用于建模應用行為、硬件電路系統(tǒng)設計、軟件工程，編譯器、網(wǎng)絡協(xié)議、和計算與語言的研究。它是非常成熟的一套方法論。

有限狀態(tài)機包含五個重要部分：

• 初始狀態(tài)值 (initial state)
• 有限的一組狀態(tài) (states)
• 有限的一組事件 (events)
• 由事件驅(qū)動的一組狀態(tài)轉(zhuǎn)移關系 (transitions)
• 有限的一組最終狀態(tài) (final states)

更簡潔的總結(jié)，就三個部分：

• 狀態(tài) State
• 事件 Event
• 轉(zhuǎn)換 Transition

同一時刻，只可能存在一個狀態(tài)。例如，人有 “睡著” 和 “醒著” 兩個狀態(tài)，同一時刻，要么 “睡著” 要么 “醒著”，不可能存在 “半睡半醒” 的狀態(tài)。

邏輯學中說，現(xiàn)實生活中描述的事物都可以抽象為命題。命題本質(zhì)上就是狀態(tài)機的 State，Event 就是命題的條件，通過命題和條件推導過程。而 Transition 就是命題推導完成的結(jié)論。

所以當我們拿到需求的時候，首先要分離出哪些是已知的命題（State），哪些是條件（Event），哪些是結(jié)論（Transition）。而我們要通過這些已知命題和條件，推導出結(jié)論的過程。

1.2.1. 拿我們經(jīng)常用到的 Fetch API 來舉例子

fetch(url).then().catch()

有限的一組狀態(tài)：

初始狀態(tài)：

有限的一組最終狀態(tài):

有限的一組事件：

• Idle 狀態(tài)只處理 FETCH 事件
• Pending 狀態(tài)只處理 RESOLVE 和 REJECT 事件

由事件驅(qū)動的一組狀態(tài)轉(zhuǎn)移關系:

1.3. 狀態(tài)機 VS 傳統(tǒng)編碼 示例

下面采用一個小需求來對比一下區(qū)別。

1.3.1. 需求描述

根據(jù)輸入的關鍵字進行搜索，并將搜索結(jié)果顯示出來。如下圖所示：

1.3.2. 基于傳統(tǒng)編碼

根據(jù)關鍵字拿到請求結(jié)果，再將結(jié)果塞回去就行了，代碼如下：

function onSearch(keyword) {fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {this.setState({ data });}); }

看似幾行代碼就把這個需求搞定了，但其實還有一些其他問題要處理。如果接口響應比較慢，則需要給一個用戶預期的交互，如 Loading 效果：

function onSearch(keyword) {this.setState({isLoading: true,});fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {this.setState({ data, isLoading: false });}); }

還會發(fā)生出請求出錯的情況：

function onSearch(keyword) {this.setState({isLoading: true,});fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {this.setState({isError: true,});}); }

當然，不能忘記把 Loading 關掉：

function onSearch(keyword) {this.setState({isLoading: true,});fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {this.setState({isError: true,isLoading: false,});}); }

我們每次搜索時，還需要把錯誤清除：

function onSearch(keyword) {this.setState({isLoading: true,isError: false,});fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {this.setState({isError: true,isLoading: false,});}); }

這就結(jié)束了么，是不是我們把所有的 Bug 都考慮進去了？并沒有。當用戶在等待搜素請求的時候，不應該再去搜索，所以搜索結(jié)果返回前，禁止再次發(fā)送請求：

function onSearch(keyword) {if (this.state.isLoading) {return;}this.setState({isLoading: true,isError: false,});fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {this.setState({isError: true,isLoading: false,});}); }

可以看到，應用的復雜度在不斷變大，可能你經(jīng)歷的場景比這個小示例還要復雜的多的多。如果因為搜索接口特別慢，用戶希望有一個中斷搜索的功能，那么新的需求又來了：

function onSearch(keyword) {if (this.state.isLoading) {return;}this.fetchAbort = new AbortController();this.setState({isLoading: true,isError: false,});fetch(SEARCH_URL + "?keyword=" + keyword, {signal: this.fetchAbort.signal,}).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {this.setState({isError: true,isLoading: false,});}); }function onCancel() {this.fetchAbort.abort(); }

不能落下對 catch 的特殊處理，因為中斷請求會觸發(fā) catch：

function onSearch(keyword) {if (this.state.isLoading) {return;}this.fetchAbort = new AbortController();this.setState({isLoading: true,isError: false,});fetch(SEARCH_URL + "?keyword=" + keyword, {signal: this.fetchAbort.signal,}).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {if (e.name == "AbortError") {this.setState({isLoading: false,});} else {this.setState({isError: true,isLoading: false,});}}); }function onCancel() {this.fetchAbort.abort(); }

最后還要處理沒有值的情況：

function onSearch(keyword) {if (this.state.isLoading) {return;}this.fetchAbort = new AbortController();this.setState({isLoading: true,isError: false,});fetch(SEARCH_URL + "?keyword=" + keyword, {signal: this.fetchAbort.signal,}).then((data) => {this.setState({ data, isLoading: false });}).catch((e) => {if (e && e.name == "AbortError") {this.setState({isLoading: false,});} else {this.setState({isError: true,isLoading: false,});}}); }function onCancel() {if (this.fetchAbort.abort &&typeof this.fetchAbort.abort == "function") {this.fetchAbort.abort();} }

僅僅這么簡單的一個小需求，從開始幾行代碼就可以完成，到最終判斷各種邊界完成的代碼，對比一下，如下圖所示：

可以看到，這種包含各種 flag 變量和嵌套著各種 if/else 的代碼，會越來越難維護，所有的邏輯只存在于你的腦子里。當你寫測試的時候必須從頭再梳理一遍代碼邏輯，才能寫出來。

由于業(yè)務的高頻變化，很多業(yè)務開發(fā)人員是不寫單元測試的，因為成本太高太高，這也導致了交接代碼時，別人去理解你的代碼是一件很困難的事。寫久了，你自己都可能讀不懂代碼里面的邏輯了。

上面的編碼方式其實有專業(yè)術語的，叫“Bottom-up Approach”。這種方式 從解決問題的最基本層面開始，然后逐步擴展解決方案的多個部分。

這樣會導致：

• 難以測試
• 難以閱讀
• 可能含有隱藏的 Bug
• 難以擴展
• 新功能增加時還會使邏輯進一步混亂

1.3.3. 基于狀態(tài)機

看一下我們用狀態(tài)機的做法。記住流程：梳理出有哪些狀態(tài)，每個狀態(tài)有哪些事件，經(jīng)歷了這些事件又會轉(zhuǎn)換到什么狀態(tài)。

下面是用 XState 狀態(tài)機工具的 JSON 描述：

{initial: "空閑",states: {空閑:{on:{搜索: '搜索中'}},搜索中:{on:{搜索成功: '成功',搜索失敗: '失敗',取消: '空閑'}},成功:{on:{搜索: '搜索中'}},失敗:{on:{搜索: '搜索中'}}}, }

沒錯，就這幾行代碼就描述清楚所有的關系了。并且，可以把它可視化出來，如下圖所示：

可以看到狀態(tài)之間表達的非常清晰，結(jié)合到 View 中，也不需要再去編寫復雜的 flag 及 if/else 了，View 中只需要知道當前是什么狀態(tài)，已及將事件發(fā)送到狀態(tài)機就可以了，其他什么都不需要做。在新增或者修改需求的情況下，只需要對狀態(tài)進行新增或者編排就可以了。

而且可視化后，有以下變化：

• 清晰的看到有哪些狀態(tài)
• 清晰的看到每個狀態(tài)可以接受哪些事件
• 清晰的看到接受到事件后會轉(zhuǎn)移到什么狀態(tài)
• 清晰的看到到達某個狀態(tài)的路徑是怎么樣的

2. 解決協(xié)作的問題

另一個很大的問題是解決協(xié)作問題，主要包括：

• 與測試開人員的協(xié)作溝通
• 與 PD 人員的協(xié)作溝通
• 與其他前端開發(fā)人員的協(xié)作溝通
• 與用戶的協(xié)作溝通

這里就需要引用一個可視化的概念了。
可視化，是利用人眼的感知能力對數(shù)據(jù)進行交互的可視表達以增強認知的技術 。

所以很大程度上，可視化可以解決一大部分協(xié)作問題。當然，必須要確定把什么進行可視化才是有意義的。

要想可視化，狀態(tài)工具就需要具備可序列化的能力。這也是 Redux 之類的狀態(tài)管理工具缺乏的，主要有以下幾方面問題：

• 不具備可視化的能力
• 狀態(tài)和數(shù)據(jù)混在一起
• 所有的狀態(tài)都是平級的，無法描述狀態(tài)之間的關系

2.1. 狀態(tài)圖

回到狀態(tài)機。你單純用狀態(tài)機去寫代碼，需求數(shù)量上去了，狀態(tài)多了，會面臨 “狀態(tài)爆炸” 問題，依然很難維護，且閱讀成本巨大。

當然，這個場景其實很早之前就有人考慮到了，1987 年，Harel 就發(fā)表論文，解決復雜狀態(tài)機可視化的問題，在狀態(tài)機的基礎上進一步增強，提出狀態(tài)圖的概念。隨后，由微軟、IBM、惠普等多家公司，從 2005 到 2015 年花了 10 年時間制定了規(guī)范，并推出了 W3C 的 State Chart XML (SCXML) 規(guī)范，至此基本穩(wěn)定，各家編程語言也基于此規(guī)范進行了狀態(tài)圖的封裝。

看一下，狀態(tài)機、狀態(tài)圖和手寫代碼復雜度的對比，如下圖所示：

從圖中可以看到：

• 傳統(tǒng)編碼方式，隨著狀態(tài)和邏輯的增加，復雜度是線性增長的。
• 使用狀態(tài)機，前期復雜度很底，但隨著狀態(tài)的增多，“狀態(tài)爆炸”現(xiàn)象的出現(xiàn)，復雜度也急劇增長。
• 使用狀態(tài)圖，雖然前期成本略高，但后期的狀態(tài)和邏輯的增長，基本不太會影響它的復雜度。

前面給狀態(tài)機畫的圖，就是狀態(tài)圖。

狀態(tài)圖大概長這樣，如下圖所示：

主要包括：

• 狀態(tài)
  • 原子狀態(tài)
  • 復合狀態(tài)
  • 條件狀態(tài)
  • 最終狀態(tài)
  • 歷史狀態(tài)
  • 初始狀態(tài)
  • 并行狀態(tài)
  • 偽/瞬間狀態(tài)
• 轉(zhuǎn)換
  • 自動轉(zhuǎn)換
  • 延遲轉(zhuǎn)換
  • 自身轉(zhuǎn)換
  • 內(nèi)部轉(zhuǎn)換
• 操作
  • 自定義操作
  • 進入操作
  • 退出操作
  • 數(shù)據(jù)操作
  • 日志操作
• 事件
  • 生成事件
  • 延遲時間
• 條件
• 數(shù)據(jù)
• 調(diào)用

即使狀態(tài)非常復雜，也可以通過狀態(tài)圖的模式進行聚合、分組、細化，還可以通過 Actor 模型進行劃分，不會發(fā)生 “狀態(tài)爆炸” 現(xiàn)象。

2.2. 文檔化

目前對項目需求的描述主要有：

• 產(chǎn)品需求文檔（PRD）
• 設計稿

而這兩個，在描述頁面行為上都不夠細致，PRD 幾乎不會去描述過于細節(jié)的交互行為，設計稿大概率也不會（因為業(yè)務交付周期上不允許在這上面花費太多的時間）。
而對于這些不清楚的、模糊的點，就帶來了后面的問題，針對于這些細節(jié)點，各個角色之間的溝通成本和拉通成本。

還有一個很嚴重的問題，就是同步問題。
很多時候在開發(fā)過程中，進行需求變動，而大多數(shù)情況下，這些變動不會重新對 PRD 和設計稿進行修改，不同角色之間去對焦及未來回顧，都是問題。

而如果你使用狀態(tài)機開發(fā)，那這兩個問題就可以迎刃而解。狀態(tài)機方式，要求你在開發(fā)之前必須把所有可能的狀態(tài)都羅列出來，狀態(tài)之間的關聯(lián)關系必須描述清晰。基于生成的狀態(tài)圖，是可以完全表達清楚所有的狀態(tài)交互及變化，且它是來源于代碼的，所以它是實時同步的，你代碼中怎么運行的，這個狀態(tài)圖就是怎么表達的。

2.3. 角色影響

回到前面說的，與不同角色協(xié)作的問題上。有了狀態(tài)圖的加持，會發(fā)生什么變化：

• 設計師可以根據(jù)狀態(tài)圖中的不同狀態(tài)，來確定哪種狀態(tài)合適用什么樣的 UI。
• 對于 PD，可以查看狀態(tài)圖，以了解系統(tǒng)行為，并驗證是否滿足要求。
• 對于測試和用戶，狀態(tài)圖完全充當說明書用，以前不知道如何才能到達某個狀態(tài)，現(xiàn)在一目了然。
• 對于測試還有一個很大的區(qū)別，因為基于狀態(tài)機去寫的，所以可以使用 Model-Based Testing，而這部分測試，可以由某些狀態(tài)機工具自動化掉。
• 對于交接的前端開發(fā)來說，有說明書在手，每個狀態(tài)都十分清晰，能做的事也十分清晰，在具備狀態(tài)機基礎的情況下，是可以快速上手的。

2.4. 提升用戶體驗度：用戶操作鏈路追蹤和分析

除了解決復雜度的問題，基于狀態(tài)機的特性，還可以帶來一些新的思路，如用戶操作鏈路追蹤和分析。

2.4.1. 常見分析用戶操作鏈路方法

目前，針對于分析用戶操作鏈路的方法，主要是在頁面中的可操作標簽上進行埋點，如，Button、Tab Item 等。有手動埋點和自動埋點。

• 手動埋點，可以按照你的意愿來收集特定區(qū)域的操作數(shù)據(jù)，但成本偏高，需要一個一個的手動接入，還可能需要自行上報數(shù)據(jù)。
• 自動埋點，通常是自動在一些常用的標簽上埋點，但會存在具體的標簽變更的問題，且不能覆蓋所有可操作的區(qū)域，數(shù)據(jù)精度不夠。

無論使用哪種埋點，都存在 回放噪音 的問題。

如，上報信息里包含，“查看詳情” 按鈕的操作，那么對應的 “詳情對話框” 一定會出來么？這個時候鏈路回放，只能去猜測，認為點擊了這個按鈕，就意味著這個對話框出來了。其實是不準確的。

如果，頁面上新增加了一個功能，要判斷這個新功能用戶的使用量，及用戶做了哪些操作才找到這個新功能。通過這個數(shù)據(jù)來判斷新的交互設計是否存合理。在這種不精準數(shù)據(jù)及 “噪音” 的回放中也是不準確的。

同樣，分析頁面中的哪些部分是高頻操作，也有類似的問題。

2.4.2. 基于狀態(tài)機的鏈路分析方法

狀態(tài)機做這種用戶鏈路分析，是天然合適的。因為用戶的所有操作，所有行為，本質(zhì)上就是 “狀態(tài)在接收了什么事件，要變換到什么狀態(tài)” 上的過程。這是在 View 上埋點的方式缺乏的。

我們只需要在每次 “狀態(tài)” 發(fā)生轉(zhuǎn)換時，把狀態(tài)圖數(shù)據(jù)上報到分析平臺就可以。完全可以基于狀態(tài)的方式， 1:1 的回放用戶操作鏈路。

3. 總結(jié)

最后，總結(jié)一下狀態(tài)機方式帶來的好處和不足。

3.1. 優(yōu)勢

• 比傳統(tǒng)的編碼方式，更容易理解。
• 基于行為建模，與視圖解耦。
  • 更容易改變行為：組件中的行為被提取到了狀態(tài)機中，與 把行為和業(yè)務邏輯一起嵌入的組件相比，行為的更改相對容易。
  • 更容易的理解代碼。
  • 更容易測試
• 構(gòu)建狀態(tài)圖的過程必須探索所有狀態(tài)，也是讓你具備業(yè)務全局視角的過程，它迫使你考慮所有可能發(fā)生的場景。
• 基于狀態(tài)圖的代碼比傳統(tǒng)代碼具有更少的 Bug 數(shù)。相關數(shù)據(jù)表示，錯誤減少了 80% 到 90%，剩下的錯誤也很少出現(xiàn)在狀態(tài)圖本身。
• 有助于處理可能會被忽視的特殊情況。
• 隨著復雜性的增加，狀態(tài)圖可以很好地擴展。
• 狀態(tài)圖是一個很好的交流工具。

3.2. 帶來的一些問題

• 需要學習新的東西，狀態(tài)機是一種范式的轉(zhuǎn)化，且容易有抵觸心里，不愿意走出舒適圈。
  • 新的格式
  • 新的重構(gòu)技術
  • 新的調(diào)試工具
• 部分人覺得可視化這種東西，沒什么用。
• 陌生的編碼方式，在團隊內(nèi)可能出現(xiàn)不同的阻力。
  • 雖然大多數(shù)人聽過狀態(tài)機，但實際的編程中離它遙遠，所以并不熟悉它。
  • 編程方式的轉(zhuǎn)換，很多人需要弄清楚原來的代碼，現(xiàn)在該如何去寫，如何映射。
  • 部分人會質(zhì)疑它的有效性。
  • 必須有人基于這種模式實踐過，對它非常了解才可以。
  • 如果從來沒用過它，使用這種模式會無從下手，令人生畏。

3.3. 為什么用的人不多

狀態(tài)機已經(jīng)發(fā)展幾十年了，前面也說過，在非常的多場景有使用，像電子、嵌入式、游戲、通訊等領域。那為什么前端上使用較少呢（限定國內(nèi)）？

除了上面列出的 “帶來的一些問題” 中的一些點，我覺的還有以下問題導致的：

• 缺少指導圖書：現(xiàn)在搜索一下關于狀態(tài)圖的前端圖書或者教程，搜索結(jié)果告訴你 0 條。資料很少（嵌入式之類的狀態(tài)機資料還是挺多的）。
• “用最簡單的方式去實現(xiàn)” 的心態(tài)：很多人喜歡用 if/else/switch 來解決問題。
• “你覺得你不需要” 的心態(tài)：復雜度在每一個 flag 變量和布爾值中蔓延。就像溫水煮青蛙，溫水中的青蛙不會注意到溫度的緩慢升高一樣，開發(fā)人員也不會注意到復雜度的蔓延。在一些小的系統(tǒng)中運行的很好，但隨著系統(tǒng)的迭代和變大，一個個凌亂的 if/else/switch 語句，它修改了各種變量的狀態(tài)，以試圖維持它們的一致性。就好像你不需要狀態(tài)機，直到為時已晚。
• 就像 RxJS、函數(shù)式編程之類的一樣，大家都知道它很好，但就是不用它。

3.3. 總結(jié)

任何解決方案都不能解決一切問題，一定要找到它適合的場景。不過，現(xiàn)階段，狀態(tài)機確實是我能看到的，解決復雜業(yè)務邏輯最好的工具。

如果文中說的問題也發(fā)生在你身邊，且無法徹底解決，那推薦你可以嘗試一下，或許會有驚喜。

總結(jié)

以上是生活随笔為你收集整理的降低前端业务复杂度新视角：状态机范式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。