子曰，知之為知之，不知為不知，是知也。

知道自己不知道也是一種知道，但作為開發人員，面對一個系統時，無論是開發新功能還是維護老系統，我們更多的是處在一種茫然無助，不知道如何下手，甚至不知道自己不知道的狀態中。雖然系統開發的實踐已經超過半個世紀了，在各個方面都取得了長足的進步，解決了很多難題，但我們在開發效率方面的提高明顯跟不上系統規模的膨脹。雖然各種新想法，新方案雖然層出不窮，但始終都沒成為大家心目中的那枚銀彈。

本文試圖從分析開發人員面臨的困難與挑戰入手，剖造根因，探索解決之道，最終通過提供工具來落實解決方案。也許沒辦法提供一枚完美的銀彈，但鋼彈鐵彈也能打敗怪物。

一、系統開發面臨的挑戰

對於一個擁有多年實踐經驗的開發人員來說，軟體開發的本質其實是軟體維護

，因為任何一個系統從開發的第二天開始，就會面臨一個理解的問題，擺在我們眼前的始終是如何理解昨天的系統和構建今天與明天的系統。

理解系統的途徑無非是閱讀文件和程式碼。但無論公司大小，只要對開發工作有所積累，都會發現通過文件和程式碼進行理解存在巨大的困難。雖然是老生常談，但為了深入理解問題並針對性的提出解決辦法，我們還是先花點時間聊聊。

1.1、文件迷宮

首先，人人都討厭寫文件。人的思維的速度是任何事物都無法匹敵的，嘴巴跟不上大腦，手更跟不上。因此我們往往發現找不到文件或即使找到，文件質量也很差。產品經理負責的需求文件可能好點，因為他們必須寫，但開發人員負責的設計和說明文件其質量大家心裡都有數。

其次，開發本質上是個翻譯的過程。從最開始的想法到終端使用者看到的實現，中間要經歷多次的翻譯過程：

需求 --> 設計 --> 程式碼

哪裡有翻譯，哪裡就有誤解。由於各個環節參與的人之間存在概念，慣用語等各方面的差異，存在誤解是必然的，不誤解是僥倖的。並且由於在各個環節之間的抽象程度不一樣，在環節之間還存在細節的增強與丟失。這就是為什麼文件往往缺乏關鍵的實現細節。

常見的情況是很多需求確認的內容會在口頭，電話或郵件中表述，但沒有反映到文件裡面，雖然最初參與溝通和系統實現的人按照這種需求做了，但後繼維護的人就無法找到原始的需求來源。

最後，很隱蔽，但很關鍵的一點是文件之間的無關聯性。需求文件與設計文件，設計文件與程式碼本質是割裂的，沒有關聯的。任意文件的改動不會引起其他文件的自動同步。

這事實上決定了文件是不可信的。即使找到一些文件，這些文件也都很少反映最新的需求和系統現狀。也許最初的文件寫的很工整，與實際系統大致吻合，但幾個版本以後，文件一般都會變得要麼支離破碎，要麼結構混亂，最慘的是根本就忘了更新。

這是現實，討論對錯沒有什麼意義。最終悲催的開發人員只能依賴原始碼，從原始碼反推需求。也就是那句著名的“Talk is cheap, show me the code”

1.2、原始碼泥潭

通過看程式碼理解系統是沒有辦法的辦法。小公司，小模組裡幾千，上萬行程式碼的系統我們也許可以這麼做，但面對一個百萬，千萬程式碼行級別的系統，我們本質上無法通過閱讀程式碼來進行理解的。

經常會聽到某某技術公司的CEO/CTO說其會看程式碼，以表示自己多麼的hands-on。我們做個簡單的算術，假定一個人1天可以看完1萬行程式碼，100萬代碼需要近3個月時間，很難想象一個高層人士3個月什麼事情也不做，只是看程式碼，並且程式碼每天都在變化。靠對細節的觀察反推巨集觀系統，這種思路是錯誤的。

系統的動態幾乎不可能通過人工的靜態分析推測出來。看程式碼只能檢查一些很表面的東西，幾乎所有的程式碼檢查都以對格式或命名之類的細節爭論收場。當然不能說看程式碼完全沒用，在一個很小的團隊內部，大家都對系統很熟悉的情況下，這樣做可能是有效的；但放到cross team的情況下，程式碼review最終會變為形式或者一個social activity而已。

