本文來自閃客Sun的投稿，博客地址：

https://www.cnblogs.com/flashsun/p/9450066.html

看完你就會明白，雖然有一定的方法論，但是不下功夫，沒有耐心，還是萬萬不行的。

很多新人進入一家新公司后，最頭疼的就是如何快速了解公司的業(yè)務(wù)和項目架構(gòu)。

因為文檔很少，沒有文檔，或者是文檔嚴(yán)重落伍， 根本沒法看；如果你碰到一個特別熱心的老員工，事無巨細地給你講，隨時在你身邊答疑解惑， 那簡直是天大的好運氣， 現(xiàn)實是大家都很忙，沒人給你講解。

很快就要深入項目做開發(fā)了，怎么辦呢？

我在加入新公司后，就遇到了悲催的情況。但是在一個多月時間里，我靠自己的力量熟悉了大概十個項目，總結(jié)了一些方法，分享給大家。

這里強調(diào)一點，我的策略是大體了解整個業(yè)務(wù)線上的所有項目，大概摸清楚每個項目都是干嘛的，他們之間的關(guān)系如何，以便以后具體項目時不至于找不到方向，具體到細節(jié)的業(yè)務(wù)，當(dāng)然還需要花時間，但相比對整體上的一頭霧水，還是簡單許多的。

一. 必要條件

這里說的必要條件不是“項目面對的客戶是誰”，“項目用的框架是什么”這種，而是真真正正的必要條件，就好比用幾條數(shù)學(xué)公理能推出整個數(shù)學(xué)體系一樣。這里我總結(jié)的真正的必要條件只有這兩點：

• 源碼位置（gitlab或svn）
• 部署環(huán)境（dev/test/online）

所謂項目，其實就是一堆代碼放在了一堆機器上而已，所以這些就足夠了。當(dāng)然，為了更加節(jié)約時間，也要獲得wiki、jenkins、頁面訪問路徑、數(shù)據(jù)庫地址等相關(guān)信息。

我之所以說那兩個必要條件，是想說其實項目本質(zhì)上就是這么簡單的一個事，你千萬不要想的太復(fù)雜。

它的業(yè)務(wù)可以無限復(fù)雜，但它的本質(zhì)卻逃不出這些，你千萬不可以糊涂。當(dāng)你無從下手或者什么都不清楚的時候，那么就主要把源碼和環(huán)境弄清楚吧，其它的都是附屬品。

二. 從頁面到數(shù)據(jù)庫

有了上面的必要條件后，我們就開始了解項目了。由于不只是一個項目，所以千萬不能深入具體代碼，否則你就越來越煩，懷疑人生，很快放棄。

對某個具體項目的了解，一定要建立在對整體了解的基礎(chǔ)上。這時我們首先為各個項目畫出一條線，并標(biāo)明每一個節(jié)點的信息，就像下面的樣子：

頁面訪問路徑--前端項目--后臺服務(wù)--數(shù)據(jù)庫地址

這里的一個前端項目可能對應(yīng)多個后臺服務(wù)，所以最終的圖應(yīng)該差不多是這樣：

這個整理的過程，主要是讓自己梳理清楚，一共有哪些項目，哪些是前端可視的，哪些是后臺提供服務(wù)的。

了解前端項目分別調(diào)用了哪些后臺服務(wù)，通過后臺服務(wù)和數(shù)據(jù)庫的名稱，我們能從本質(zhì)上了解到這條業(yè)務(wù)線提供了什么功能，從前端項目和頁面路徑，我們能了解到我們需要給用戶展示什么。

注意，這個階段我們只是見名知意，即使點開頁面，連接上數(shù)據(jù)庫看看，也千萬別花過多的時間，這個階段的重點就是僅僅知道，這條業(yè)務(wù)線提的整體內(nèi)容。

