![1.png](https://ucc.alicdn.com/pic/developer-ecology/2696c9bb9e374b48aa34395f940157cf.png)

作者 | 張建飛  阿里巴巴高階技術專家

> **導讀**：針對業務在不同場景下的差異，我們常常會習慣性地使用 if-else 來實現不同的業務邏輯，久而久之程式碼越來越難以維護。那麼如何消除這些 if-else？面對複雜業務應如何思考和分析？本文分享阿里高階技術專家張建飛（Frank）關於複雜業務治理的方法論，介紹一種多維度分析問題的方法：矩陣分析法。

> You should not be a if-else coder, should be a complexity conquer. 
> ——Frank

這篇文章，是對之前我在[《阿里高階技術專家方法論：如何寫複雜業務程式碼？》](http://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247491068&idx=1&sn=2e724face6f7e1df5e81c377c84862a6&chksm=e92920f3de5ea9e574cdc9b183e837aab9eb032694d44f44c61b4637d8e477e0c0de831f7f51&scene=21#wechat_redirect)說的“自上而下的結構化分解 + 自下而上的抽象建模”方法論的升級。因為在之前的方法論中，我們缺少一個多維度看問題的視角，這種維度思維的缺失，可能會導致 miss 掉一些重要的業務資訊，從而使我們制定軟體設計策略的時候，陷入困難。

有了維度思維，我們便可以更加方面的去看清業務的全貌，更加全面的掌握業務資訊，從而幫助我們更加體系化的去治理複雜性。

# 從 if-else 說起

我經常說，我們不要做一個 if-else coder。這裡的 if-else，不是說我們在 coding 的時候不能使用 if-else，而是說我們不應該簡陋地用 if-else 去實現業務的分支流程，因為這樣隨意的程式碼堆砌很容易堆出一座座“屎山”。

業務的差異性是 if-else 的根源。以零售通的商品業務為例。不同的處理場景，其業務邏輯實現是有差異性的。如下圖所示，商品業務的差異性，主要體現在商品型別、銷售方式和倉儲方式的不同。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/05299dd41b054d24b4d9c69a62206de5.png)

這三個維度上的差異組合起來，有 2 * 3 * 2 = 12 之多。這就是為什麼在老程式碼中，到處可以看到 if(組合品) blabla，if(贈品) blabla，if(實倉) blabla 之類的程式碼。

那麼，要如何消除這些討厭的 if-else 呢？我們可以考慮以下兩種方式：

- **多型擴充套件**：利用物件導向的多型特性，實現程式碼的複用和擴充套件。

- **程式碼分離**：對不同的場景，使用不同的流程程式碼實現。這樣很清晰，但是可維護性不好。

## 1. 多型擴充套件

多型擴充套件可以有繼承和組合兩種方式。繼承勿用多言，組合有點像策略模式，也就是把需要擴充套件的部分封裝、抽象成需要被組合的物件，然後對其進行擴充套件，比如星環的能力擴充套件點就是這種方式。

這裡，我們舉一個繼承的例子，商品在上架的時候要檢查商品的狀態是否可售，普通商品（Item）檢查自己就好了，而組合商品（CombineItem）需要檢查每一個子商品。

用過程式編碼的方式，很容易就能寫出如下的程式碼：

```
public void checkSellable(Item item){
    if (item.isNormal()){
        item.isSellable(); 
        //省略異常處理
    }
    else{
        List<item> childItems = getChildItems();
        childItems.forEach(childItem -> childItem.isSellable()); 
        //省略異常處理
    }
}
```

然而，這個實現不優雅，不滿足 OCP，也缺少業務語義顯性化的表達。更好的做法是，我們可以把 CombineItem 和 Item 的關係透過模型顯性化的表達出來。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8e1cfbbed67e43d3957e122f430d7419.png)

這樣一來，一方面模型正確的反應了實體關係，更清晰了。另一方面，我們可以利用多型來處理CombineItem和Item的差異，擴充套件性更好。重構後，程式碼會變成：

```
public void checkSellable(Item item){
    if (!item.isSellable()){
        throw new BizException("商品的狀態不可售，不能上架");
    }
}
```

## 2. 程式碼分離

所謂的程式碼分離是指，對於不同的業務場景，我們用不同的編排程式碼將他們分開。以商品上架為例，我們可以這樣寫：

