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

故事

小貓連續承擔責任，讓他的內心受到了巨大打擊，這在他的職業生涯中是首次。如果對小貓的處境感興趣，可以瞭解“冪等事件”和“緩存擊穿事件”。

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

在這麼短的時間裏發生了這麼多事故，我理解這對你來說也很不容易，畢竟你剛接手這個項目。或許項目本身就存在一些問題。現在責任落到你頭上，希望你不要泄氣……”，組長在一旁繼續說道。

小貓看着小雞點頭，感到放心了。心想：“看來組長不會批評我的績效。”

然而，問題已經出現，系統可能存在其他問題，包括業務、代碼或設計方面。請抽出時間進行整理，並準備一份項目文檔分析。我們期待您在下次月會上與大家分享系統的現狀。

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

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

聊聊熟悉新項目

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

現在我們來談談老貓對一個新系統的熟悉過程。希望這些經驗對你有所幫助，也歡迎分享你自己的方法。主要步驟如下：

項目熟悉

1.嘗試畫一下用例圖

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

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

用例圖簡析

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

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

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

用例

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

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

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

2.後端模型梳理

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

什麼是ER圖

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

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

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

ER例子

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

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

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

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

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

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

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

流程圖

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

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

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

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

泳道流程

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

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

狀態流轉

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

以上就是新接手一個業務系統，我是這麼熟悉的的詳細內容，更多請關注本站其它相關文章！