專案好與不好，它就在那裡；架構優雅或者醜陋，它就在那裡；註釋有或者沒有，它還在那裡；文件亂或者不亂，它始終都在那裡。不論它是什麼樣子的，線上就那樣跑著。
一般來講，專案分為兩種：
1、為業務服務的專案，比如公司內部專案、電商專案、各種 app 專案；
2、為技術服務的專案，比如開源中介軟體專案（dubbo、spring cloud、各種資料庫中介軟體、各種快取方案等）；
首先說第二種專案，它專注於提供某一個或幾個特定的功能。相對來說，這種專案技術實現上可能需要對這一領域有比較深的要求，但職責單一，目標明確。而且這種專案都是面向開發人員的，所以設計文件、介面文件、使用文件都會比較齊全。而且這種專案一般都會承擔比較核心、比較重要的功能，並且還會在公司內部開放，甚至直接開源到社群。所以要經得起考驗，程式碼都會寫的比較規整。
開放出去，如果架構和程式碼不規整，就不會有人在 github 上 star，也不會有多少人使用。沒人用事小，被人罵事大，讓團隊和公司丟臉更了不得了。所以這種專案比較容易接手，因為在文件和程式碼都比較規整的情況下，只需要在技術上下功夫就可以了。
本來專案應該有齊備的文件的，而現實中的好多專案往往不是這樣的。由於各種各樣的原因，比如框架比較老，人員變動，業務變動等，可能造成專案結構變的比較混亂。那麼當我們應該如何快速的接手這樣一個專案呢。
1、首先需要了解專案的的表現形式，什麼是表現形式呢，就是說這個專案是提供 web 端服務，還是提供 App 端服務，還是其他形式的服務，又或者是混合了多種形式。我們比較容易理解具體的東西，而對於抽象的事物理解起來有一定的難度。所以看到專案最終的表現形式，可以對應到我們的專案結構中，這樣一來，對於理解專案就比較容易了。
2、瞭解專案的部署架構。部署架構包括從客戶端一直到資料訪問層。這其中包括伺服器系統版本，後端伺服器軟體型別（tomcat 、jetty 等），負載均衡配置，配置了多少臺，用的是 nginx 還是 HA ,有或者是其他的。前後端互動方式，快取是用到什麼方案，是 redis 還是其他的，單機主備還是叢集方案。資料庫用的什麼，有沒有叢集，有沒有異地。資料庫中介軟體用的什麼框架等等。這個時候，最好有部署架構圖拿來看一眼，如果是比較複雜的專案，肯定開發和運維會有部署文件的。如果沒有完備的文件，建議要了解清楚之後，自己手動畫一下部署架構圖。
3、瞭解專案的程式碼架構。其中包括專案使用的基礎框架，比如是 Spring mvc ，還是 Spring boot ，又或者是其他的框架，有沒有用到 Netty 等其他的比較大的框架。有沒有用到分散式 SOA 或者是否使用了微服務。用到分散式方案是 dubbo 還是 spring boot ，其中重點關注這些框架所用的版本，有些框架的版本可能比較老舊。
4、瞭解專案功能模組。到這裡就和業務有關了，功能模組的劃分一般和業務有關，比如註冊登入模組、使用者管理模組、訂單管理模組、財務相關的服務模組等等。以及模組之間的依賴關係，是不是存在專案引用，是不是存在 RPC 呼叫或 http 服務呼叫關係等。這個時候，最好有完整的模組或服務依賴結構圖，如果沒有，最好在瞭解了專案結構之後，自己手動畫一張。
5、最後，就是要理解具體的業務了，然後根據業務檢視、調式對應的程式碼以及資料結構。
總體上要遵循從整體到細節，從高緯到低維的一個過程。如果能做好以下幾點就最好了：
1、如果專案不是很複雜，最好可以有測試環境或者本地環境搭建起完整的專案架構。
2、如果專案很複雜，至少要保證自己負責的部分可以通過一些方法能在本地搭起來。
3、如果要在專案上做功能擴充套件，要遵循團隊或專案的規範，不要獨樹一幟，這樣會給後期維護帶來麻煩。
4、修改功能之後，要維護好對應的文件。
想到哪兒寫到哪兒，好多東西沒寫到位。
微信公眾號，多謝關注：
還可以加入 Java 微信討論群（如果二維碼過期：請加微信:fengdezitai001 ,備註：cnblogs）：
