故事

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

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

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

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

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

小貓連連點頭，心里琢磨“這應該算是變相抓典型吧，罷了罷了，可是，這樣的一份文檔該怎么寫呢”

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

聊聊熟悉新項目

當接手到一個新的系統的時候，大家是如何進行熟悉的呢？其實老貓在上一篇“緩存擊穿事件”的文末就問過大家了，不曉得大家還有印象不？

接下來和大家聊一下老貓對一個新系統的熟悉過程。如果大家覺得有所幫助歡迎借鑒，當然如果大家還有更好的方式，也歡迎留言。主要按照以下方法：

項目熟悉

1.嘗試畫一下用例圖

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

我們先了解一下什么是用例圖。

用例圖簡析

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

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

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

用例

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

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

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

2.后端模型梳理

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

什么是ER圖

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

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

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

ER例子

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

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

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

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

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

3.核心流程以及狀態機流轉

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

流程圖

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

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

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

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

泳道流程

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

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

狀態流轉

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

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

4.引入時序圖

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

如下圖。

時序圖

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

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

片段

5.復雜代碼的類圖

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

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

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

寫在最后

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