當然我們最終還是得看原始碼的。談到看程式碼，大家心裡想的一定是能不看就不看，因為大多數的原始碼真的是慘不忍睹。對於任何一個有點積累的公司來說，到處都是超長的類，超長的方法；超大，超長，超寬的巢狀條件分支；硬編碼的物件組裝邏輯等等，更別談各種新興的AOP和位元組碼技術埋伏在各種和你眼前的程式碼完全無關的想不到的角落。這樣的原始碼要麼完全讓人無法讀懂，要麼即使看完了也不敢說自己真的明白怎麼回事。

系統開發並不僅僅意味著寫程式碼，問題的規模不同，解決的手段也不同。不幸的是我們開發任何規模的系統用的辦法都似乎是同一個原始的手段--寫程式碼。對於一個小系統，直接上程式碼也許沒問題，但對於大多數工業級別的系統，由於規模不同，這麼做只能是低效的甚至是失敗的。

從整個系統的角度來看，程式碼僅僅是最底層實現的細節。程式碼可以完成很多事情，但不意味著程式碼是解決所有開發問題最有效的手段。對於寫給人類看的程式碼來說，程式碼只適合描述簡短的順序邏輯，分支和巢狀結構。

通過看程式碼來理解一個系統是最低效的方式，好比一個人試圖通過雙腳走遍一個森林的每個角落來理解整個森林一樣,本質上是不可能完成的任務。

二、解決思路

問題意味著機會，思路決定著出路。如果承認提高系統開發效率的關鍵在於如何快速高效的理解系統，那麼我們的解決問題的方向和判斷標準就很明確。

先排除不正確的思路，我認為有如下幾個：

1.     堆砌流程。流程越多越痛苦。這個無需多說。真正該做的事是現有流程的簡化與自動化。流程本質上跟提高理解系統和構建系統的效率無關。系統開發的主要工作是理解並構建一個可以執行的系統，而不是構建一套工作流程。參與到流程中的時間必然會擠佔掉實際開發的有效時間。

2.     開發更多的管理工具。大多數工具做的是和開發無關的周邊管理工作，例如編譯，持續整合，原始碼管理，釋出等等。同流程一樣，管理工具越多，開發工作越艱難。經常發現為了統一目前過多的解決方案，大家頭腦一熱就又做了一個類似的。往往很多系統之間對關鍵資料都對不上號。這個道理跟航海時用一個鐘錶還是兩個鐘錶的問題一致。

3.     貿然引進與目前類似的新語言/框架/標準。公司級別的開發實踐和個人的開發實踐是兩個完全不同概念。個人如同武林高手，多學習新東西是自我成長的必要，藝多不壓身，最好成為全才；公司如同軍隊作戰，講究的是快速培訓，快速上手，團隊合作，同一標準，簡潔高效，對人的要求是中眾就行。引入過多的語言/框架/標準會導致對人員要求不必要的提高。因此對公司開發而言必須要對引入新東西保持警惕。如果沒有新東西，不符合之前提到的標準，對開發效率沒有很大的提高，又或者僅僅只是重複解決已經被現有方法解決了的問題，這種引入就是失敗的，只會增大整個系統的複雜度，增加理解的難度，進一步拉低效率。

要構建一個可以快速高效理解的系統，正確的思路主要是為系統構建提供一種簡單易懂，無需翻譯的方式。其次由於不同領域的模型千差萬別，無法通過一個統一的模型來描述，針對不同的問題領域，我們需要合適的模型和專用的建模工具。因此正確的方案需要做到以下幾個方面：

2.1、圖形化編輯

俗話說百聞不如一見。由於人天生對圖形比對文字理解來的更快，更自然。因此一個高效的工具必須首先是視覺化的。從系統頂層模型就開始通過視覺化工具來構建，直到不得不借助程式碼來實現的細節層面之上為止。同時由於某些問題領域可能具有相當的複雜度，往往一張圖不能完全表達整個系統，所以必要時需要支援子圖，要做到主圖與子圖之間的相互關聯。通過這種方式做到從抽象到具體的層級遞進，讓人擁有看系統的“鷹眼”。既可以檢視高層的結構，又可以快速定位到某個特定的抽象層次。

2.2、基於模型而不是程式碼

很多程式碼其實描述的是業務模型或者資料模型，雖然能執行，但是是無法理解或者實現上非常笨拙。正確的做法是將業務模型和資料模型從程式碼裡面解放出來，模型就用能最直接表示模型特點的方式來描述。實踐中有一種做法是試圖通過程式碼生成來完成模型到實現的關聯，但大部分場景會存在上面提到的細節丟失問題，導致無法有效做到雙向同步。要做到模型的有效性，最好的做法是直接使用模型而不是程式碼生成，並且在開發和執行時是同一個。