```
/**
* 1. 普通商品上架
*/
public void itemOnSale(){
    checkItemStock();//檢查庫存
    checkItemSellable();//檢查可售狀態
    checkItemPurchaseLimit();//檢查限購
    checkItemFreight();//檢查運費
    checkItemCommission();//檢查佣金
    checkItemActivityConflict();//檢查活動衝突

generateCspuGroupNo();//生成單品組號
    publishItem();//釋出商品
}

/**
* 2. 組合商品上架
*/
public void combineItemOnSale(){
    checkCombineItemStock();//檢查庫存
    checkCombineItemSellable();//檢查可售狀態
    checkCombineItemPurchaseLimit();//檢查限購
    checkCombineItemFreight();//檢查運費
    checkCombineItemCommission();//檢查佣金
    checkCombineItemActivityConflict();//檢查活動衝突

generateCspuGroupNo();//生成單品組號
    publishCombineItem();//釋出商品
}

/**
* 3. 贈品上架
*/
public void giftItemOnSale(){
    checkGiftItemSellable();//檢查可售狀態
    publishGiftItem();//釋出商品
}
```

這種方式，當然也可以消除 if-else，彼此獨立，也還清晰。但複用性是個問題。

## 3. 多維分析

細心的你可能已經發現了，在上面的案例中，普通商品和組合商品的業務流程基本是一樣的。如果採用兩套編排程式碼，有點冗餘，這種重複將不利於後期程式碼的維護，會出現散彈式修改（一個業務邏輯要修改多處）的問題。

一個極端情況是，假如普通商品和組合商品，只有 checkSellable() 不一樣，其它都一樣。那毫無疑問，我們使用有多型（繼承關係）的 CombineItem 和 Item 來處理差異，會更加合適。

而贈品上架的情況恰恰相反，它和其他商品的上架流程差異很大。反而不適合和他們合用一套流程程式碼，因為這樣反而會增加他人的理解成本。還不如單獨起一個流程來的清晰。

那麼，問題來了，我們什麼時候要用多型來處理差異，什麼時候要用程式碼分離來處理差異呢？

接下來，是我今天要給你著重介紹的多維度分析問題的方法論之一：矩陣分析法。

我們可以弄一個矩陣，縱列代表業務場景，橫列代表業務動作，裡面的內容代表在這個業務場景下的業務動作的詳細業務流程。對於我們的商品業務，我們可以得到如下的矩陣：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/461099ceadce4f418f9938e08bf33fc6.png)

透過上面的矩陣分析，我們不難看出普通品和組合品可以複用同一套流程編排程式碼，而贈品和出清品的業務相對簡單，更適合有一套獨立的編排程式碼，這樣的程式碼結構會更容易理解。

# 維度思維

## 1. 多維度的重要性

上面的案例不是我編造出來的，而是我在和張文（我同事）討論應該用哪種方式去處理業務差異的真實故事。

我記得在和大學討論完，開車回去的路上，我一直在想這個問題，然後在第二個路口等紅燈的時候，突然有一個靈感冒出來。我抑制不住興奮，一邊開車，一邊發訊息給張文說：“我想到了一個很 NB 的方法論，能解決在‘多型擴充套件’和‘程式碼分離’之間如何做選擇的問題”。

其實，我知道我興奮的不僅僅是解決了這個問題。我興奮的是，我第一次真正領悟到了多維度思考的重要性。從而有機會從一個“單維度”生物，升級成一個“多維度”思考者。媽媽再也不用擔心我被“降維打擊”了 :)

結構化思維有用、很有用、非常有用，只是它更多關注的是單向維度的事情。比如我要拆解業務流程，我要分解老闆給我的工作安排，我要梳理測試用例，都是單向維度的。

而複雜性，通常不僅僅是一個維度上的複雜，而是在多個維度上的交叉複雜性。當問題涉及的要素比較多，彼此關聯關係很複雜的時候，兩個維度肯定會比一個維度要來的清晰，這也是為什麼說矩陣思維是比結構化思維更高層次的思維方式。

實際上，我們從漢語的詞彙上，也不難看出一個人的思維層級，是和他的思考維度正相關的。當我們說這個人很“軸”、“一根筋”的時候，實際上是在說他只有一維的線性思維。所以，觀察事物的視角越多，維度越豐富，其思維層級也會越高。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/f51651a4dae04c319baf55880deecb71.png)

## 2. 無處不在的多維思考

有了這些感悟，我開始系統的整理關於多維度思考分析的資料，發現這種思考方式真是無處不在。發現的越多，我越是感慨，為什麼如此重要的思維方式，我到現在才領悟到。

### 1）波士頓矩陣

比如，在做產品分析的時候，有對產品發展前景進行分析的波士頓矩陣。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/ce2d7a5718ef4dc9803dde4ab60050ea.png)

