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

故事

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

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

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

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

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

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

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

聊聊熟悉新專案

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

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

專案熟悉

1.嘗試畫一下用例圖

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

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

用例圖簡析

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

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

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

用例

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

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

這樣我們就可以很清楚地了解目前的業務現況。

2.後端模型梳理

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

什麼是ER圖

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

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

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

ER例子

解釋一下每一塊圖的意思：

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

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

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

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

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

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

流程圖

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

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

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

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

泳道流程

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

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

狀態流轉

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

以上是新接手一個業務系統，我是這麼熟悉的的詳細內容。更多資訊請關注PHP中文網其他相關文章！