圖1

通過以上兩點把系統開發的方法從簡單的堆砌程式碼提升到基於視覺化模型的層次。方法不同，層次不同，描述系統的的廣度和難易程度就不同，理解系統的效率將大大提高。

那麼情形值得我們抽象成特定的模型？根據實際工作中的痛點，行為，決策和狀態這幾個模型值得抽象出來。

2.2.1行為模型

站在使用者和開發的角度，一個系統是由其提供的服務來定義。系統有哪些服務，完成一個服務需要執行那些步驟，按照什麼路徑執行，是理解系統的關鍵。行為模型可以通過流程圖來視覺化表達。流程圖可以清晰的描述一個服務是如何一步步的完成。從程式碼的角度而言，引入流程圖可以消滅大部分的粘合，判斷程式碼。有利於把一個單體系統拆分為易於理解的子系統，並進一步拆分為具體的步驟。

也許有人會問為什麼不用物件圖或時序圖，原因如下：

1.     物件圖顯示實體間的關係而不是動作如何完成，對系統動態理解沒幫助

2.     時序圖僅能描述特定執行路徑，而無法直觀表述分支/迴圈，對系統動態的描述不完整，也不友好

X-Series工具集裡面的Xross Unit就是利用流程圖構造系統的工具。

2.2.2決策模型

一個決定受哪些因素影響，每個因素的可能取值有哪些，按照什麼順序考慮因素獲得決策。決策模型可以通過決策樹來視覺化表達。這種方式可以直觀的表達複雜邏輯判斷的分支和判斷標準。可以用來取代複雜巢狀的if/else。

X-Series工具集裡面的Xross Decision就是利用決策樹構造決策模型的工具。

2.2.3狀態模型

一個實體具有哪些狀態，狀態之間如何轉移。狀態模型可以通過狀態機來視覺化表達。可以代替複雜的hard-code的狀態判斷和動作觸發。

X-Series工具集裡面的Xross State就是利用狀態機描述模型狀態的工具。

三、X-series簡介

工欲善其事 必先利其器。X-series是一套輕量級的，易於學習，易於使用，易於測試，易於交流的框架。目的是解決大規模軟體開發中溝通不暢，文件不新，分工不當，進度不明等難題。它包括3個元件：

1.     XrossUnit：用流程圖描述服務如何按步驟完成

2.     XrossDecision：用決策樹為複雜決策建模

3.     XrossState：用狀態機管理業務狀態變遷

這三個元件互相之間沒有任何耦合，根據實際需要，在一個系統裡面即可以單獨使用，也可以配合使用。這些元件對執行的平臺也沒有要求，即可以執行在容器裡面，也可以單獨執行在應用程式裡面。

另外還有一個正在開發中的基於SEDA的微服務框架XEDA，屬於執行平臺級別。整體的範圍的關係如下：

圖2

四、Xcorss unit

4.1、簡介

XrossUnit是一個基於流程圖的靈活的系統構建器，又稱xUnit。使用者在Eclipse裡面通過Xross Unit編輯器建立系統服務，編輯服務流程。執行時通過Xross Unit工廠類來獲得並執行定義的流程。

圖3

XrossUnit支援行為元件和結構元件。行為元件又稱為單元，是Xross Unit名字中Unit的來源。行為元件通過介面定義規範對資料處理的方式，是構成模型的基本元素。結構元件提供預定義的結構，方便在行為元件之上用更大的粒度構造流程結構。結構元件可以指定自己表現為那種行為。

XrossUnit的範圍包括流程圖模型和其中的配置資訊，不包括元件內部的程式碼實現。元件內部程式碼需要通過對行為元件的介面實現來完成。

XrossUnit關聯了模型與程式碼，Xross Unit依據模型規劃的路徑自動排程各個行為元件。想要看任意元件的程式碼僅僅需要雙擊即可進入到實現類的內部。

行為元件通過介面定義，包括

1.     Processor。僅對輸入的Context進行處理，沒有返回值

2.     Converter。將輸入Context轉換為輸出Context

3.     Validator。對Context進行true/false判斷

4.     Locator。對Context進行定位分類判斷

行為元件即可以單獨使用，也可以相互組合為更大的結構。

結構元件為按照一定結構預定義的一系列行為元件，包括：

1.     Chain。順序執行一系列單元

2.     If-else。根據Validator的判斷，決定執行兩個分支中的哪一個

