作為一個程式設計師，我們很少能從頭到尾參與一個新專案的開發。如果你經常開發的是新專案，那你真是太幸福了。

更多的情況是半路進入一個專案組進行開發，或者是有其他同事離職了，之前由他維護的系統轉交給你維護。

還有一種情況就是領導不知道從哪裡弄過來一個系統和一堆文件，然後就直接就把系統交給你了維護了。

遇到以上幾種情況我們怎樣才能快速熟悉上手專案，應對生產問題呢？下面是我自己在工作中的一點總結，希望能對大家有所幫助。

資料要要全

當你接手一個新專案（別人的專案）的時候，你要第一時間向把專案移交給你的人要到所有的資料。因為在這之後，這個同事可能就會離職了，到時再要什麼文件就不太方便了。一般情況下，你需要拿到這些資料：

• 專案程式碼的地址（svn地址或者是git地址）；
• 系統部署的Linux機器地址，登陸的使用者名稱和密碼（方便登陸上去看看機器的執行狀況）
• 資料庫地址/使用者名稱/密碼（不要以為所有專案中都會有使用者名稱密碼，有些專案會將使用者名稱密碼加密）
• 系統的登陸使用者/密碼（如果系統有頁面，將可以登陸的使用者要一個，不用自己再造使用者了）
• 其他中介軟體地址（MQ、Redis等）
• 需求文件
• 介面文件
• 其他所有資料（上面的文件時必須的，如果除此之外還能拿到其他文件，都可以儲存下來）

技術棧要看懂

拿到文件資料後，我個人的經驗是先要快速瀏覽下文件，不需要看清文件的每個段落，但是我們要通過略讀文件知道這個系統大概是幹什麼的，有哪些功能。這點對我們後續看程式碼幫助很大。

熟悉專案技術棧

快速瀏覽完文件之後，我們就要開始看程式碼了。這個階段，你需要能將程式碼在本地跑起來，知道這個專案運用了哪些技術棧，每個技術棧的作用是什麼。

熟悉上下游系統

搞清楚了上下游系統，我們就知道了誰呼叫了我們系統，或是我們的系統呼叫了誰，查起問題來也能有的放矢。

知道去哪裡查日誌

日誌是查線上問題的關鍵，必須要知道怎麼查日誌，去哪裡查日誌。

知道怎麼打包

接了新需求或者改了Bug之後你肯定要釋出吧，那你必須要知道這個怎麼打包部署。

知道怎麼部署

同上

熟悉業務程式碼

到了最關鍵的一步了，但是對於這步我覺得不同的系統我們可以區別對待下。有的系統我們接手過來是要在此基礎上長期開發維護的，那這種系統就需要我們好好梳理下業務。

但是有的系統比較穩定了，也不會再加什麼新功能，對於這種系統要不要深入研究就需要我們自己權衡了。因為時間成本上可能划不來。

下面是我熟悉業務的一般流程：

• step1：在看業務程式碼之前，首先需要看完資料庫的表設計，不然會不知所云。

• step2：然後就是梳理各個介面了，一般是各個Controller（一般系統功能都是通過Controller暴露出去的），如果你能每個介面跟進去debug一遍，整個呼叫流程都梳理清楚，那麼這個業務你就梳理清楚了（這步最好根據介面文件來梳理）

• step3：當然，系統的功能不都是由Controller提供的，有的是通過定時任務來觸發的，所以你要看看系統中配置了哪些定時任務，都實現哪些功能；

• step4：還有的功能是通過消費MQ觸發的，所以也要看看有沒MQ相關的互動；

• step5：類似其他的互動

關於熟悉業務程式碼這塊可能沒有太通用的方法，還是需要大家自己總結