研發新人如何快速熟悉新項目和業務(上）

進入一家新公司後，最頭疼的就是如何快速了解公司的業務和項目架構。

如果碰到一個特别熱心的老員工，事無巨細地給你講，随時在你身邊答疑解惑，那可能還好。但很可惜，我沒有碰到這樣的人，在加入新公司後，帶我的人幾乎沒有花時間給我講項目，也沒有給我安排一些可以熟悉項目的需求。就這樣的一個多月時間裡，我慢慢開始靠自己的力量熟悉大概十個項目，并在過程中總結了一些方法，借此機會記錄一下，并分享給大家。

注意，這裡的政策并非快速了解一個項目的具體業務，這個不同項目也不一樣，無法總結。

我的政策是大體了解整個業務線上的所有項目，大概摸清楚每個項目都是幹嘛的，他們之間的關系如何，以便以後不論具體負責任何項目不至于找不到方向，具體到細節的業務，雖然需要花時間，但相比對整體上的一頭霧水，還是簡單許多。

1 業務的本質

并非項目面對的客戶是誰啊？、項目用的啥架構啊？而是真的能推出所有現存業務的，僅如下兩點：

1. 源碼位置（如gitlab）
2. 部署環境（dev生産/test測試/online線上環境）

項目，其實就是一堆機器上的一堆代碼。為節約時間，最好還有wiki、jenkins、頁面通路路徑、資料庫位址，我之是以說那兩個必要條件，是想說其實項目本質上就是這麼簡單的一個事，你千萬不要想的太複雜。

業務再複雜，但本質卻逃不出這些，你千萬不可以糊塗。當你無從下手或者什麼都不清楚的時候，那麼就主要把源碼和環境弄清楚吧，其它的都是附屬品。

2 從頁面到資料庫的線

有了上面的必要條件後，我們就開始了解項目了。由于不隻是一個項目，是以千萬不要深入具體代碼，否則你就越來越煩直到放棄，也不會有好的效果。

對某個具體項目的了解，一定要建立在對整體了解的基礎上。這時我們首先為各個項目畫出一條線，并标明每一個節點的資訊，就像下面的樣子：

頁面通路路徑–前端項目–背景服務–資料庫位址

一個前端項目可能對應多個背景服務，是以最終圖差不多這樣：

這個整理的過程，主要是讓自己梳理清楚，有哪些項目，哪些是前端可視，哪些是背景提供服務。

了解到前端項目分别調用哪些背景服務，通過背景服務和資料庫名稱，能從本質上了解到這條業務線提供了什麼功能，從前端項目和頁面路徑，我們能了解到我們需要給使用者展示什麼，即注意輸入輸出。

注意，這個階段我們隻是見名知意，即使點開頁面，連接配接上資料庫看看，也千萬别花過多的時間，這個階段的重點就是僅僅知道，這條業務線提的整體内容。

在此基礎上，這個圖可以不斷細化，比如項目部署的機器，可以标注在項目旁，或儲存在xshell。

此外所有非業務相關的，能查到的盡量都記錄下來，這個真的為以後找各種東西友善太多了，否則别看你現在節約了時間，把以後查找相關東西的時間加起來，将會是天文數字了。

由于這部分的資訊沒人會一個一個地告訴你，就算有也不可能說的特别全。是以我是借助jenkins來整理的。項目部署都需要用到jenkins，隻要檢視jenkins配置的指令，就可以把部署環境一一整理出來，這個我認為是最全而且最新的。不要和我說查wiki，如果公司wiki都寫的這麼全，我估計就沒這篇文章什麼事了。當時我的jenkins權限特别少，隻能看一部分項目，而且還隻能執行，不能看配置，帶我的人也是摳門，每次問他都給我開通所需要的項目的執行權限，多一點都不給。後來我也懶得問了，由于jenkins機器大家都可以用root權限登陸，是以我進入jenkins的配置檔案config.xml，給我自己添加了一個admin權限，重新開機jenkins，再打開之後螢幕滿滿的項目都出來了，而且都可以檢視和修改，暢通無阻。我就這樣通過一個個jenkins的配置，整理了部署的機器，也看了下啟動的邏輯。

3 了解項目間的關系

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

4 整理資料庫表

上面都是整理項目的大體架構，還沒有涉及到具體的項目細節。這一部分，仍然不去涉及。如果說站在整個業務的本質上看，業務無非就是一堆代碼運作在一堆機器上。那麼站在單個項目來看，一個項目無非就是對資料庫的增删改查操作而已，或者從使用者的角度看，一個項目就是輸入一些參數得到一些傳回結果。是以接下來我們要做兩件事，一個是整理資料庫表，一個是整理Controller層的所有接口。

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

如果資料庫的表比較少，那我們拿工具導出來表結構，一個個看就行了，這個不難。但如果資料庫表特别多，我們首先要将表名全部導出，篩選出那些核心的表。這裡導出表名、篩選表以及後面的分析表字段，不妨給自己做個工具，我在遇到一些很麻煩的或者感覺以後還可以通用的事情時，就會做成一個小工具，放在一個我給自己起名為javamate的程式中，這些小工具逐漸積累起來你會發現今後有意想不到的友善。

話說回來，如何判斷哪些是核心表呢，不要着急，我們首先排除掉一些沒用的。拿我在公司分析的系統來說，一共150多個表，其中有好多copy結尾的是備份，flow結尾的是流水，rel結尾的是中間關聯表，statistics結尾的是資料統計表，log結尾的是日志表，config結尾的是配置表。等等。排除掉這些對核心業務了解無影響的表之後，所剩的也就20來張表，再根據他們的名字，可以看出好多表是屬于一類的，比如order表就有各種order，按類别再分出來也就四五類，再分析起來就不難了。當然如果是更大的體系結構，那就要再不斷做拆解。

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

到此，你就對整體的資料庫結構有所了解了。根據表名也能對表的大緻内容有所了解，接下來就是針對具體的表，看裡面具體的字段和前人給出的備注，這個過程就沒有技巧了，要耐心，要慢慢熬。