在此基礎(chǔ)之上，這個圖可以不斷細化，比如項目部署的機器，我們可以標(biāo)注在項目旁邊，或者保存在xshell里。此外所有非業(yè)務(wù)相關(guān)的，能查到的盡量都記錄下來，這個真的為以后找各種東西方便太多了，否則別看你現(xiàn)在節(jié)約了時間，把以后查找相關(guān)東西的時間加起來，將會是天文數(shù)字了。

這里關(guān)于整理項目部署的機器還有個小插曲，跟大家分享一下。由于這部分的信息沒人會一個一個地告訴你，就算有也不可能說的特別全。所以我是借助jenkins來整理的。項目部署都需要用到j(luò)enkins，只要查看jenkins配置的命令，就可以把部署環(huán)境一一整理出來，這個我認為是最全而且最新的。

不要和我說查wiki，如果公司wiki都寫的這么全，我估計就沒這篇文章什么事了。當(dāng)時我的jenkins權(quán)限特別少，只能看一部分項目，后來費了很大的勁，想了很多辦法才看到項目的配置，整理出了部署的機器。

三. 了解項目間的關(guān)系

這部分如果有老員工愿意和你說說，那最好還是了解一下。如果沒有也沒關(guān)系，先跳過這段，以后慢慢了解也是可以的。

四. 整理數(shù)據(jù)庫表

我們上面都是整理項目的大體框架，還沒有涉及到具體的項目細節(jié)。這一部分，仍然不去涉及。

如果說站在整個業(yè)務(wù)的本質(zhì)上看，業(yè)務(wù)無非就是一堆代碼運行在一堆機器上。那么站在單個項目來看，一個項目無非就是對數(shù)據(jù)庫的增刪改查操作而已，或者從使用者的角度看，一個項目就是輸入一些參數(shù)得到一些返回結(jié)果。

所以接下來我們要做兩件事，一個是整理數(shù)據(jù)庫表，一個是整理Controller層的所有接口。

這里首先要選擇一個核心項目去看，眾多項目中一定有一個是核心項目，先從這個開始看起。

如果數(shù)據(jù)庫的表比較少，那我們拿工具導(dǎo)出來表結(jié)構(gòu)，一個個看就行了，這個不難。但如果數(shù)據(jù)庫表特別多，我們首先要將表名全部導(dǎo)出，篩選出那些核心的表。

這里導(dǎo)出表名、篩選表以及后面的分析表字段，不妨給自己做個工具，我在遇到一些很麻煩的或者感覺以后還可以通用的事情時，就會做成一個小工具，放在一個我給自己起名為javamate的程序中，這些小工具逐漸積累起來你會發(fā)現(xiàn)今后有意想不到的方便。

話說回來，如何判斷哪些是核心表呢，不要著急，我們首先排除掉一些沒用的。拿我在公司分析的系統(tǒng)來說，一共150多個表，其中有好多copy結(jié)尾的是備份，flow結(jié)尾的是流水，rel結(jié)尾的是中間關(guān)聯(lián)表，statistics結(jié)尾的是數(shù)據(jù)統(tǒng)計表，log結(jié)尾的是日志表，config結(jié)尾的是配置表。等等。

排除掉這些對核心業(yè)務(wù)理解無影響的表之后，所剩的也就20來張表，再根據(jù)他們的名字，可以看出好多表是屬于一類的，比如order表就有各種order，按類別再分出來也就四五類，再分析起來就不難了。當(dāng)然如果是更大的體系結(jié)構(gòu)，那就要再不斷做拆解。

再具體分析這些核心表字段之前，還要做一件事就是找出表中間的關(guān)系。如果表b中有個字段叫比如a.id，那么b和a就是一對多的關(guān)系，如果兩個表有rel中間表，那二者就是多對多的關(guān)系，起碼從邏輯上講是這樣的。這個分析過程我也是做了個小工具，通過程序來判斷的。

到此，你就對整體的數(shù)據(jù)庫結(jié)構(gòu)有所了解了。根據(jù)表名也能對表的大致內(nèi)容有所了解，接下來就是針對具體的表，看里面具體的字段和前人給出的備注，這個過程就沒有技巧了，要耐心，要慢慢熬。