### 2）訂單要素分析

當年，我在 1688 做交易下單業務的時候，有非常多的下單場景，每種場景下，買家享受的權益是不一樣的（如下表所示）。我們當時也是使用了矩陣去表達這個複雜的關係，只是當時還沒有想到要將其提升到方法論的高度。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/6ef8b568d23744899ddef9a542999e7b.png)

### 3）資料交叉分析

在資料分析中，維度分析是非常重要的，特別是維度很多的時候，我們可以透過皮爾遜積矩相關係數，做交叉分析，從而彌補獨立維度分析沒法發現的一些問題。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/8207739fcaa248b6be960e40ee9c5d7c.png)
簡單相關係數矩陣

### 4）分析矩陣

最近我碰巧看到 Alan Shalloway 寫的《設計模式解析：Design Patterns Explained》，這是一本非常經典的關於 OOP 的書，裡面的第十六章就是專門講“分析矩陣”的，作者創造這個方法論的初衷也是因為業務涉及的要素太多，資訊量太大，他需要一種組織海量資料的新方式。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/b2c4a8d8f2734fb59aba9b77df2698a2.png)

我和 Alan 的路徑不一樣，但是都得出了同樣的結論。由此可見，這種矩陣分析的方式的確是對複雜業務進行分析的一把利器，業務場景越多，交叉關係越是複雜，越需要這樣的分析。

### 5）組織陣型

生產關係決定生產力，對於一個管理者來說，如何有效的設定組織結構是決定團隊是否能高效協作的關鍵。所以我們可以看到公司裡面，每年都有比較大的關於組織結構和人員安排的調整。

對於技術團隊來說，我們習慣於按領域劃分工作範圍，這樣做的好處是責任到人、職責清晰。然而，領域只是一個維度，我們工作通常都是以專案的形式的開展，而專案通常是貫穿多個領域的。所以，在做團隊組織規劃的時候，我們可以透過業務領域和業務專案兩個維度去看。

比如，在我負責的商品團隊，我會按照如下的形式去做職責劃分。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e2cb77b3c7954c50acbcdcd2a1bf5306.png)

### 6）時間維度

除了工作，生活中也到處可見多維思考的重要性。

比如，我們說浪費可恥，應該把盤子舔的很乾淨，豈不知加上時間維度之後，你當前的舔盤，後面可能要耗費更多的資源和精力去減肥，反而會造成更大的浪費。

我們說程式碼寫的醜陋，是因為要“快速”支撐業務，加上時間維度之後，這種臨時的妥協，換來的是意想不到的 bug，線上故障，以及無止盡的 996。

### 7）RFM 模型

簡單的思考是“點”狀的，比如舔盤、程式碼堆砌就是當下的“點”；好一點的思考是“線”狀，加上時間線之後，不難看出“點”是有問題的；再全面一些的思考是“面”（二維）；更體系化的思考是“體”（三維）；比如，RFM 模型就是一個很不錯的三維模型。可惜的是，在表達上，我們人類只能在二維的空間裡去模擬三維，否則四維可能會更加有用。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/3690cbbcddf140abaf9094c572c9ecf6.png)

# 複雜業務治理總結

在前言部分，我已經說過了，多維分析是對之前方法論的升級。加上以前的方法論，完整的方法論應該是“業務理解-->領域建模-->流程分解-->多維分析”。

為了方便大家理解，下面我把這些方法論做一個簡單的串聯和解釋。

## 1. 業務理解

理解業務是所有工作的起點。首先，我們要找到業務的核心要素，理解核心概念，梳理業務流程。

比如，在零售通的商品域，我們要知道什麼是商品（Item），什麼是單品（CSPU），什麼是組合品（CombineItem）。在下單域，我們要知道訂單（order）的構成要素是商品、優惠、支付。在 CRM 領域，我們要理解客戶、機會、聯絡人、Leads 等等。

這裡，我想再次強調下語言的重要性，語言是我們思考的載體，就像維特根斯坦說的：“凡是能夠說的事情，都能夠說清楚”。

你不應該放過任何一個模糊的業務概念，一定要透徹的理解它，並給與合理的命名（Ubiquitous Language）。唯有如此，我們才能更加清晰的理解業務，才能更好的開展後續的工作。

## 2. 領域建模

在軟體設計中，模型是指實體，以及實體之間的聯絡，這裡需要我們具備良好的抽象能力。能夠透過龐雜的表象，找到事務的本質核心。

