編輯導讀：狀態機可以對業務狀態進行梳理，一目了然，之後可以根據業務場景不斷增加。它雖然不是做好一款產品的必備品，但是卻可以讓你在跟技術等人員溝通時效率更高。文章對有限狀態機進行了簡要的介紹，與大家分享。
一、地址的分析和識別
以前每次搬家，要重新寫收貨地址時，我都會特別小心，要去百度地圖上搜一下地址的完整寫法，生怕一不小心寫錯或寫漏了就收不到包裹了（捂臉）。直到某天我看到有限狀態機的原理，才知道我太天真了。
比如騰訊公司在深圳的地址，有如下的各種寫法：
廣東省深圳市騰訊大廈廣東省518075深圳市南山區科技園騰訊大廈深圳市510875科技園騰訊大廈深圳市南山區科技園騰訊大廈廣東省深圳市科技園中一路騰訊公司…這些地址寫得都有點不清楚，那麼程序是如何準確地識別這些信息呢？下圖所示的是一個識別中國地址有限狀態機的例子。
每一個有限狀態機都有一個開始狀態和一個終止狀態，以及若干中間狀態。每一條弧上帶有從一個狀態進入下一個狀態的條件。如果一個地址能從狀態機的開始狀態進過狀態機的若干中間狀態，走到終止狀態，那麼這條地址有效，否則無效。
比如「北京市雙清路83號」對於上面的狀態機有效，而「上海市遼寧省馬家莊」則無效。
二、什麼是有限狀態機
有限狀態機（Finite-state machine）是一個非常有用的模型，可以模擬世界上大部分事物。
它有三個特徵：
狀態總數（state）是有限的。任一時刻，只處在一種狀態之中。某種條件下，會從一種狀態轉變（transition）到另一種狀態。現實世界中存在大量具有有限個狀態的系統：鐘錶系統、電梯系統、交通信號燈系統、通信協議系統、正則表達式、硬體電路系統設計、軟體工程，編譯器等，有限狀態機的概念就是來自於現實世界中的這些有限系統。
下面是一個可樂機的狀態圖。
從圖中就可以清楚地看到可樂機的運行過程，圖中直觀地表現了可樂機投入不同金額硬幣時的情況以及幾個處理步驟的各個狀態和它們之間的轉換關係，根據投入硬幣的不同面值，對總金額進行計算，並對各種操作進行響應以完成一次購買。 狀態機的動態結構使得其在通訊系統，數字協議處理系統，控制系統，用戶界面等領域得到了廣泛地應用。
上圖是非常有名的TCP協議狀態機。這個狀態機我沒看懂，放在這裡拋磚引玉吧。
三、有限狀態機的應用
有限狀態機有多種實現方式
1. switch-case或if-else
舉例來說，網頁上有一個菜單元素。滑鼠懸停的時候，菜單顯示；滑鼠移開的時候，菜單隱藏。如果使用有限狀態機描述，就是這個菜單只有兩種狀態（顯示和隱藏），滑鼠會引發狀態轉變。
當狀態量少並且各個狀態之間變化的邏輯比較簡單時，使用switch語句實現的有限狀態機的確能夠很好地工作，但代碼的可讀性並不十分理想。在很長一段時期內，使用switch語句一直是實現有限狀態機的唯一方法，甚至像編譯器這樣複雜的軟體系統，大部分也都直接採用這種實現方式。
但之後隨著狀態機應用的逐漸深入，構造出來的狀態機越來越複雜，這種方法也開始面臨各種嚴峻的考驗，其中最令人頭痛的是如果狀態機中的狀態非常多，或者狀態之間的轉換關係異常複雜，那麼簡單地使用switch語句構造出來的狀態機將難以擴展和維護。
2. 狀態表
我們還可以用狀態表來表示狀態的轉化過程，以一個遊戲中的簡單設定為例：
這段需求相信大家一眼就可以看明白，現在我們用狀態機來表示，大概是這樣：
看完這個圖，是不是有種似曾相識的感覺。產品經理在做複雜的業務需求時，往往會遇到狀態的變更，一般我們會畫流程圖來表示（比如一個審核流程），偶爾也會用表格的形式來表示（比如內容平臺的發布流程）。
但是我們在做的時候往往沒有考慮過有限狀態機的這種表述方式，或者說考慮得不夠全面，如果用有限狀態機的這種方式，那就是可以直接供測試人員使用的一個測試用例了，想想測試同學雀躍的心情吧。
四、總結
狀態機表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。
通俗的描述狀態機就是定義了一套狀態変更的流程：狀態機包含一個狀態集合，定義當狀態機處於某一個狀態的時候它所能接收的事件以及可執行的行為，執行完成後，狀態機所處的狀態。
狀態機主要的應用場景就是流程控制。一個狀態機定義以後，在某個狀態下就只接收固定的Event，也就是執行指定的操作，這樣流程就能按照預期定義的那樣流轉，不會出現亂入的情況，執行了一些在某狀態下不允許執行的操作。
一個很典型的應用就是工作流引擎：以工作流中典型的審批流程為例，審批流程按照預先定義的流程流轉的固定的某些人手裡，只有這一批固定的人才能審批，當審批後（可能是一個人審批，也可能是多個人審批）才會流轉到下個節點，由下個節點的審批人繼續審批，一直流轉到最後一個節點。
狀態機的流轉可以人工幹預，也可以自動流轉。定義為自動流轉後，把業務流程定義完成後，只要添加一個定時任務，整個流程的運轉就都由狀態機來完成了。
寫到這，只想說一句話，無處不狀態機！
本文由 @CARRIE 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議