五. 深入代碼層

當(dāng)你對數(shù)據(jù)庫表做了以上到了解后，你基本上對這個系統(tǒng)能提供什么服務(wù)了解到差不多了。這個不論你的代碼長什么樣子，數(shù)據(jù)庫擺在那里，其實能提供的服務(wù)就已經(jīng)差不多出來了，對于有經(jīng)驗的人來講，代碼的業(yè)務(wù)邏輯也大致能猜到個八九分。

我認為一個業(yè)務(wù)相關(guān)的項目代碼只分三個部分：

1. 通過交互對自身數(shù)據(jù)庫進行增刪改查操作

2. 通過定時任務(wù)或服務(wù)器腳本對自身數(shù)據(jù)庫進行增刪改查操作

3.?調(diào)用或通知其他服務(wù)做一些事情

如果只是單一項目，無非就是通過各種途徑去玩自己的數(shù)據(jù)庫而已，前兩點足夠了。而如果是微服務(wù)部署，那么加一個第三點足矣。我們將代碼邏輯分成這三個部分看，快速了解一個項目就不成問題，甚至在你沒有看過某一項目而突然有一個bug要你解決時，你也可以按照這種方式去快速定問問題。

通過交互對自身數(shù)據(jù)庫進行增刪改查操作

這個無非是最簡單的一部分，即使復(fù)雜也是代碼較長，表較多而已。所謂的交互，或許是Controller暴露給前端用戶的接口，或許是開一個rpc端口暴露給其他微服務(wù)的接口，總之是第三方去觸發(fā)的。

這里我也給自己做了個小工具，掃描出所有的暴露服務(wù)的接口，展示出方法名，路徑名，參數(shù)列表和返回值等。

和數(shù)據(jù)庫一樣，如果接口很少那么一個個看，如果特別多，還是先找出比較核心的幾個方法研究。這里我用的是postman，把要研究的接口訪問保存起來，并且添加訪問成功和失敗的Example。

這里我推薦自己開發(fā)的時候也把postman用起來，越詳細越好，postman不只是可以簡簡單單訪問你的接口，還能做批量測試，還可以生成api文檔用于和前端交互。這樣你不但測試了自己的接口，還省的寫文檔了。而且postman還有個好處就是可以給自己的接口mock一個服務(wù)，這樣即使你的接口掛了，或者你的接口根本就沒寫好，你可以讓前端人員先訪問你的mock，完全不影響前端邊測試邊開發(fā)，這才是真正的前后端分離嘛。

整理出所有接口后，肯定大部分是很簡單的，一看就懂，一層一層點進去直到數(shù)據(jù)庫層的sql語句，該接口最本質(zhì)的東西就出來了。

如果是復(fù)雜的，那就一步一步debug，花時間總是可以分析的。如果再復(fù)雜的，你可以畫流程圖（這里我比較推薦用processon）。甚至幾個接口圍繞一個功能的，你可以畫狀態(tài)流轉(zhuǎn)圖。比如我之前看我們公司處理訂單業(yè)務(wù)這塊，邏輯確實比較復(fù)雜，我就畫了類似如下的圖：

狀態(tài)流轉(zhuǎn)圖：橫軸代表order_status字段的狀態(tài)，縱軸代表當(dāng)order_status是以上狀態(tài)時，觸發(fā)該接口操作會使該字段發(fā)生什么變化）

接口對表的影響圖：這里你可以把所有涉及到的表以及表中的關(guān)鍵字段列舉出來，然后看分別調(diào)用接口后對各個表字段的影響，變化的就用紅色標(biāo)出

有了這兩種維度的視角，我相信再復(fù)雜的業(yè)務(wù)都能很理清楚，也能發(fā)現(xiàn)某些bug最本質(zhì)的問題。

我正是通過這樣的方式，把一個本來不屬于我的項目短時間內(nèi)了解清楚，快速準(zhǔn)確地修復(fù)了好多頑固的bug。