再複雜的業務領域，其核心概念都不應該太複雜，抓住了核心，我們就抓住了主線，業務往往都是圍繞著這些核心實體展開的。

比如，商品域雖然很複雜，但其核心的領域模型，無外乎就如下圖所示：

![12.png](https://ucc.alicdn.com/pic/developer-ecology/dd1f9796160e445ca7bb9d89438dbe07.png)

## 3. 流程分解

關於流程分解，在[《阿里高階技術專家方法論：如何寫複雜業務程式碼？》](http://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247491068&idx=1&sn=2e724face6f7e1df5e81c377c84862a6&chksm=e92920f3de5ea9e574cdc9b183e837aab9eb032694d44f44c61b4637d8e477e0c0de831f7f51&scene=21#wechat_redirect)裡面已經有非常詳細的闡述，這裡就不贅述了。

簡單來說，流程分解就是對業務過程進行詳細的分解，使用結構化的方法論（先演繹、後歸納），最後形成一個金字塔結構。

比如，在商品領域，有建立商品、商品上架、上架稽核、商品下架、下架稽核、修改商品、刪除商品等一些列動作（流程），每個動作的背後都有非常複雜的業務邏輯。我們需要對這些流程進行詳細的梳理，然後按步驟進行分解。最後形成一個如下的金字塔結構：

![13.png](https://ucc.alicdn.com/pic/developer-ecology/911eed1516e44c57b28367b800b48f09.png)

## 4. 多維分析

關於多維分析，我以二維的矩陣分析為例，我想我前面應該已經說清楚了。

業務的複雜性主要體現在流程的複雜性和多維度要素相互關聯、依賴關係上，結構化思維可以幫我們梳理流程，而矩陣思維可以幫忙我們梳理、呈現多維度關聯、依賴關係。二者結合，可以更加全面的展現複雜業務的全貌。從而讓我們的治理可以有的放矢、有章可循。

既然是方法論，在這裡，我會嘗試給出一個矩陣分析的框架。試想下，如果我們的業務很簡單，只有一個業務場景，沒有分支流程。我們的系統不會太複雜。之所以複雜，是因為各種業務場景互相疊加、依賴、影響。

因此，我們在做矩陣分析的時候，縱軸可以選擇使用業務場景，橫軸是備選維度，可以是受場景影響的業務流程（如文章中的商品流程矩陣圖），也可以是受場景影響的業務屬性（如文章中的訂單組成要素矩陣圖），或者任何其它不同性質的“東西”。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/da2d348b09c143168cdfbff6b2a4d22f.png)

透過矩陣圖，可以清晰的展現不同場景下，業務的差異性。基於此，我們可以定製滿足差異性的最佳實現策略，可能是多型擴充套件，可能是分離的程式碼，也可能是其它。

這就是矩陣分析的要義，其本質是一種多維度思考的方法論。

# 篇後寄語

最後，我想說世界是熵增的（即萬物都在緩慢的分崩離析），控制複雜度是我們這些從業者無法推卸的責任和使命。

軟體行業的發展才幾十年，還是一門年輕的學科，軟體工程就像一個剛學會走路的小孩，還很不成熟，有時還很幼稚。

但畢竟還是有幾十年的沉澱，還是有一些好的方法和實踐可以參考，我的這些總結沉澱只是在前人的基礎上，多走了一點點而已。但就是這一點點，也實屬來自不易，其中冷暖，只有自己能體會。可以說，這一路走來，是一場對心力、腦力和體力的持續考驗。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/06d598d880be48a8ab3939a57608fc8b.png)

- **心力**是指不將就的匠心，不妥協的決心，不滿足的好奇心、以及不放棄的恆心。

- **腦力**是指那些必要的思維能力、學習能力、思考能力、思辨能力。

- 之所以說“業務理解-->領域建模-->流程分解-->多維分析”是**體力**，是因為實現它們就像是在做填空題，只要你願意花時間，再複雜的業務都可以按部就班的清晰起來。

梳理清晰了，再配合 COLA（[https://start.aliyun.com/](https://start.aliyun.com/)）的指導，我們就有可能寫出清晰、易讀的程式碼，就有可能從一個 if-else coder 升級為一個 complexity conquer。

而這不正是我們工程師孜孜不倦的追求嗎?

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495092&idx=1&sn=fcfea85971aa5974b1617ad259298790&chksm=fae6e67bcd916f6d28a2349ac387b4037b3def7ebb111fdf9b0f6ab5756df3def126531c209d&token=921359287&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”</item>

面對複雜業務，if-else coder 如何升級？

相關文章