摘要：代碼只是狀態(tài)機(jī)圖的相關(guān)元素的一種表現(xiàn)形式，它與節(jié)點(diǎn)式或表格式的狀態(tài)機(jī)圖并無本質(zhì)不同。如上，狀態(tài)機(jī)是防止代碼失控的一劑良藥，制備完善的狀態(tài)機(jī)圖就是防止代碼失控的一種有效手段。

前幾天和某某同學(xué)吃飯席間，他聊到每當(dāng)要修改老項(xiàng)目中自己寫的代碼時就痛苦不堪，問我是不是也有同感。我覺得這應(yīng)該是不少程序猿的心聲，之所以會這樣，大致有兩個主因：

項(xiàng)目的整體設(shè)計(jì)很糟糕，只管往上堆砌各種功能、補(bǔ)丁，對于代碼質(zhì)量和結(jié)構(gòu)關(guān)系基本無暇顧及，最終積重難返滑向失控。

對技術(shù)缺乏必要的敬畏心，基礎(chǔ)不夠扎實(shí)、知識面較窄，不能（無法）進(jìn)行合理的規(guī)劃，最終導(dǎo)致停留在低水平的代碼堆砌上，只求完成功能就萬事大吉。

程序猿飯桌上總少不了對產(chǎn)品經(jīng)理的吐槽：“產(chǎn)品經(jīng)理又對業(yè)務(wù)流程進(jìn)行了瘋狂調(diào)整，我覺得這會導(dǎo)致狀態(tài)機(jī)無法支持了?！彼倪@個槽點(diǎn)讓我一時有些語塞，倒不是懷疑產(chǎn)品經(jīng)理的腦洞還能大到把狀態(tài)機(jī)開到失控，只是詫異難道我們還有比狀態(tài)機(jī)更適合應(yīng)對業(yè)務(wù)流程變更的武器嗎？

事實(shí)上狀態(tài)機(jī)對于軟件工程師來說應(yīng)該是個很基礎(chǔ)的知識點(diǎn)，它原理簡單卻擁有強(qiáng)大的適應(yīng)力并被廣泛應(yīng)用（譬如：游戲開發(fā)、工作流、編譯器、正則表達(dá)式等解析器），掌握好它的原理和應(yīng)用，能幫助我們從容應(yīng)對很多棘手問題，它于程序猿應(yīng)對復(fù)雜流程性問題，就好比醫(yī)生使用抗生素應(yīng)對細(xì)菌感染一樣的最佳武器。同時，它還是防止代碼失控的一劑良藥。

狀態(tài)機(jī)一般泛指“有限狀態(tài)機(jī)(Finite State Machine)”，《離散數(shù)學(xué)》中有關(guān)于它的專門章節(jié)，以下謹(jǐn)為我對相關(guān)概念的形式上的非精準(zhǔn)釋義，如有出入請以教科書或相關(guān)學(xué)術(shù)資料為準(zhǔn)。

狀態(tài)：顧名思義表示某個時刻系統(tǒng)處于一個特定的階段。通常我們不考慮中間態(tài)，也可以把中間態(tài)進(jìn)行退化處理。當(dāng)狀態(tài)發(fā)生變更，就叫狀態(tài)轉(zhuǎn)換(Transfer)或狀態(tài)遷移(Transition)。

事件：驅(qū)動系統(tǒng)進(jìn)行狀態(tài)轉(zhuǎn)換/遷移的源，提供這種源的也常被稱為“觸發(fā)器(Trigger)”。

行為：當(dāng)系統(tǒng)進(jìn)行狀態(tài)轉(zhuǎn)換時進(jìn)行的響應(yīng)處理，提供響應(yīng)處理的程序也常被稱為“處理器(Handler)”。

有了上面的基本概念，我們來看一個最簡單的狀態(tài)圖：

你可能會奇怪這個圖怎么跟網(wǎng)上那些狀態(tài)機(jī)圖不一樣，連狀態(tài)轉(zhuǎn)換條件都沒有呢？這是因?yàn)?，我覺得在了解狀態(tài)機(jī)之前，最好先確立以下兩種概念：

狀態(tài)驅(qū)動：狀態(tài)機(jī)負(fù)責(zé)根據(jù)輸入來驅(qū)動狀態(tài)流轉(zhuǎn)。

