最近，因為公司項目的原因，對一個大型的系統做了一個簡要的架構分析。由于，時間上的限制，所以在這里我也只能做一個快速的分析，并沒有其它的可能性。
太長不看版步驟：
-
clone 項目的代碼，以及相關的依賴
-
嘗試編譯系統
-
借助目錄 + 編輯器進行初步分析
-
借助工具進行可視化分析
-
配置 IDE，進行源碼分析
-
繪制架構圖
-
從用戶旅程驗證架構正確性
-
總結輸出
-
回溯版本，進一步驗證
PS：這里所針對的情況是，沒有現有架構圖的情況。如果已經有現成的架構，那么它的步驟應該是不一樣的。依我之間的經驗來看，它應該是這樣的：
-
尋找架構圖
-
尋找相關的閱讀代碼文檔、日記
-
其它同上
0. clone
多數情況下，把遠程的代碼 clone 到本地，是一件非常簡單的事情。但是，并非所有的情況都是如此，因為對一個大型的系統來說，我們要面對著這么一些情況：
-
代碼庫過多
-
代碼量過大
于是，在我所需要分析的這個系統里，它采用了 google 的多倉庫管理工具 Repo。這樣就從一定程度上解決代碼庫過多的問題——對于我們來說，我們只需要執行一個 repo sync，它就可以幫助我們把所有的代碼 clone 下來。而后，我們只需要等待幾小時，或者幾天，就可以下到我們的代碼庫了。
1. 嘗試編譯系統
有了代碼之后，我們就可以嘗試按文檔的步驟來構建應用。期間，我們還需要解決一些工具上的問題，又或者是按官方的 issue 來處理一些異常情況。
與此同時，你還可能會遇到我在這個項目上遇到的問題：當前版本是無法成功構建的。
于是，我還需要重新花一天時間，再找到某一個特定版本的代碼……。
2. 借助目錄 + 編輯器進行初步分析
與此同時，在我們進行編譯的時候，還可以同時簡單地對項目進行分析：
-
目錄結構分析。通過查看目錄名稱和目錄結構，分析項目的組成關系。
-
代碼簡單分析。嗯，從一個入口點，一步步查看調用關系等。
之所以，我們還不能用 IDE 進行分析的一個原因是：對于這樣的一個系統來說，IDE 是一個龐大的吃內存怪物。而在當前時刻，我們還在嘗試構建這個系統，它不僅吃內存，還吃 CPU。甚至于，你的電腦還會因此而卡住。
3. 工具可視化
進一步地考慮到了項目的代碼量的問題，簡單地靠人力分析起來比較困難。我們就需要借助于一些工具來對代碼進行分析。
由于這是一個 JAVA 項目，我就可以用我之前寫的系統分析工具：Coca。用它來繪制基本的架構圖：
Package Arch Demo
還有某一個方法或者是類的上下調用關系：
call
4. 配置 IDE，進行源碼分析
在騰出了足夠的 CPU + 內存資源之后，我們就可以輕松愉快地打開 IDE，進行源碼分析。于是，很快地，我就需要等待 IDE 把代碼索引完。
好了，IDE 卡住了。
模塊分析
接著，我嘗試了另外一種可能性，打開其中的某一個工程查看源碼，但是很快地我發現了：缺少依賴。因為總體的構建失敗，導致了總工程的一些依賴無法構建成功。
于是乎，我嘗試了另外一種可能性：提取生產環境的依賴。畢竟，我所需要的依賴是一些 jar 包，而 jar 包會伴隨著系統一起分發。這樣一來，我就能從發布包中復制依賴到工程中使用，然后愉快地繼續閱讀代碼了 —— 順便地也能從依賴分析項目的情況。
工程內依賴分析
嗯，對于某些模塊來說，它的產出是一個 jar 包，那么我們不一定需要閱讀它地源碼。只需要理清單個模塊的構建產物，以及它的作用即可。
5. 繪制架構圖
嗯，有了上面的基礎之后，我們就可以繪制架構圖了。
暫時沒啥好的工具推薦，Google Slides、Sketch 這一類的都可以。
如果是調用關系的話，可以用 Graphviz 來繪制。只是呢，我已經用 Coca 來自動化繪制這個依賴關系了。哈哈
6. 用戶旅程驗證
我們閱讀代碼時，都是從入口開始驗證。如基于 Spring 的微服務項目，都是從 API 注解作為入口點，一步步分析這個系統的架構；如 Angular 開發的前端應用，是從 main.ts開始的。如 IDEA 插件，是從 plugin.xml 開始的，從 Action 綁定用戶行為。
以類似的方式，我們就可以在不能調試的情況下，進一步驗證架構的提煉是否合理。
7. 回溯版本，重復
考慮到我使用的版本是不能成功編譯地版本，所以又花了點時間再下一個舊版本的系統，以驗證部分關系是否是正確的。
畢竟只有成功編譯地版本，才是正常的版本。
8. 總結輸出
這些相關的產物可以有：
-
過程日志
-
問題總結
-
架構圖
-
仿制的 MVP demo
在這里，我們還是強調一下最后一個，我經常拿這種方式來創造輪子。
人生苦短，我有 Coca。
http://github.com/phodal/coca
