故事

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

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

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

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

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

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

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

聊聊熟悉新項目

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

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

項目熟悉

1.嘗試畫一下用例圖

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

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

用例圖簡析

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

用途：能夠列出系統(tǒng)中的用例和執(zhí)行者，并顯示哪個執(zhí)行者參與了哪個用例的執(zhí)行。

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

用例

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

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

這樣我們就可以很清晰地了解當前的業(yè)務現(xiàn)狀。

2.后端模型梳理

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

什么是ER圖

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

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

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

ER例子

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

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

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

當咱們梳理完ER圖之后，其實上述的用例業(yè)務圖如何在現(xiàn)有系統(tǒng)中的抽象大概就清楚了。

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

3.核心流程以及狀態(tài)機流轉

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

流程圖

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

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

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

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

泳道流程

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

那么再細節(jié)一點，比如討論到訂單狀態(tài)的一些流轉的時候，此時我們?yōu)榱烁玫陌芽?，會使用一些狀態(tài)的流轉圖去梳理。

狀態(tài)流轉

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

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

4.引入時序圖

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

如下圖。

時序圖

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

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

片段

5.復雜代碼的類圖

完成上面這些梳理之后，這個老系統(tǒng)其實就已經(jīng)被你搞定了，后續(xù)一些比較細節(jié)的地方，當然隨著業(yè)務功能地迭代再慢慢吃透。

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

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

寫在最后

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