轉載自：https://www.toutiao.com/a6599078103778066947/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1539844728&app=news_article&utm_source=weixin&iid=46282795224&utm_medium=toutiao_android&group_id=6599078103778066947

很多新人進入一家新公司後，最頭疼的就是如何快速了解公司的業務和項目架構，或者說不要求快速，即便有足夠的時間，也很難在龐大的業務中整理出思緒。當然，如果你碰到一個特別熱心的老員工，事無巨細地給你講，隨時在你身邊答疑解惑，那可能還好。

但很可惜，我沒有碰到這樣的人，在加入新公司後，帶我的人幾乎沒花時間給我講項目，也沒給我安排可以熟悉項目的任務。

就這樣的一個多月時間裏，我慢慢靠自己的力量熟悉了大概十個項目，並在過程中總結了一些方法，借此機會記錄一下，分享給大家。

首先在這裏強調一點，我的策略不是快速了解一個項目的具體業務，因為這個不同項目也不一樣，無法總結。我的策略是大體了解整個業務線上的所有項目，大概摸清楚每個項目都是幹嘛的，它們之間的關系如何，以便以後不論具體負責哪個項目都不至於找不到方向。

這樣等到需要負責具體到細節的業務時，雖然依然需要花時間，但相比整體一頭霧水地開始，還是簡單許多的。

一、必要條件

我們首先要想的是，有了哪些必要條件後，給你足夠的時間，你才能夠完全了解整個項目？

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

• 源碼位置（gitlab或svn）；

• 部署環境（dev/test/online）；

所謂項目，其實就是一堆代碼放在了一堆機器上而已，所以這些就足夠了。

當然，為了更加節約時間，最好還要有wiki、jenkins、頁面訪問路徑、數據庫地址。

我之所以說那兩個是必要條件，是想說其實項目本質上就是這麽簡單的一個事，你千萬不要想的太復雜。它的業務可以無限復雜，但它的本質卻逃不出這些，你千萬不可以糊塗。當你無從下手或者什麽都不清楚的時候，就主要把源碼和環境弄清楚吧，其它的都是附屬品。

二、從頁面到數據庫的線

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

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

頁面訪問路徑——前端項目——後臺服務——數據庫地址

這裏的一個前端項目可能對應多個後臺服務，所以最終的圖應該差不多是這樣：

這個整理的過程，主要是讓自己梳理清楚，一共有哪些項目，哪些是前端可視的，哪些是後臺提供服務的，並且大致了解前端項目分別調用了哪些後臺服務。通過後臺服務和數據庫的名稱，我們能從本質上了解到這條業務線提供了什麽功能；從前端項目和頁面路徑，我們能了解到我們需要給用戶展示什麽。

註意，這個階段我們只是見名知意，即使點開頁面，連接上數據庫看看，也千萬別花過多的時間，因為這個階段的重點就是僅僅知道這條業務線提的整體內容。

在此基礎之上，這個圖可以不斷細化，比如項目部署的機器，我們可以標註在項目旁邊，或者保存在Xshell裏。此外所有非業務相關的，能查到的盡量都記錄下來。這個真的為以後找各種東西提供太多方便了。如果不在這一步這樣做，別看你現在節約了時間，但等到以後查找相關東西的時候，時間加起來將會是天文數字了。

這裏關於整理項目部署的機器還有個小插曲，跟大家分享一下。

由於這部分的信息沒人會一個一個地告訴你，就算有也不可能說的特別全。所以我是借助jenkins來整理的。項目部署都需要用到jenkins，只要查看jenkins配置的命令，就可以把部署環境一一整理出來，這個我認為是最全而且最新的。

不要和我說查wiki，如果公司wiki都寫的這麽全，我估計就沒這篇文章什麽事了。當時我的jenkins權限特別少，只能看一部分項目，而且還只能執行，不能看配置，帶我的人也是摳門，每次問他都給我開通所需要的項目的執行權限，多一點都不給。後來我也懶得問了，由於jenkins機器大家都可以用root權限登陸，所以我進入jenkins的配置文件config.xml，給我自己添加了一個admin權限，重啟jenkins，再打開之後屏幕滿滿的項目都出來了，而且都可以查看和修改，暢通無阻。我就這樣通過一個個jenkins的配置，整理了部署的機器，也看了下啟動的邏輯。

三、了解項目間的關系

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

四、整理數據庫表

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

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

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

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

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

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

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

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

五、整理Controller層接口

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

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

這裏我也給自己做了個小工具，掃描出所有的controller層的接口，展示出方法名、路徑名、參數列表和返回值等，但可惜沒能展示註釋，有大神有想法的話也歡迎幫我想想。

和數據庫一樣，如果接口很少，那麽一個個看；如果特別多，還是先找出比較核心的幾個方法研究。

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

六、重新理清項目間的關系

好了，這時候每個項目你已經大致了解，最起碼調用的效果，數據庫所能提供的服務，你是清楚的。至此，就要重新整理下項目之間的關系了。

• 根據之前的接口名稱，詳細了解下項目間的調用關系。理不清的部分去問老員工，這時候你帶著自己的了解問，他們也能給出更多的信息。

• 看看每個項目中用到的中間件，主要是mq服務，看看誰是生產者，誰是消費者，以此來了解關系。

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

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

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

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

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

這就是我總結的了解項目的過程，我工作年限不多，經驗上還不夠豐富，希望大佬們多多留言指點，提出問題，共同進步。

加入新公司，怎樣快速熟悉業務和項目？