很多新人進入一家新公司後，最頭疼的就是如何快速了解公司的業務和項目架構。或者說不要求快速，給你足夠的時間，也很難在龐大的業務中整理出思緒
很多新人進入一家新公司後，最頭疼的就是如何快速了解公司的業務和項目架構。或者說不要求快速，給你足夠的時間，也很難在龐大的業務中整理出思緒。當然，如果你碰到一個特别熱心的老員工，事無巨細地給你講，随時在你身邊答疑解惑，那可能還好。但很可惜，我沒有碰到這樣的人，在加入新公司後，帶我的人幾乎沒有花時間給我講項目，也沒有給我安排一些可以熟悉項目的需求。就這樣的一個多月時間裡，我慢慢開始靠自己的力量熟悉大概十個項目，并在過程中總結了一些方法，借此機會記錄一下，并分享給大家。
這裡強調一點，我的政策并不是快速了解一個項目的具體業務，這個不同項目也不一樣，無法總結。我的政策是大體了解整個業務線上的所有項目，大概摸清楚每個項目都是幹嘛的，他們之間的關系如何，以便以後不論具體負責任何項目不至于找不到方向，具體到細節的業務，雖然需要花時間，但相比對整體上的一頭霧水，還是簡單許多的。
一. 必要條件
我們首先要想的是，有了哪些必要條件後，隻要給你足夠的時間，你總是能夠完全了解整個項目的？這裡說的必要條件不是“項目面對的客戶是誰”，“項目用的架構是什麼”這種，而是真真正正的必要條件，就好比用幾條數學公理能推出整個數學體系一樣。這裡我總結的真正的必要條件隻有這兩點：
源碼位置（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中間表，那二者就是多對多的關系，起碼從邏輯上講是這樣的。這個分析過程我也是做了個小工具，通過程式來判斷的。
到此，你就對整體的資料庫結構有所了解了。根據表名也能對表的大緻内容有所了解，接下來就是針對具體的表，看裡面具體的字段和前人給出的備注，這個過程就沒有技巧了，要耐心，要慢慢熬。
五. 深入代碼層
當你對資料庫表做了以上到了解後，你基本上對這個系統能提供什麼服務了解到差不多了。這個不論你的代碼長什麼樣子，資料庫擺在那裡，其實能提供的服務就已經差不多出來了，對于有經驗的人來講，代碼的業務邏輯也大緻能猜到個八九分。
我認為一個業務相關的項目代碼隻分三個部分：
1. 通過互動對自身資料庫進行增删改查操作
2. 通過定時任務或伺服器腳本對自身資料庫進行增删改查操作
3. 調用或通知其他服務做一些事情
如果隻是單一項目，無非就是通過各種途徑去玩自己的資料庫而已，前兩點足夠了。而如果是微服務部署，那麼加一個第三點足矣。我們将代碼邏輯分成這三個部分看，快速了解一個項目就不成問題，甚至在你沒有看過某一項目而突然有一個bug要你解決時，你也可以按照這種方式去快速定問問題。
通過互動對自身資料庫進行增删改查操作：這個無非是最簡單的一部分，即使複雜也是代碼較長，表較多而已。所謂的互動，或許是Controller暴露給前端使用者的接口，或許是開一個rpc端口暴露給其他微服務的接口，總之是第三方去觸發的。這裡我也給自己做了個小工具，掃描出所有的暴露服務的接口，展示出方法名，路徑名，參數清單和傳回值等。和資料庫一樣，如果接口很少那麼一個個看，如果特别多，還是先找出比較核心的幾個方法研究。這裡我用的是postman，把要研究的接口通路儲存起來，并且添加通路成功和失敗的Example。這裡我推薦自己開發的時候也把postman用起來，越詳細越好，postman不隻是可以簡簡單單通路你的接口，還能做批量測試，還可以生成api文檔用于和前端互動。這樣你不但測試了自己的接口，還省的寫文檔了。而且postman還有個好處就是可以給自己的接口mock一個服務，這樣即使你的接口挂了，或者你的接口根本就沒寫好，你可以讓前端人員先通路你的mock，完全不影響前端邊測試邊開發，這才是真正的前後端分離嘛。整理出所有接口後，肯定大部分是很簡單的，一看就懂，一層一層點進去直到資料庫層的sql語句，該接口最本質的東西就出來了。如果是複雜的，那就一步一步debug，花時間總是可以分析的。如果再複雜的，你可以畫流程圖（這裡我比較推薦用processon）。甚至幾個接口圍繞一個功能的，你可以畫狀态流轉圖。比如我之前看我們公司處理訂單業務這塊，邏輯确實比較複雜，我就畫了類似如下的具有程式員視角的狀态流轉圖（這裡隻是示例圖）：
狀态流轉圖：橫軸代表order_status字段的狀态，縱軸代表當order_status是以上狀态時，觸發該接口操作會使該字段發生什麼變化）
| 0-待支付 | 1-已支付 | 2-已取消 | 3-退款中 | 4-已退款 | 5-退款失敗 | |
| 支付成功異步通知來了 | -->1 | 報錯 | ||||
| 使用者發起退款 | -->3 | |||||
| 退款成功異步通知來了 | -->4 | |||||
| 退款失敗異步通知來了 |
接口對表的影響圖：這裡你可以把所有涉及到的表以及表中的關鍵字段列舉出來，然後看分别調用接口後對各個表字段的影響，變化的就用紅色标出
有了這兩種次元的視角，我相信再複雜的業務都能很理清楚，也能發現某些bug最本質的問題。我正是通過這樣的方式，把一個本來不屬于我的項目短時間内了解清楚，快速準确地修複了好多頑固的bug。雖然項目很爛，業務邏輯十分混亂，但正是這樣一段時間鍛煉了我深入代碼理清邏輯的能力，也有了自己獨特的一套方法。
通過定時任務或伺服器腳本對自身資料庫進行增删改查操作：這個和第一種類型一樣，隻不過換了個 入口。如果有些問題你發現并不是互動而産生的，那你就要尋找其他入口。比如定時任務，或者啟動的時候就開啟的一些線程。尋找這些入口的确不是特别容易，比較頭疼，但也隻是入口比較隐蔽而已。找到他，記下來，具體分析過程還是按照上述方法去分析，就可以了。
調用或通知其他服務做一些事情：上述兩種代碼如果你都摸得差不多了，整個項目對自身的玩法基本你已經摸透了，那還剩一小部分就是它和其他服務之間的互動。代碼中一定有通過mq給其他服務發消息，或者直接調用其他服務的接口，或者調用類似雲推送的接口讓它去幫忙像mq發消息。總之不管形式如何，都隻是為了rpc其他服務而已。這部分代碼可能更加隐蔽，但數量少，邏輯也簡單，你需要做的仍然隻是找到它們。這部分也是為了解項目之間的關系打下伏筆。
這三種類型的代碼研究清楚後，對于一個業務型的項目來說，已經基本足夠了。對于一些基礎服務和中間件類型的服務，還是得慢慢積累技術深度才行，了解過程仍然也是可以有規律的，隻不過需要更底層的方式去分類，比如将代碼分成資源的加載，模式的比對，等等。由于本篇文章是快速了解一個業務型的項目，是以就不展開叙述了。
六. 重新理清項目間的關系
好了，這時候每個項目你已經大緻了解，最起碼調用的效果，資料庫所能提供的服務，甚至某些關鍵部分的本質邏輯，你是清楚的。這個時候，要重新整理下項目之間的關系。
- 根據之前的接口名稱，詳細了解下項目間的調用關系。理不清的部分去問老員工，這時候你帶着自己的了解問，他們也能給出更多的資訊。
- 看看每個項目中用到的中間件，主要是mq服務，看看誰是生産者，誰是消費者，以此來了解關系
- 這時你應該已經開了好幾輪的周會了，接下來的周會你應該能聽懂部分内容。根據每個人的描述和最新的幾組需求，逐漸摸清楚現在項目面臨的問題，以及哪個項目是核心，哪個項目是輔助，哪個項目是以穩定安全為主的
到此為止，整條業務線你就有了大緻的了解，接下來就要結合你具體負責的内容，上司安排你做的方向，去看具體的業務代碼了。深入其中，事無巨細地了解。但此時，你通過前面的努力，你已經可以站在一定的高度看每一個項目了，雖然你細節上還是不了解，但這是完全不同的。在研究具體業務代碼的同時，不斷地跳出來看整條業務線的架構，修正之前由于不了解具體業務而了解錯誤的架構。長此以往，你一定會在某個項目中脫穎而出，讓大家認識到你的全局視野，這也是走出老是寫增删改查代碼怪圈的一個途徑。慢慢會有人意識到，你對項目的了解總能站在全局的視野，很多需要跨項目去做的業務，也會自然而然想到你，慢慢地，你會接觸到更為核心的東西，成為架構師，或者去轉向産品，轉向管理。
這就是我總結的了解項目的過程，希望大佬們多多留言指點，提出問題，共同進步。
公衆号 - 低并發程式設計