3.     Branch。根據Locator的判斷，決定執行多個分支中的哪一個

4.     While迴圈。根據Validator的判斷，決定是否執行包含的單元，並在執行結束後回到Validator再次判斷

5.     Dowhile迴圈。在執行完包含的單元后根據Validator判斷決定是否再次執行

6.     Decorator。對任意單元進行修飾，在單元執行前後做額外動作

7.     Adapter。對任意單元做行為上的轉變，可以用於複用現成元件

XrossUnit編輯器提供了直觀的編輯方法，可以將現有已有單元或結構通過的簡單的物件組合來生成新的結構。例如需要在一個單元原來的處理流程上面需要新增一個新的流程判斷，我們可以在介面上面選擇Validator再單擊需要新增分支判斷的單元或結構就會在原有基礎上增加一個分支結構。編輯器本身支援undo/redo功能。通過這種方式可以快速的從無到有的構建一個複雜的系統，同時保證系統易於理解。

XrossUnit編輯器提供自動排版，使用者僅僅需要在圖上新增修改單元，編輯器會自動根據元件間的關係對佈局做調整，無需人工干預。無論誰來生成，模型都是一致的，始終保持圖的清晰，準確與美觀。

XrossUnit還支援配置，可以在應用或構建單元層次上面配置引數，方便在不同場景下複用同一個模型。

4.2 Xross Unit使用方式

1）構建系統藍圖。可以一個人或大家一起邊討論，邊通過編輯器畫出要開發的系統的流程圖。每個元件都會有預設的樁實現。因此圖畫好了，這個系統就可以馬上執行。

圖4

2） 實現元件單元。針對流程圖中的每個行為元件實現相應的介面，提供實際的處理能力。

圖5

3） 關聯藍圖和程式碼。在編輯器裡面雙擊行為元件，指定實現類的名字。

圖6

4）生成例項並執行。

圖7

4.3、Xross Unit實際示例

我們看一個實際例子來說明其優勢，這是一個實際使用了Xross Unit構建系統的一部分例子。

系統頂層主流程

圖8

主流程中請求籤名驗證對應的子圖

圖9

主流程中中業務處理對應的子圖

圖10

主流程中返回值處理對應的子圖

圖11

具體實現的程式碼不方便，但可以看到流程圖可以有效的描述和分解系統。這難道不是你們渴望已久的工具嗎？

4.4、Xross Unit的優勢

趁手的工具是原則保證的利器，通過上面的例子我們可以看到使用Xross Unit：

首先可以做到快速組建系統：

1.   自頂向下分解，元件化設計，流水線式開發

2.   最優化設計複用

3.   在流程模型與程式碼之間快速切換。無需脫離開發環境

其次可以自然做到系統開發提倡的高內聚，低耦合原則。通過沒有工具的保證，這些原則只能淪為口號

1.   通過名字描述功能

2.   通過配置調整行為

3.   通過Context限定資料

4.   每個unit僅僅完成明確描述的功能，有效控制程式碼複雜度

最後這種構造系統的方式非常易於單元化測試

1.   單介面設計，無選擇，無歧義的實現

2.   通過構造Context，輕鬆模擬測試資料

3.   可以在元件級別快速提供mock object

4.5、Xross Unit不是什麼

不是又一個Spring

Spring是從整體如何由區域性構成的觀點構建系統。Spring的做法其實是完成類圖/物件圖的模型化，如前所述，這種圖無法描述系統動態。xUnit是從請求如何被處理的行為觀點構建系統。

不是工作流

工作流處理多角色在多請求之間的任務/路徑管理，是更大範疇的視覺化。xUnit細化的是單個請求級別的響應路徑/處理單元

不是一個視覺化的程式語言

視覺化的程式語言的做法是解釋和生產程式碼。xUnit將粘合程式碼抽取為模型，在業務層組裝行為和結構單元，

xUnit的系統定位如下圖

圖12

4.6 Xross Unit常見問題

1）為什麼使用單元來完成程式碼也能做的事情？

因為問題的大小決定手段的選擇，想象下面工作的複雜度

                i.         “Hello World”

              ii.         一個Web Service

             iii.         一個小的Web App

             iv.         一個淘寶，ebay，ctrip規模的網站

