最近，因?yàn)楣卷?xiàng)目的原因，對一個大型的系統(tǒng)做了一個簡要的架構(gòu)分析。由于，時間上的限制，所以在這里我也只能做一個快速的分析，并沒有其它的可能性。

太長不看版步驟：

clone 項(xiàng)目的代碼，以及相關(guān)的依賴
嘗試編譯系統(tǒng)
借助目錄 + 編輯器進(jìn)行初步分析
借助工具進(jìn)行可視化分析
配置 IDE，進(jìn)行源碼分析
繪制架構(gòu)圖
從用戶旅程驗(yàn)證架構(gòu)正確性
總結(jié)輸出
回溯版本，進(jìn)一步驗(yàn)證

PS：這里所針對的情況是，沒有現(xiàn)有架構(gòu)圖的情況。如果已經(jīng)有現(xiàn)成的架構(gòu)，那么它的步驟應(yīng)該是不一樣的。依我之間的經(jīng)驗(yàn)來看，它應(yīng)該是這樣的：

尋找架構(gòu)圖
尋找相關(guān)的閱讀代碼文檔、日記
其它同上

0. clone

多數(shù)情況下，把遠(yuǎn)程的代碼 clone 到本地，是一件非常簡單的事情。但是，并非所有的情況都是如此，因?yàn)閷σ粋€大型的系統(tǒng)來說，我們要面對著這么一些情況：

代碼庫過多
代碼量過大

于是，在我所需要分析的這個系統(tǒng)里，它采用了 google 的多倉庫管理工具 Repo。這樣就從一定程度上解決代碼庫過多的問題——對于我們來說，我們只需要執(zhí)行一個 repo sync，它就可以幫助我們把所有的代碼 clone 下來。而后，我們只需要等待幾小時，或者幾天，就可以下到我們的代碼庫了。

1. 嘗試編譯系統(tǒng)

有了代碼之后，我們就可以嘗試按文檔的步驟來構(gòu)建應(yīng)用。期間，我們還需要解決一些工具上的問題，又或者是按官方的 issue 來處理一些異常情況。

與此同時，你還可能會遇到我在這個項(xiàng)目上遇到的問題：當(dāng)前版本是無法成功構(gòu)建的。

于是，我還需要重新花一天時間，再找到某一個特定版本的代碼……。

2. 借助目錄 + 編輯器進(jìn)行初步分析

與此同時，在我們進(jìn)行編譯的時候，還可以同時簡單地對項(xiàng)目進(jìn)行分析：

目錄結(jié)構(gòu)分析。通過查看目錄名稱和目錄結(jié)構(gòu)，分析項(xiàng)目的組成關(guān)系。
代碼簡單分析。嗯，從一個入口點(diǎn)，一步步查看調(diào)用關(guān)系等。

之所以，我們還不能用 IDE 進(jìn)行分析的一個原因是：對于這樣的一個系統(tǒng)來說，IDE 是一個龐大的吃內(nèi)存怪物。而在當(dāng)前時刻，我們還在嘗試構(gòu)建這個系統(tǒng)，它不僅吃內(nèi)存，還吃 CPU。甚至于，你的電腦還會因此而卡住。

3. 工具可視化

進(jìn)一步地考慮到了項(xiàng)目的代碼量的問題，簡單地靠人力分析起來比較困難。我們就需要借助于一些工具來對代碼進(jìn)行分析。

由于這是一個 JAVA 項(xiàng)目，我就可以用我之前寫的系統(tǒng)分析工具：Coca。用它來繪制基本的架構(gòu)圖：

Package Arch Demo

還有某一個方法或者是類的上下調(diào)用關(guān)系：

call

4. 配置 IDE，進(jìn)行源碼分析

在騰出了足夠的 CPU + 內(nèi)存資源之后，我們就可以輕松愉快地打開 IDE，進(jìn)行源碼分析。于是，很快地，我就需要等待 IDE 把代碼索引完。

好了，IDE 卡住了。

模塊分析

接著，我嘗試了另外一種可能性，打開其中的某一個工程查看源碼，但是很快地我發(fā)現(xiàn)了：缺少依賴。因?yàn)榭傮w的構(gòu)建失敗，導(dǎo)致了總工程的一些依賴無法構(gòu)建成功。

于是乎，我嘗試了另外一種可能性：提取生產(chǎn)環(huán)境的依賴。畢竟，我所需要的依賴是一些 jar 包，而 jar 包會伴隨著系統(tǒng)一起分發(fā)。這樣一來，我就能從發(fā)布包中復(fù)制依賴到工程中使用，然后愉快地繼續(xù)閱讀代碼了 —— 順便地也能從依賴分析項(xiàng)目的情況。

工程內(nèi)依賴分析

嗯，對于某些模塊來說，它的產(chǎn)出是一個 jar 包，那么我們不一定需要閱讀它地源碼。只需要理清單個模塊的構(gòu)建產(chǎn)物，以及它的作用即可。

5. 繪制架構(gòu)圖

嗯，有了上面的基礎(chǔ)之后，我們就可以繪制架構(gòu)圖了。

暫時沒啥好的工具推薦，Google Slides、Sketch 這一類的都可以。

如果是調(diào)用關(guān)系的話，可以用 Graphviz 來繪制。只是呢，我已經(jīng)用 Coca 來自動化繪制這個依賴關(guān)系了。哈哈

6. 用戶旅程驗(yàn)證

我們閱讀代碼時，都是從入口開始驗(yàn)證。如基于 Spring 的微服務(wù)項(xiàng)目，都是從 API 注解作為入口點(diǎn)，一步步分析這個系統(tǒng)的架構(gòu)；如 Angular 開發(fā)的前端應(yīng)用，是從 main.ts開始的。如 IDEA 插件，是從 plugin.xml 開始的，從 Action 綁定用戶行為。

以類似的方式，我們就可以在不能調(diào)試的情況下，進(jìn)一步驗(yàn)證架構(gòu)的提煉是否合理。