作為一個程序員，我們很少能從頭到尾參與一個新項目的開發。如果你經常開發的是新項目，那你真是太幸福了。
更多的情況是半路進入一個項目組進行開發，或者是有其他同事離職了，之前由他維護的系統轉交給你維護。
還有一種情況就是領導不知道從哪里弄過來一個系統和一堆文檔，然后就直接就把系統交給你了維護了。
遇到以上幾種情況我們怎樣才能快速熟悉上手項目，應對生產問題呢？下面是我自己在工作中的一點總結，希望能對大家有所幫助。
資料要要全
當你接手一個新項目（別人的項目）的時候，你要第一時間向把項目移交給你的人要到所有的資料。因為在這之后，這個同事可能就會離職了，到時再要什么文檔就不太方便了。一般情況下，你需要拿到這些資料：
- 項目代碼的地址（svn地址或者是git地址）；
- 系統部署的Linux機器地址，登陸的用戶名和密碼（方便登陸上去看看機器的運行狀況）
- 數據庫地址/用戶名/密碼（不要以為所有項目中都會有用戶名密碼，有些項目會將用戶名密碼加密）
- 系統的登陸用戶/密碼（如果系統有頁面，將可以登陸的用戶要一個，不用自己再造用戶了）
- 其他中間件地址（MQ、Redis等）
- 需求文檔
- 接口文檔
- 其他所有資料（上面的文檔時必須的，如果除此之外還能拿到其他文檔，都可以保存下來）
技術棧要看懂
拿到文檔資料后，我個人的經驗是先要快速瀏覽下文檔（業務文檔，需求文檔或者接口文檔等），不需要看清文檔的每個段落，但是我們要通過略讀文檔知道這個系統大概是干什么的，有哪些功能。這點對我們后續看代碼幫助很大。
熟悉項目技術棧
快速瀏覽完文檔之后，我們就要開始看代碼了。這個階段，你需要能將代碼在本地跑起來，知道這個項目運用了哪些技術棧（看看項目依賴了哪些外部包大致可以看出來這個系統用了哪些技術），每個技術棧的作用是什么。
熟悉系統的表設計
系統的表設計是整個系統的核心，只有熟悉了表設計，才能對整個系統的功能有大致的了解。熟悉表設計也是看懂業務代碼的前置條件。
熟悉上下游系統
搞清楚了上下游系統，我們就知道了誰調用了我們系統，或是我們的系統調用了誰，查起問題來也能有的放矢。
知道去哪里查日志
日志是查線上問題的關鍵，必須要知道怎么查日志，去哪里查日志。
知道怎么打包
接了新需求或者改了Bug之后你肯定要發布吧，那你必須要知道這個怎么打包部署。
知道怎么部署
同上
熟悉業務代碼
到了最關鍵的一步了，但是對於這步我覺得不同的系統我們可以區別對待下。有的系統我們接手過來是要在此基礎上長期開發維護的，那這種系統就需要我們好好梳理下業務。
但是有的系統比較穩定了，也不會再加什么新功能，對於這種系統要不要深入研究就需要我們自己權衡了。因為時間成本上可能划不來。
下面是我熟悉業務的一般流程：
-
step1：在看業務代碼之前，首先需要看完數據庫的表設計，不然會不知所雲。
-
step2：然后就是梳理各個接口了，一般是各個Controller（一般系統功能都是通過Controller暴露出去的），如果你能每個接口跟進去debug一遍，整個調用流程都梳理清楚，那么這個業務你就梳理清楚了（這步最好根據接口文檔來梳理）
-
step3：當然，系統的功能不都是由Controller提供的，有的是通過定時任務來觸發的，所以你要看看系統中配置了哪些定時任務，都實現哪些功能；
-
step4：還有的功能是通過消費MQ觸發的，所以也要看看有沒MQ相關的交互；
-
step5：類似其他的交互
關於熟悉業務代碼這塊可能沒有太通用的方法，還是需要大家自己總結。