如何接手一個新項目

項目好與很差，它就在那裏；架構優雅或者醜陋，它就在那裏；註釋有或者沒有，它還在那裏；文檔亂或者不亂，它始終都在那裏。不論它是什麼樣子的，線上就那樣跑着。

通常來說，項目分爲兩種：

一、爲業務服務的項目，好比公司內部項目、電商項目、各類 app 項目；

二、爲技術服務的項目，好比開源中間件項目（dubbo、spring cloud、各類數據庫中間件、各類緩存方案等）；

首先說第二種項目，它專一於提供某一個或幾個特定的功能。相對來講，這種項目技術實現上可能須要對這一領域有比較深的要求，但職責單一，目標明確。並且這種項目都是面向開發人員的，因此設計文檔、接口文檔、使用文檔都會比較齊全。並且這種項目通常都會承擔比較核心、比較重要的功能，而且還會在公司內部開放，甚至直接開源到社區。因此要經得起考驗，代碼都會寫的比較規整。

開放出去，若是架構和代碼不規整，就不會有人在 github 上 star，也不會有多少人使用。沒人用事小，被人罵事大，讓團隊和公司丟臉更了不起了。因此這種項目比較容易接手，由於在文檔和代碼都比較規整的狀況下，只須要在技術上下功夫就能夠了。

原本項目應該有齊備的文檔的，而現實中的好多項目每每不是這樣的。因爲各類各樣的緣由，好比框架比較老，人員變更，業務變更等，可能形成項目結構變的比較混亂。那麼當咱們應該如何快速的接手這樣一個項目呢。

一、首先須要瞭解項目的的表現形式，什麼是表現形式呢，就是說這個項目是提供 web 端服務，仍是提供 App 端服務，仍是其餘形式的服務，又或者是混合了多種形式。咱們比較容易理解具體的東西，而對於抽象的事物理解起來有必定的難度。因此看到項目最終的表現形式，能夠對應到咱們的項目結構中，這樣一來，對於理解項目就比較容易了。

二、瞭解項目的部署架構。部署架構包括從客戶端一直到數據訪問層。這其中包括服務器系統版本，後端服務器軟件類型（tomcat 、jetty 等），負載均衡配置，配置了多少臺，用的是 nginx 仍是 HA ,有或者是其餘的。先後端交互方式，緩存是用到什麼方案，是 redis 仍是其餘的，單機主備仍是集羣方案。數據庫用的什麼，有沒有集羣，有沒有異地。數據庫中間件用的什麼框架等等。這個時候，最好有部署架構圖拿來看一眼，若是是比較複雜的項目，確定開發和運維會有部署文檔的。若是沒有完備的文檔，建議要了解清楚以後，本身手動畫一下部署架構圖。

三、瞭解項目的代碼架構。其中包括項目使用的基礎框架，好比是 Spring mvc ，仍是 Spring boot ，又或者是其餘的框架，有沒有用到 Netty 等其餘的比較大的框架。有沒有用到分佈式 SOA 或者是否使用了微服務。用到分佈式方案是 dubbo 仍是 spring boot ，其中重點關注這些框架所用的版本，有些框架的版本可能比較老舊。

四、瞭解項目功能模塊。到這裏就和業務有關了，功能模塊的劃分通常和業務有關，好比註冊登陸模塊、用戶管理模塊、訂單管理模塊、財務相關的服務模塊等等。以及模塊之間的依賴關係，是否是存在項目引用，是否是存在 RPC 調用或 http 服務調用關係等。這個時候，最好有完整的模塊或服務依賴結構圖，若是沒有，最好在瞭解了項目結構以後，本身手動畫一張。

五、最後，就是要理解具體的業務了，而後根據業務查看、調式對應的代碼以及數據結構。

整體上要遵循從總體到細節，從高緯到低維的一個過程。若是能作好如下幾點就最好了：

一、若是項目不是很複雜，最好能夠有測試環境或者本地環境搭建起完整的項目架構。

二、若是項目很複雜，至少要保證本身負責的部分能夠經過一些方法能在本地搭起來。

三、若是要在項目上作功能擴展，要遵循團隊或項目的規範，不要獨樹一幟，這樣會給後期維護帶來麻煩。

四、修改功能以後，要維護好對應的文檔。

想到哪兒寫到哪兒，好多東西沒寫到位。

微信公衆號，多謝關注：

還能夠加入 Java 微信討論羣（若是二維碼過時：請加微信:fengdezitai001 ,備註：cnblogs）：