新接手一個業務系統，我是這麼熟悉的

故事

接二連三地背鍋讓小貓的內心受到了前所未有的打擊。這也是他職業生涯中的第一次。感興趣的伙伴們如果想瞭解一下小貓怎麼了，可以看一下“冪等事件”以及“緩存擊穿事件”。

這天組長找小貓來到了一間會議室。

“在這麼短的時間內發生了這麼多的事故，我想也你心裡也不好受，也不怪你，畢竟剛接手項目。以前項目中可能本身存在一定問題。正好輪到你頭上，我希望你也不要灰心......”，組長在一邊balabala。

小貓在一旁小雞啄米似的點著頭。緊張的內心緩和了許多，“聽組長這語氣，貌似不扣我績效啊”，小貓心裡尋思著。

“但是呢，事情是發生了，系統中估計還有其他的問題，無論是業務上的還是代碼上的亦或是設計上的，然後我希望你最近可以花時間整理一下，然後輸出一份項目文檔分析。等到下次月會的時候一起分享一下當前系統的情況。”

小貓連連點頭，心裡琢磨“看來還是躲不過當眾批鬥這關啊，罷了罷了，可是，這樣的一份文檔該從哪個口子開始呢，到底該怎麼寫呢”

此時的小貓內心又開始不安起來。

聊聊熟悉新項目

當接手到新的系統的時候，大家是如何進行熟悉的呢？其實老貓在上一篇“緩存擊穿事件”的文末就問過大家了，不曉得大家是怎麼處理的，歡迎大家留言。

接下來和大家聊一下老貓對一個新系統的熟悉過程。如果大家覺得有所幫助也可以借鑒一下。主要按照以下方法：

嘗試畫一下用例圖

當接受到一個新的業務系統之後，首先咱們至少需要知道當前這個系統是乾什麼的，所以有時候就需要抽時間找到相關的產品經理瞭解一下業務，此時產品經理可能會和你聊一下現有的業務現狀和背景，但是有可能也會丟給你一份V0-Vn版本的產品需求方案。如果是後者記住千萬得忍住，不要用顯示器砸產品的臉，因為你們的合作尚未開始。咳咳，開個玩笑，言歸正傳。

我們先瞭解一下什麼是用例圖。

用例圖簡析

用例是系統中的一個功能單元，可以被描述為執行者與主體之間的一次交互行為。執行者是與系統、子系統或類發生交互作用的外部用戶、進程或其他系統的理想化角色。

用途：能夠列出系統中的用例和執行者，並顯示哪個執行者參與了哪個用例的執行。

針對之前小貓遇到的“下單付款的業務點”，咱們來畫個用例圖說明一下。如下圖：

如上圖其實就是一個簡單的用例圖。我們需要搞清楚的是各種線條的含義。

1. a線條表示的是關聯即執行者與其參與的用例之間的通信路徑。用實線表示。
2. b線條表示包含，在基用例上插入附加的行為，並且顯式地描述了該插入。
3. c線條表示擴展，在基用例上插入附加的行為，基用例並不知道。
4. d線條表示用例泛化，一般用例和特殊用例之間地關係，其中特殊用例繼承了一般用例的特征並增加了新的特性。

這樣我們就可以很清晰地瞭解當前的業務現狀。

後端模型梳理

當梳理完當前的系統功能點以及業務形態的時候，我們就可以介入去看一下現有系統的模型了即DB資料庫的表。這樣我們就能知道當前設計的系統是如何對業務進行抽象的。
那麼在看相關表的時候，其實我們就可以慢慢地將ER圖進行繪製出來了。

什麼是ER圖

E-R圖即全稱實體-聯繫圖(Entity Relationship Diagram)，它提供了表示實體類型、屬性和聯繫的方法，用來描述現實世界的概念模型。

通過其定義其實我們就知道了在ER圖裡面有三個比較重要的點，分別是實體類，屬性，聯繫。當我們在整理DB表的時候其實對應的就是我們的表、表欄位以及對應的表和表之間的關係。

看個例子，下麵老貓繪製一下一般商城系統底層的商品邏輯。

解釋一下每一塊圖的含義：

1. 方塊表示一個模型即一個表，當然這個也是ER圖中的實體類。
2. 橢圓形表示實體類包含的屬性。
3. 菱形就表示兩個類之間的動作行為關係，比如上圖中商品上架到貨架上。日常中老師給學生上課，那麼菱形中可能就是上課。
4. 線條上的1和n就更清晰了，就是一對多，多對一，一對一的關係。

