大家好，我是 Z 哥。

所謂“跳槽爽，一直跳槽一直爽”。但是，世上哪有那么好的事哦，跳槽雖然可以帶來更快的漲薪機會，但是你也是要面對和克服一些新挑戰的，其中最大的挑戰莫過于要熟悉一個陌生的項目。畢竟，進入到一個新的團隊，又恰好遇到做的是一個新項目，這個概率就太小了。

對我們程序員來說，這里的陌生項目就是一套陌生的源碼。

有時候如果運氣好，有一位帶教老師或者熱心的同事來幫助你熟悉項目，那自然會輕松很多，速度也更快。

但是如果你運氣沒那么好，或者去到了一個人員緊張的快速發展期企業，那就只能靠你自己了。這個時候如果你掌握了一些快速熟悉項目的技巧，會對你有很大幫助。

否則，因為沒能在一定時間內對項目有足夠的了解，導致工作完成得不好，進一步導致沒過試用期，那就麻煩大了。

很多人熟悉項目，先從其中用到的中間件開始。這個思路其實不太好，雖然中間件是通用的，在哪個項目里都能用，所以比較容易下手。但是具體怎么用，承擔了什么職責，在一些細節上，不同項目會有所不同。

所以從中間件入手去熟悉項目，就猶如管中窺豹，了解的并不全面，甚至可能會判斷錯誤。

在 Z 哥的職業生涯中，大多數時候都沒有什么人來指導，自己摸石頭過河熟悉過大大小小十幾個項目，也積累了一些經驗，在這里和大家交流一下。也歡迎你在評論區分享你的好方法。

我的思路總共分為 5 步。我相信，沿著這個思路來熟悉項目，不敢說對項目了如指掌吧，至少可以在短時間內了解項目的 6、7 分。

/01? 從哪里來/

“從哪里來，到哪里去”是一個著名的哲學問題，其實這個邏輯也適用于我們熟悉一個陌生項目。

大部分情況下，技術都是為業務服務的，所以任何項目都是為了解決某一個問題而誕生的，因此，「從哪里來」自然藏在業務里。

建議可以從以下兩個問題入手，搞清楚了這兩個問題，相信你也知道了這個項目的由來。

誰在用這個系統？

用這個系統做什么？

其實你會發現，這兩個問題構建的是一個畫面，一個人或者一群人在如何使用這個系統進行工作的畫面。這其實就是所謂的工作場景，它們也解答了「從哪里來」這個問題。

舉個例子，比如說你接手了一個消息通知類的系統，那么經過了解會得到這樣的一條信息。

運營人員會用這個系統發送APP通知、短信通知等，以此來觸達消費者，并引導用戶促成交易轉化。

進一步你也會知道，這個系統的職責就是編輯通知內容、發送通知、記錄觸達的結果。如果更進一步的話，還能考慮到點擊率、轉化率等數據記錄，因為這些數據可以更好的幫助操作人完成他的工作目的，“促成更多的交易”。

/02? 到哪里去/

第一步搞清楚了「從哪里來」，下一步搞清楚「到哪里去」。

「到哪里去」就是搞清楚這個項目生命周期，這個項目實際是如何運轉創造價值的。這其實也是必要的一個前期準備工作。畢竟不管做任何事，有準備總是更好的。沒有準備，談何事半功倍呢。

第一步主要需要做兩件事：

知道源碼在哪里。

搞清楚項目運行涉及到的環境。這里的環境不僅僅是生產環境，還有各個測試環境和 CI / CD 機制。

只要知道了這兩項內容，其實你對這個項目的「生命周期」就了解的很清楚了。知道了它是如何流轉的，就相當于知道了它到哪里去。

/03? 梳理技術鏈路/

在第一步中我們做的工作其實間接也算梳理了一遍業務鏈路。基于這個信息其實我們也可以進行技術鏈路的梳理了。

對于技術鏈路的梳理，我的建議是，「先縱再橫」。

「縱」就是沿著一條線從前往后梳理，一般從應用側開始， 應該很多人也的確是這么干的。比如上面我們在前面例子中提到的通知系統，一般是，UI -> API -> MQ / DB -> 各個通知渠道的 Service -> DB。

「橫」就是對梳理出來的多條「縱」的技術鏈路進行整理，找到其中的共同點以及相關性。這些共同點大多會由一個通用組件/ Service 來滿足需求，而相關性則代表著多個業務鏈路之間的「耦合」關系。

當然，如果你參與到的是一個超大型項目，很多「縱」其實已經單獨做成一個子系統了，這個時候對「橫」的梳理，其實就是對子系統之間的梳理。

注意，做技術鏈路梳理的時候，不需要陷入到代碼細節里去，只要大致知道不同 class 之間的引用關系如何即可。如果你提前深入到代碼細節里去，那么一但遇到復雜度較高的項目，你很容易產生焦慮感。

/04? 梳理數據表/

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

工欲善其事必先利其器，梳理數據表我平時最喜歡用的工具是 Red Gate 里的 SQL Doc 和 SQL Dependency Tracker。前者可以自動根據數據庫的信息生成方便查看的文檔，后者可以生成圖表查看數據之間的關系，很好用。

如果遇到一個表數量達到 3 位數的時候，怎么能快速定位核心表呢，有 2 個小技巧。

忽略 config、log、flow、statistics 為后綴或者前綴的表，這些的表的作用從名字也能看出來作用，必然不會包含什么核心業務信息。

從一些前綴統一的表，但是前綴不屬于上面 4 個單詞的表開始。比如 order、trade 這種，一般越核心的業務，往往基于它前綴所擴展出來的表也越多。

/05? 運行并調試一下/

調試是一個有效的 Debug 方式，也是一個有效理解代碼的方式。我們進行調試的目的倒不是為了弄清楚某一個業務的細節，而是通過調試來觀察數據的流轉情況，驗證自己對之前做的這些信息整理所形成的猜想是否屬實。

因此，盡量挑選一個你認為業務最復雜的頁面，然后對頁面上的每個按鈕都去點一下看看。在這個期間你還能加強對前后端之間通訊方式的理解。

前陣子寫過一篇《幫助閱讀源碼的 8 個技巧》，里面有些思路其實是類似的。

最后再多說幾句感想，我知道有很多人在熟悉項目的時候會吐槽原來的設計多么多么垃圾。我勸大家善良，因為可能未來接手你現在負責的這個項目的人也會這么吐槽你。但實際上我相信每個人在當時作出的決策設計，一定是在當時綜合各方因素后的最優解，畢竟沒有人那么傻，明知故錯。

另外，以下這三點也是在我們熟悉項目的過程中可以相信的事情。

• 你遇到的問題很多人已經遇到過并且解決了 。?

• 你遇到的問題大概率在當前系統里面已經有了答案。?

• 你遇到的問題大概率在你用的框架和組件里面都有現成的解決方案。

好了，總結一下。

這篇呢，Z 哥和你分享了我對如何快速熟悉一個項目的經驗。我的思路主要分為 5 步：

從哪里來

到哪里去

梳理技術鏈路

梳理數據表

運行并調試一下

希望對你有所幫助。

對很多人來說，更愿意重頭做一個新系統而不是去接手一個老系統。不過，老系統其實滿是寶藏，里面有很多你可以借鑒和學習的東西。

推薦閱讀：

• 這個時代最重要的技能之一
  

• 對DDD的常見誤區
  

原創不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創作 ：）

也可以分享我的公眾號名片給有需要的朋友們。

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

以上是生活随笔為你收集整理的每次跳槽，总得面对这摊事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。