1. 程式人生 > 其它 >如何快速熟悉一個系統

如何快速熟悉一個系統

一、快速熟悉一個系統

我認為寫得很好的一個文章,如何快速熟悉一個系統。參考博文:https://www.cnblogs.com/flashsun/p/9450066.html

現在發現如何快速熟悉一個系統,核心的內容就是邏輯,如何把邏輯理解清楚,是我們首要去處理的問題。

從技術的角度,主要從頁面到資料庫:一個是整理資料庫表,一個是整理Controller層的所有介面。

1.從頁面到資料庫的線

針對邏輯流程的測試,可能最好的方式是從頁面到資料庫的線:頁面訪問路徑--前端專案--後臺服務--資料庫地址。

2.整理資料庫表

  1. 找核心專案
  2. 篩選核心資料表
  3. 判斷核心表
  4. 找出表與表之間的關係

找核心專案: 目標明確,找一個核心專案去展開。

篩選核心資料表: 分2種情況,一個是表少,直接拿工具匯出來表結構,一個個看就行了。但如果資料庫表特別多,我們首先要將表名全部匯出,篩選出那些核心的表。這裡匯出表名、篩選表以及後面的分析表字段,不妨給自己做個工具。

判斷哪些是核心表: 首先排除常規表(備份表、中間表、統計表、日誌表、配置表)。比如在公司分析的系統,一共150多個表,其中有好多copy結尾的是備份,flow結尾的是流水,rel結尾的是中間關聯表,statistics結尾的是資料統計表,log結尾的是日誌表,config結尾的是配置表,等等。其次剩下的表進行分類。比如常規表排除以後也就剩20來張表,再根據它們的名字,可以看出好多表是屬於一類的,比如order表就有各種order,按類別再分出來也就四五類,再分析起來就不難了。當然如果是更大的體系結構,那就要再不斷做拆解。

找出表之間的關係:在具體分析這些核心表字段之前,還要做一件事就是找出表中間的關係。如果表b中有個欄位,比如 叫 a.id,那麼b和a就是一對多的關係;如果兩個表有rel中間表,那二者就是多對多的關係,起碼從邏輯上講是這樣的。這個分析過程可以做個小工具,通過程式來判斷。

到此,你就對整體的資料庫結構有所瞭解了。根據表名也能對錶的大致內容有所瞭解,接下來就是針對具體的表,看裡面具體的欄位和前人給出的備註,這個過程就沒有技巧了,要耐心,要慢慢熬。

3.整理controller層的所有介面

當對資料庫表做了以上的瞭解後,你基本上對這個系統能提供什麼服務瞭解得差不多了。這個時候不論你的程式碼長什麼樣子,資料庫擺在那裡,能提供的服務差不多就已經出來了,對有經驗的人來講,程式碼的業務邏輯也大致能猜到個八九分。

我們梳理了大後方,那接下來就是把最前端和別人互動的部分搞清楚,這樣掐頭去尾,整個專案就解剖的差不多了。

可以做個小工具,掃描出所有的controller層的介面,展示出方法名、路徑名、引數列表和返回值等,但可惜沒能展示註釋。

和資料庫一樣,如果介面很少,那麼一個個看;如果特別多,還是先找出比較核心的幾個方法研究。

可以用postman,把要研究的介面訪問儲存起來,並且新增訪問成功和失敗的Example。我推薦自己開發的時候也把postman用起來,越詳細越好,postman不只是可以簡簡單單訪問你的介面,還能做批量測試,還可以生成api文件用於和前端互動。這樣你不但測試了自己的介面,還省的寫文件了。而且postman還有個好處就是可以給自己的介面mock一個服務,這樣即使你的介面掛了,或者介面根本就沒寫好,也可以讓前端人員先訪問你的mock,完全不影響前端邊測試邊開發,這才是真正的前後端分離嘛。

4.重新清理專案間的關係

  好了,這時候每個專案你已經大致瞭解,最起碼呼叫的效果,資料庫所能提供的服務,你是清楚的。至此,就要重新整理下專案之間的關係了。

根據之前的介面名稱,詳細瞭解下專案間的呼叫關係。理不清的部分去問老員工,這時候你帶著自己的瞭解問,他們也能給出更多的資訊。

看看每個專案中用到的中介軟體,主要是mq服務,看看誰是生產者,誰是消費者,以此來了解關係。

這時你應該已經開了好幾輪的週會了,接下來的週會你應該能聽懂部分內容。根據每個人的描述和最新的幾組需求,逐漸摸清楚現在專案面臨的問題,以及哪個專案是核心,哪個專案是輔助,哪個專案是以穩定安全為主的。

到此為止,你對整條業務線就有了大致的瞭解,接下來就可以結合你具體負責的內容、領導安排你做的方向,去看具體的業務程式碼了。

雖然之後的步驟依然需要你深入其中,事無鉅細地瞭解具體內容, 但此時,你通過前面的努力,已經可以站在一定的高度看每一個專案了,雖然你細節上還是不瞭解,但這是完全不同的。

在研究具體業務程式碼的同時,不斷地跳出來看整條業務線的框架,修正之前由於不瞭解具體業務而理解錯誤的架構。

長此以往,你一定會在某個專案中脫穎而出,讓大家認識到你的全域性視野,這也是走出老是寫增刪改查程式碼怪圈的一個途徑。慢慢會有人意識到,你對專案的理解總能站在全域性的視野,很多需要跨專案去做的業務,也會自然而然想到你,慢慢地,你會接觸到更為核心的東西,成為架構師,或者去轉向產品,轉向管理。