上圖中其實我們就可以比較清晰地看到，在當前的這個系統中存在三個比較重要的實體概念，分別是商品、商品池、以及貨架。從圖中我們也可以大概地看到他們之間的關係。

當咱們梳理完ER圖之後，其實上述的用例業務圖如何在現有系統中的抽象大概就清楚了。

聊到這裡，咱們從上帝視角去看一下，我們給當前這個系統賦予了骨架，接下來得讓它的開始心臟跳動，血液奔騰起來，讓整個系統賦予靈魂。
那麼接下來，我們就把模型通過流程的方式串起來。

核心流程以及狀態機流轉

咱們直接看一下例子，其實老貓覺得流程圖的梳理可能比較簡單，但是難的是如何去把控整個流程中的環節。如果在繪製的時候想的比較細緻，可能每一步的落庫環節都會去記錄。這樣的話對於業務的專註度就會少一些。如果畫粗了，模型的對應關係可能又把控不好。所以這個地方老貓覺得還是比較考驗程式員的概括能力以及業務的理解能力的。

上述圖中，老貓簡單畫了一個流程圖，當然流程圖中可能會存在紕漏，大家不要太過較真，在此是說明這麼一個事情，咱們暫且不談裡面業務流程的準確度。
上面流程中我們看到有以下圖形內容：

1. 起始節點，咱們用圓圈表示，當然可以選擇自己喜歡的顏色，沒有太多標準。
2. 流程進行流轉的時候，我們用了相關的箭頭線表示，涉及到核心業務操作的時候就是方塊。
3. 遇到分支節點的時候，咱們用菱形去做路由。
4. 遇到一些非同步操作的時候，老貓喜歡用虛線去表示。

上述這種流程的表示其實是比較簡單的，我們不用去在意系統邊界。只管繪製即可。

但是現在的開發體系咱們往往都是微服務化的，那麼此時我們可能就要考慮到不同系統之間的交互流程。由此，咱們可能機會引入泳道的概念。見下圖。

上述圖中我們就可以看到各個系統應用之間的交互，每一個泳道就代表著其中的一個微服務系統。這是老貓日常熟悉業務中真實繪製的一張圖，再次強調一下大家要看的是繪圖的一些思路，不要太過糾結業務。

那麼再細節一點，比如討論到訂單狀態的一些流轉的時候，此時我們為了更好的把控，會使用一些狀態的流轉圖去梳理。

上述主要是闡述整個狀態在流程中的流轉，當然很多時候狀態位比較簡單的時候，咱們也可以不用畫，可能當狀態比較複雜多樣的時候才會去考慮到畫狀態機。

到此，通過上面的幾個步驟的梳理，其實我們已經能夠對大部分的業務有個熟悉了。但是有的時候還不夠，涉及一些複雜介面交互請求時序的時候，可能還是會翻車弄不清楚，那麼此時咱們就要引入時序圖進行梳理。

引入時序圖

時序圖通常為表示多個對象之間消息交互的序列。
其中時序圖涉及：參與者、對象、生命線、激活、消息、片段。
當然消息中又包含：同步消息、非同步消息、自關聯消息、返回消息。

關於其中的解釋，如下圖例子。

上述簡單繪製了下單扣減庫存的時序。

在上述圖中，老貓用到了其中的一種片段--抉擇，其實關於片段還有很多種類，大家繪製時序的時候可以對照著去使用。

複雜代碼的類圖

完成上面這些梳理之後，這個老系統其實就已經被你搞定了，後續一些比較細節的地方，當然隨著業務功能地迭代再慢慢吃透。

類圖：是描述類、介面、協同以及他們之間關係的圖，用來顯示系統中這些概念的靜態結構，類圖主要由類、介面和各種關係組成。

如果老系統中存在一些屎山代碼或者極端優秀的代碼，你看不透裡面的繼承實現關係的，那麼可以去繪製一下類圖。這裡老貓不作展開，先賣個關子，後續等咱們梳理到設計模式相關知識點的時候，咱們再慢慢聊。

寫在最後

在日常開發的過程中，我們會遇到各種各樣複雜的系統，老貓通過上述手段，基本就可以做一個比較好的拿捏。希望能夠幫助到大家，大家如果還有其他比較好的辦法，也歡迎在評論區留言。