如何快速熟悉一個新項目

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

 

由於文檔不多，沒有文檔，或者是文檔嚴重落伍， 根本無法看；若是你碰到一個特別熱心的老員工，事無鉅細地給你講，隨時在你身邊答疑解惑， 那簡直是天大的好運氣， 現實是你們都很忙，沒人給你講解。

 

很快就要深刻項目作開發了，怎麼辦呢？

 

我在加入新公司後，就遇到了悲催的狀況。可是在一個多月時間裏，我靠本身的力量熟悉了大概十個項目，總結了一些方法，分享給你們。

 

這裏強調一點，個人策略是大致瞭解整個業務線上的全部項目，大概摸清楚每一個項目都是幹嗎的，他們之間的關係如何，以便之後具體項目時不至於找不到方向，具體到細節的業務，固然還須要花時間，但相比對總體上的一頭霧水，仍是簡單許多的。

 

一. 必要條件

 

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

 

源碼位置（gitlab或svn）

 

部署環境（dev/test/online）

 

所謂項目，其實就是一堆代碼放在了一堆機器上而已，因此這些就足夠了。固然，爲了更加節約時間，也要得到wiki、jenkins、頁面訪問路徑、數據庫地址等相關信息。

 

我之因此說那兩個必要條件，是想說其實項目本質上就是這麼簡單的一個事，你千萬不要想的太複雜。

 

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

 

二. 從頁面到數據庫

 

有了上面的必要條件後，咱們就開始瞭解項目了。因爲不僅是一個項目，因此千萬不能深刻具體代碼，不然你就愈來愈煩，懷疑人生，很快放棄。

 

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

 

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

 

這裏的一個前端項目可能對應多個後臺服務，因此最終的圖應該差很少是這樣：

 

 

這個整理的過程，主要是讓本身梳理清楚，一共有哪些項目，哪些是前端可視的，哪些是後臺提供服務的。

 

瞭解前端項目分別調用了哪些後臺服務，經過後臺服務和數據庫的名稱，咱們能從本質上了解到這條業務線提供了什麼功能，從前端項目和頁面路徑，咱們能瞭解到咱們須要給用戶展現什麼。

 

注意，這個階段咱們只是見名知意，即便點開頁面，鏈接上數據庫看看，也千萬別花過多的時間，這個階段的重點就是僅僅知道，這條業務線提的總體內容。

 

在此基礎之上，這個圖能夠不斷細化，好比項目部署的機器，咱們能夠標註在項目旁邊，或者保存在xshell裏。此外全部非業務相關的，能查到的儘可能都記錄下來，這個真的爲之後找各類東西方便太多了，不然別看你如今節約了時間，把之後查找相關東西的時間加起來，將會是天文數字了。

 

這裏關於整理項目部署的機器還有個小插曲，跟你們分享一下。因爲這部分的信息沒人會一個一個地告訴你，就算有也不可能說的特別全。因此我是藉助jenkins來整理的。項目部署都須要用到jenkins，只要查看jenkins配置的命令，就能夠把部署環境一一整理出來，這個我認爲是最全並且最新的。

 

不要和我說查wiki，若是公司wiki都寫的這麼全，我估計就沒這篇文章什麼事了。當時個人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是以上狀態時，觸發該接口操做會使該字段發生什麼變化）

 

 

接口對錶的影響圖：這裏你能夠把全部涉及到的表以及表中的關鍵字段列舉出來，而後看分別調用接口後對各個表字段的影響，變化的就用紅色標出

 

有了這兩種維度的視角，我相信再複雜的業務都能很理清楚，也能發現某些bug最本質的問題。

 

我正是經過這樣的方式，把一個原本不屬於個人項目短期內瞭解清楚，快速準確地修復了好多頑固的bug。

 

雖然項目很爛，業務邏輯十分混亂，但正是這樣一段時間鍛鍊了我深刻代碼理清邏輯的能力，也有了本身獨特的一套方法。

 

定時任務或服務器腳本

 

這個和第一種類型同樣，只不過換了個入口。好比定時任務，或者啓動的時候就開啓的一些線程。

 

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

 

調用或通知其餘服務作一些事情

 

代碼中可能有經過mq給其餘服務發消息，或者直接調用其餘服務的接口，或者調用相似雲推送的接口讓它去幫忙像mq發消息。

 

這部分代碼可能更加隱蔽，但數量少，邏輯也簡單，你須要作的仍然只是找到它們。這部分也是爲了解項目之間的關係打下伏筆。

 

這三種類型的代碼研究清楚後，對於一個業務型的項目來講，已經基本足夠了。

 

對於一些基礎服務和中間件類型的服務，仍是得慢慢積累技術深度才行。因爲本篇文章是快速瞭解一個業務型的項目，因此就不展開敘述了。

 

六. 從新理清項目間的關係

 

好了，這時候每一個項目你已經大體瞭解，最起碼調用的效果，數據庫所能提供的服務，甚至某些關鍵部分的本質邏輯，你是清楚的。這個時候，要從新整理下項目之間的關係。

 

1. 根據以前的接口名稱，詳細瞭解下項目間的調用關係。理不清的部分去問老員工，這時候你帶着本身的瞭解問，他們也能給出更多的信息。

 

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

 

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

 

到此爲止，整條業務線你就有了大體的瞭解，接下來就要結合你具體負責的內容，領導安排你作的方向，去看具體的業務代碼了。深刻其中，事無鉅細地瞭解。

 

但此時，你經過前面的努力，你已經能夠站在必定的高度看每個項目了，雖然你細節上仍是不瞭解，但這是徹底不一樣的。

 

在研究具體業務代碼的同時，不斷地跳出來看整條業務線的框架，修正以前因爲不瞭解具體業務而理解錯誤的架構。久而久之，你必定會在某個項目中脫穎而出，讓你們認識到你的全局視野，這也是走出總是寫增刪改查代碼怪圈的一個途徑。

 

慢慢會有人意識到，你對項目的理解總能站在全局的視野，不少須要跨項目去作的業務，也會天然而然想到你，慢慢地，你會接觸到更爲核心的東西，成爲架構師，或者去轉向產品，轉向管理。