遷移判定：在狀態(tài)流轉(zhuǎn)過程中確定當(dāng)前狀態(tài)是否需要進(jìn)行轉(zhuǎn)換/遷移，以及轉(zhuǎn)換/遷移到哪個狀態(tài)中的判定機(jī)制。

所以，在常見的狀態(tài)機(jī)圖中標(biāo)注的那些狀態(tài)轉(zhuǎn)換條件只是“遷移判定”的一種具體表現(xiàn)形式，它即可以由狀態(tài)機(jī)內(nèi)置，也可以是獨(dú)立的判定器來處理，又或者由狀態(tài)圖預(yù)先定義好，如此等等。

建立“狀態(tài)驅(qū)動”和“遷移判定”這兩個被抽象化的概念，有助于我們深入理解狀態(tài)機(jī)的機(jī)理，并且對我們設(shè)計(jì)一個魯棒性和擴(kuò)展性更好到狀態(tài)機(jī)有實(shí)際指導(dǎo)意義。

以下是表示一個‘簡陋’的 Email 地址格式的解析器狀態(tài)圖，狀態(tài)遷移條件采用正則表達(dá)式來表達(dá)，其中圖二又稱為“狀態(tài)遷移圖”。

圖一：節(jié)點(diǎn)式

圖二：表格式（紅色格表示拒絕或異常；灰色格表示忽略或無意義；其他格表示遷移條件）

有了上面的狀態(tài)圖，就像建筑工人拿到了詳細(xì)的建筑設(shè)計(jì)圖紙；現(xiàn)在我們只需要對著狀態(tài)機(jī)圖，把它映射成代碼即可完成一個基本狀態(tài)機(jī)。狀態(tài)機(jī)圖越詳細(xì)，實(shí)現(xiàn)起來就越容易，同時代碼的可維護(hù)性也越好。

public class Email
{
    public string Identifier { get; private set;}
    public string Host { get; private set; }
    public string Domain { get; private set; }

    private Email() {}