雖然項目很爛，業(yè)務(wù)邏輯十分混亂，但正是這樣一段時間鍛煉了我深入代碼理清邏輯的能力，也有了自己獨特的一套方法。

定時任務(wù)或服務(wù)器腳本

這個和第一種類型一樣，只不過換了個入口。比如定時任務(wù)，或者啟動的時候就開啟的一些線程。

尋找這些入口的確不是特別容易，比較頭疼，但也只是入口比較隱蔽而已。找到他，記下來，具體分析過程還是按照上述方法去分析，就可以了。

調(diào)用或通知其他服務(wù)做一些事情

代碼中可能有通過mq給其他服務(wù)發(fā)消息，或者直接調(diào)用其他服務(wù)的接口，或者調(diào)用類似云推送的接口讓它去幫忙像mq發(fā)消息。

這部分代碼可能更加隱蔽，但數(shù)量少，邏輯也簡單，你需要做的仍然只是找到它們。這部分也是為了解項目之間的關(guān)系打下伏筆。

這三種類型的代碼研究清楚后，對于一個業(yè)務(wù)型的項目來說，已經(jīng)基本足夠了。

對于一些基礎(chǔ)服務(wù)和中間件類型的服務(wù)，還是得慢慢積累技術(shù)深度才行。由于本篇文章是快速了解一個業(yè)務(wù)型的項目，所以就不展開敘述了。

六. 重新理清項目間的關(guān)系

好了，這時候每個項目你已經(jīng)大致了解，最起碼調(diào)用的效果，數(shù)據(jù)庫所能提供的服務(wù)，甚至某些關(guān)鍵部分的本質(zhì)邏輯，你是清楚的。這個時候，要重新整理下項目之間的關(guān)系。

1. 根據(jù)之前的接口名稱，詳細了解下項目間的調(diào)用關(guān)系。理不清的部分去問老員工，這時候你帶著自己的了解問，他們也能給出更多的信息。

2. 看看每個項目中用到的中間件，主要是mq服務(wù)，看看誰是生產(chǎn)者，誰是消費者，以此來了解關(guān)系

3. 這時你應(yīng)該已經(jīng)開了好幾輪的周會了，接下來的周會你應(yīng)該能聽懂部分內(nèi)容。根據(jù)每個人的描述和最新的幾組需求，逐漸摸清楚現(xiàn)在項目面臨的問題，以及哪個項目是核心，哪個項目是輔助，哪個項目是以穩(wěn)定安全為主的

到此為止，整條業(yè)務(wù)線你就有了大致的了解，接下來就要結(jié)合你具體負責(zé)的內(nèi)容，領(lǐng)導(dǎo)安排你做的方向，去看具體的業(yè)務(wù)代碼了。深入其中，事無巨細地了解。

但此時，你通過前面的努力，你已經(jīng)可以站在一定的高度看每一個項目了，雖然你細節(jié)上還是不了解，但這是完全不同的。

在研究具體業(yè)務(wù)代碼的同時，不斷地跳出來看整條業(yè)務(wù)線的框架，修正之前由于不了解具體業(yè)務(wù)而理解錯誤的架構(gòu)。長此以往，你一定會在某個項目中脫穎而出，讓大家認識到你的全局視野，這也是走出老是寫增刪改查代碼怪圈的一個途徑。

慢慢會有人意識到，你對項目的理解總能站在全局的視野，很多需要跨項目去做的業(yè)務(wù)，也會自然而然想到你，慢慢地，你會接觸到更為核心的東西，成為架構(gòu)師，或者去轉(zhuǎn)向產(chǎn)品，轉(zhuǎn)向管理。

這就是我總結(jié)的了解項目的過程，希望大佬們多多留言指點，提出問題，共同進步。

總結(jié)

以上是生活随笔為你收集整理的没有文档，没有老员工讲解，悲催的新人如何快速熟悉一个新项目？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。