專案好與不好，它就在那裡；架構優雅或者醜陋，它就在那裡；注釋有或者沒有，它還在那裡；文件亂或者不亂，它始終都在那裡。不論它是什麼樣子的，線上就那樣跑著。一般來講，專案分為兩種：
2、為技術服務的專案，比如開源中介軟體專案（dubbo、spring cloud、各種資料庫中介軟體、各種快取方案等）；
首先說第二種專案，它專注於提供某乙個或幾個特定的功能。相對來說，這種專案技術實現上可能需要對這一領域有比較深的要求，但職責單一，目標明確。而且這種專案都是面向開發人員的，所以設計文件、介面文件、使用文件都會比較齊全。而且這種專案一般都會承擔比較核心、比較重要的功能，並且還會在公司內部開放，甚至直接開源到社群。所以要經得起考驗，**都會寫的比較規整。
開放出去，如果架構和**不規整，就不會有人在 github 上 star，也不會有多少人使用。沒人用事小，被人罵事大，讓團隊和公司丟臉更了不得了。所以這種專案比較容易接手，因為在文件和**都比較規整的情況下，只需要在技術上下功夫就可以了。
本來專案應該有齊備的文件的，而現實中的好多專案往往不是這樣的。由於各種各樣的原因，比如框架比較老，人員變動，業務變動等，可能造成專案結構變的比較混亂。那麼當我們應該如何快速的接手這樣乙個專案呢。
2、了解專案的部署架構。部署架構包括從客戶端一直到資料訪問層。這其中包括伺服器系統版本，後端伺服器軟體型別（tomcat 、jetty 等），負載均衡配置，配置了多少臺，用的是 nginx 還是 ha ,有或者是其他的。前後端互動方式，快取是用到什麼方案，是 redis 還是其他的，單機主備還是集群方案。資料庫用的什麼，有沒有集群，有沒有異地。資料庫中介軟體用的什麼框架等等。這個時候，最好有部署架構圖拿來看一眼，如果是比較複雜的專案，肯定開發和運維會有部署文件的。如果沒有完備的文件，建議要了解清楚之後，自己手動畫一下部署架構圖。
3、了解專案的**架構。其中包括專案使用的基礎框架，比如是 spring mvc ，還是 spring boot ，又或者是其他的框架，有沒有用到 netty 等其他的比較大的框架。有沒有用到分布式 soa 或者是否使用了微服務。用到分布式方案是 dubbo 還是 spring boot ，其中重點關注這些框架所用的版本，有些框架的版本可能比較老舊。
4、了解專案功能模組。到這裡就和業務有關了，功能模組的劃分一般和業務有關，比如註冊登入模組、使用者管理模組、訂單管理模組、財務相關的服務模組等等。以及模組之間的依賴關係，是不是存在專案引用，是不是存在 rpc 呼叫或 http 服務呼叫關係等。這個時候，最好有完整的模組或服務依賴結構圖，如果沒有，最好在了解了專案結構之後，自己手動畫一張。
5、最後，就是要理解具體的業務了，然後根據業務檢視、調式對應的**以及資料結構。
總體上要遵循從整體到細節，從高緯到低維的乙個過程。如果能做好以下幾點就最好了：
1、如果專案不是很複雜，最好可以有測試環境或者本地環境搭建起完整的專案架構。
2、如果專案很複雜，至少要保證自己負責的部分可以通過一些方法能在本地搭起來。
3、如果要在專案上做功能擴充套件，要遵循團隊或專案的規範，不要獨樹一幟，這樣會給後期維護帶來麻煩。
4、修改功能之後，要維護好對應的文件。
想到哪兒寫到哪兒，好多東西沒寫到位。
如何接手乙個專案
首先將專案 大目標 分為三個小目標 業務 技術 團隊運作。業務 請同事講一下，這個業務是做什麼的，解決什麼樣的問題，具體的業務流程是什麼樣子的。在這期間，不需要弄懂所有的細節，只需要建立起初步的框架。技術 你先得知道整個系統用到的技術棧，這樣你對系統用到的框架和工具就有數了。對外 系統對外提供哪些介...
接手新專案的感受
又要開始新的開發了，專案 統計了一下，有2400多個檔案，30多萬行 而且這個只是系統中子系統的乙個專案，整個專案幾十個系統，每個系統內部又有幾個子系統專案。自己能控制的是在這幾十萬行 重構，優化，實現需求。第一次碰到這樣比較持久的專案，專案應該從07年啟動，12年的時候系統可能做了一次大的修改，我...
測試如何快速介入乙個新專案
軟體測試人員如何快速介入乙個新專案 一般我們在入職乙個新公司或者進行專案調動的時候，接觸到的專案基本上都是以前沒有接觸過的專案，就算是專案型別類似，但是總歸是乙個全新並且未接觸過的專案，這個時候，作為乙個測試人員如何快速介入這個新專案就很考驗測試人員的意識和水平了，當然也和測試經理有關 畢竟經理要你...