    public static Email Parse(string text)
    {
        if(string.IsNullOrEmpty(text))
            return null;

        var state = State.None;

        /* The State-Driven */
        for(int i=0; i
上面的代碼雖然看起來沒什么技術(shù)含量，但它已經(jīng)具備了一個狀態(tài)機(jī)最基本的三大要素了（狀態(tài)、狀態(tài)驅(qū)動、遷移判定），針對具體業(yè)務(wù)場景我們只需完善和優(yōu)化它的程序結(jié)構(gòu)，底層原理的基本要義其實(shí)就是這么簡單。

失控的大腦
人腦是一個很神奇的存在，它很擅長處理抽象思維，對于邏輯推理也有很好的應(yīng)對能力，但卻有個不擅長處理并發(fā)任務(wù)的Bug。比如當(dāng)面臨很多個邏輯分支，各分支的判定條件彼此關(guān)聯(lián)，大腦很快就會陷入繁雜的狀態(tài)中無法自拔。
表現(xiàn)在解決復(fù)雜流程相關(guān)的任務(wù)時就是，寫著寫著你會發(fā)覺腦子好像不夠用了，而程序中的 Bug 卻像打地鼠游戲中的老鼠一樣層出不窮。不難想象，即使腦力過人的你在勉強(qiáng)寫完后的某天，產(chǎn)品經(jīng)理帶著他的腦洞又來找你了，在他的威逼利誘下你打開了一個月前的代碼，忽然，覺得還是抱著產(chǎn)品經(jīng)理同歸于盡算了……
這大概是某某同學(xué)，面對自己曾經(jīng)的代碼時痛苦的根源所在，因?yàn)槠胀ㄈ嗣鎸?fù)雜流程問題時，終歸受人腦算力所限。本質(zhì)上這是人腦算力有限的一個困境，人類解決這個困境的一個行之有效的辦法就是“分而治之”，即將一個大問題或復(fù)雜問題不斷進(jìn)行分解分化，直至達(dá)到人腦能相對輕松理解和處理的程度。
為什么說狀態(tài)機(jī)是解決此類問題的一劑良藥？
通過狀態(tài)機(jī)圖可以很容易的看到它天生具有“分解、分化”的特征，一個復(fù)雜的流程由多個流程節(jié)點(diǎn)組成，這些節(jié)點(diǎn)可以理解為對流程的分解，流程節(jié)點(diǎn)之間的轉(zhuǎn)移條件（遷移判定）可以看成是被分化后的邏輯分支，如果大腦直接處理整個流程很容易陷入紛擾的流程分支和各種細(xì)節(jié)中，但是，當(dāng)我們把眼光聚焦在某個流程節(jié)點(diǎn)和它的轉(zhuǎn)移條件上的時候，大腦需要處理的信息量就變得非常少了。
所以，當(dāng)我們直面一個繁雜的流程圖的時候，第一感覺就是復(fù)雜、腦闊痛，這其實(shí)是大腦的正常反應(yīng)，當(dāng)你把眼光聚焦到“Start”節(jié)點(diǎn)上，并順著它往下推，每個節(jié)點(diǎn)的信息量一定是大腦能輕松處理的量級，這種順藤摸瓜的方式反過來也正是流程設(shè)計(jì)的套路。我有時會被自己剛畫完的狀態(tài)機(jī)圖給驚訝到，怎么這么復(fù)雜？因?yàn)楫?dāng)我一點(diǎn)點(diǎn)把細(xì)節(jié)補(bǔ)充上去后，整體性自然會變得復(fù)雜了，但是局部依然是簡單的，而簡單就是可靠、魯棒、可維護(hù)性的同義詞。
代碼只是狀態(tài)機(jī)圖的相關(guān)元素的一種表現(xiàn)形式，它與“節(jié)點(diǎn)式”或“表格式”的狀態(tài)機(jī)圖并無本質(zhì)不同。
另外，狀態(tài)機(jī)圖相對代碼而言，它更專注于流程本身，而代碼畢竟是具體實(shí)現(xiàn)層面的東西，除了流程本身還包括程序結(jié)構(gòu)、業(yè)務(wù)代碼等與流程無關(guān)的代碼，這些額外的東西對我們解讀流程造成了干擾，因而相對純粹的狀態(tài)機(jī)圖就好比是代碼實(shí)現(xiàn)的“地圖”。
經(jīng)過一段時間后，我們可能已經(jīng)不記得實(shí)現(xiàn)細(xì)節(jié)了，這時看著狀態(tài)機(jī)圖來進(jìn)行代碼解讀和修改將會大大提高效率和準(zhǔn)確度，這就是提升代碼可維護(hù)性的有力手段。
如上，狀態(tài)機(jī)是防止代碼失控的一劑良藥，制備完善的狀態(tài)機(jī)圖就是防止代碼失控的一種有效手段。
課后作業(yè)
試著脫離狀態(tài)機(jī)圖擼一個“成員訪問表達(dá)式”的解析器去體驗(yàn)下失控的感受。下次，我們將一起來實(shí)現(xiàn)這個東西。
附注：
成員訪問表達(dá)式：訪問對象方法、屬性、字段、索引器（包括字典、列表）這些成員的表達(dá)式，其中方法和索引器（包括字典、列表）的參數(shù)支持常量和成員表達(dá)式（即表達(dá)式遞歸）。詳細(xì)的文法請參考C#語言手冊。譬如：
PropertyA
.ListProperty[100]
.MethodA(PropertyB, "StringConstant for Arg2", 200, ["key"])
.Children["arg1", "arg2"]
如果你覺得這次的文章對你有所幫助，又或者你覺得我們的開源項(xiàng)目做的還不錯，請為我們點(diǎn)贊并關(guān)注我們的公眾號。

提示
本文可能會更新，請閱讀原文： https://zongsoft.github.io/blog/zh-cn/zongsoft/coding-outcontrol-statemachine-1，以避免因內(nèi)容陳舊而導(dǎo)致的謬誤，同時亦有更好的閱讀體驗(yàn)。


本作品采用?知識共享署名-非商業(yè)性使用-相同方式共享 4.0 國際許可協(xié)議 進(jìn)行許可。歡迎轉(zhuǎn)載、使用、重新發(fā)布，但必須保留本文的署名 鐘峰（包含鏈接：http://zongsoft.github.io），不得用于商業(yè)目的，基于本文修改后的作品務(wù)必以相同的許可發(fā)布。如有任何疑問或授權(quán)方面的協(xié)商，請致信給我 (zongsoft@qq.com)。