簡單的系統可以直接用程式碼實現，複雜的系統無法這麼做。單打獨鬥和大規模開發是完全不同的實踐。大規模開發的關鍵是系統理解，不但要最初開發的人理解，後面維護的人和測試，產品等相關人員也都要理解。隨著開發規模的不斷膨脹，最初方法的效果一定會發生變化，手段必然要求變化。由於人總是習慣於當前的做法，這種變化容易被人忽略，有些人可能意識到了問題所在，但沒興趣改變。還有人希望改變，但或者由於工作負擔實在太大，沒時間停下來思考，或者不具備相關的技術，無法做出改進。

目前流行的微服務的產生本質上也是迴應這種規模帶來的變化，但沒有視覺化的支援，微服務除了把一個請求放大到多個請求外，一樣沒出路。 

2）為什麼不用現有的命令框架

常見的命令框架如Servlet，JEE裡面的SessionBean, Entity Bean, Message Bean等等，描述的粒度僅限於系統入口服務。缺乏入口服務級別下的內部細節表示。我們可以觀察到儘管有大量的小的僅僅只有一頁程式碼的command，但是還是會有少量但是非常重要的command非常的複雜，這符合普遍的80/20原則。而這是系統理解最關鍵的一部分。

五、Xross Decision

5.1簡介

XrossDecision又稱為xDecision，是一個圖形化的決策樹編輯器與執行時工具。以所見即所得的方式構造複雜邏輯判斷的過程。同時還可以依據模型生成單元測試的驗證程式碼。xDecision可以用於替代傳統的複雜的if/else判斷，能極大的簡化程式碼並讓業務邏輯易於理解和維護。

圖13

5.2Xross Decision概念

1.    決策樹。決策樹是由判斷節點和其連線組成的模型。每個判斷節點可以包含決策或進一步判斷的因素

2.    因素。一個決策可以由多個因素所決定。一個因素是包括多個可能取值的變數。

3.    決策。決策就是使用者定義的包含特定含義的常量

5.3Xross Decision構建

1.    定義決策的考慮因素。一個決策可以由多個因素所決定。一個因素是包括多個可能取值的變數。

2.    定義決策。決策就是使用者定義的包含特定含義的常量

3.    新增判斷節點。節點可以包含當前節點的決策和進一步判斷所依據的因素

4.    連線節點。節點之間可以相連，連線需要賦予父節點因素的某個取值

可以在編輯器的空白出右鍵點擊出選單完成因素和決策的定義。通過邊欄選單新增節點和連線。

圖14

5.4Xross Decision測試與使用

編輯完成後可以通過生成單元測試的方式來驗證模式是否正確，同時單元測試也演示了實際使用如何進行。

圖15

單元測試是標準的Junit測試程式碼，覆蓋了模型中每一條可以到達決策的路徑，可以直接執行

圖16

六、Xross State

XrossState是視覺化建立狀態機的編輯器，又稱為xState。狀態機的用處極其廣泛，可以說是很多系統的核心。與xUnit類似，xState可以結合模型和程式碼。即可以建立僅包含狀態和變遷的狀態機，也可以提供狀態變遷時的觸發器。

圖17

狀態轉移觸發器

1.     EntryAction。進入下一個狀態時觸發

2.     ExitAction。離開當前狀態時觸發

3.     TransitionAction。在狀態遷移時觸發

狀態轉移校驗

1.     TransitionGuard。判斷狀態變遷是否合法

圖18

XrossState的使用與其他兩個類似，這裡就不細說。下面是執行時的示例程式碼

圖19

一個使用者的實際案例：

圖20

七、X-Series使用小結

無論是xUnit，xDecision還是xState，其使用方式都是：

1.     建立模型

2.     修改模型元素屬性

3.     實現對應介面。這一步不是必需的，只有xUnit需要，xState只有當需要定義觸發器時才需要，xDecision不需要

4.     執行模型。通過工廠類載入模型檔案，獲得對應模型，建立資料，處理資料

圖21

八、Xeda預覽

隨著微服務的興起，微服務的使用在服務層面對系統理解同樣帶來了挑戰。微服務的使用對系統的拆分，重構，運維，監控和釋出有很高的要求，其複雜度大大超過傳統系統架構。

圖22

Xeda是一個正在開發中的視覺化微服務編輯器，可以提供一個基於SEDA模型的微服務實現。其目的是：

1.     提供微服務視覺化編排

2.     提供微服務執行時框架

3.     提供微服務自動部署

4.     提供微服務系統層面的監控

圖23

九、X-Series資源

1.     程式碼和示例

2.     安裝包

X-Series的編輯器運行於Eclipse裡面。目前沒有idea的實現。支援的語言為Java。我的同事王曄楠提供了C#的執行時實現，C#的使用者可以在Eclipse裡面構建模型，在C#環境中執行：

1.     Xrossunit C# runtime

2.     XrossState C# runtime

3.     XrossDecision C# runtime

十、結束語

10.1X-Series開發簡史

X-Series是我獨立開發的一套為了提高開發效率，減輕開發人員工作負擔，提高系統架構質量的工具。是我多年的心血。

最初是在2001年的時候在一個線上拍賣專案中有了開發xUnit的想法，但當時想法還沒成熟，也沒有視覺化編輯器的開發能力，暫時作罷。後來在2006年東南融通做架構師，為北京農行的清算專案做架構的時候，構建了一套基本介面並基於Spring做模型整合，同事試用下來反饋很好，可以大幅降低系統的理解難度，減低維護難度，提高開發速度。這次嘗試驗證了通過流程模型構建系統的可行性，讓我堅定了信心，開始深入思考如何完善模型並積蓄必要的開發能力。後來加入ebay的時候，在無數個加班的後半夜，一個人坐在辦公室裡面面對天量的陌生程式碼時，我無數次的渴望有類似xUnit這樣的工具來幫我快速理解系統。

2007年的時候在ebay做搜尋頁面的時候為了消除複雜到變態的條件分支語句，做了最初的xDecision執行時框架。當時的實現方式是用介面定義決策樹模型，還沒有視覺化編輯器。xDecision在ebay的使用獲得了成功，並給大家做了分享，引起了熱烈的討論。

2012年，通過之前的專案獲得了Eclipse外掛開發能力，才完成了xUnit和xDecision的視覺化編輯器原型並參加了ebay的skunkwork比賽併入圍最後的全球展示。後來繼續完善這兩個系統並開發了xState，直到今天給大家演示的系統。其中的艱辛一言難盡。

10.2大規模系統的建議

大規模系統開發的難點是系統理解，我的看法是在語言層面打轉是沒有出路的，無論哪種語言都無法帶來數量級上的程式碼簡化和理解效率提升，語言這種基於文字，順序描述問題的方式天生決定了它不適合在模型層面視覺化描述系統。現代系統開發的瓶頸是人，而不是機器，流程或工具。大規模開發必須通過合適的工具來提高人的效率才能獲得突破。視覺化技術的表達能力相對語言是維度上的突破，視覺化技術已經在很多領域都有廣泛的應用，例如大規模積體電路設計，建築設計等等，是已經驗證過的成熟解決方案，我認為這是正確的方向。

方向和眼光永遠比速度重要。一個人不可能精通所有的語言和工具，請謹慎選擇合適的工具並確保充分利用工具的潛力。不要什麼都來一點，但每個都不精，每個都只用一小部分功能。那樣只會花費大量的時間但最終卻導致系統複雜到無法理解，無法交接和維護。事物的發展往往在發展中期會變得特別複雜，這正是目前大規模系統開發的狀態。但成熟後又會變得簡潔直觀，比如使用X-Series輕鬆，可控的開發。

現在的系統越來越複雜，使用X-Series可以標準化絕大多數系統開發的流程。這種做法可以作為系統開發原則成為架構文件的組成部分：

首先用xUnit構造通用的系統頂層請求處理流程，並羅列主要服務；其次用xUnit細化各個服務的流程；對於涉及到複雜條件判斷的地方使用xDecision；對明確的狀態轉換使用xState。

需求變更引起的修改要麼只涉及到具體實現，要來只涉及到模型，這種範圍的明確劃分減少了不必要的干擾。模型的變更會直接反映到系統的動態表現。如果改動只涉及到模型，程式碼完全不必修改。

快速高效的開發大規模系統的能力是現今公司競爭的巨大優勢，快打慢，會打不會是一般的規律。具有這種能力的公司將立於不敗之地。或早或晚，未來的開發都會使用X-Series或類似工具。不如此，人類無法構建更巨集偉的系統。新的事物最開始往往不被理解，普遍使用後卻覺得本來應該如此。我對X-Series也有這樣的期待。

請開始使用X-Series。

【作者簡介】赫傑輝，攜程框架研發部高階研發經理，負責攜程DAL元件開發與推廣。

在開發一線奮戰多年的老兵，雖然傷痕累累，但心中對開發還保持著初戀般的感覺。熱愛中國傳統文化和推廣開源軟體，希望用自己開發的工具為大家解決實際問題，願為中國的開源事業貢獻自己的綿薄之力。

文章首發於攜程技術中心微信公號，ID：ctriptech。