1，多打斷點
2，善用跳轉，分析數據入口（不太明白）
3，畫圖（數據流轉圖）
4，debug看源碼，看跳轉，邊看邊注釋，之后用五視圖法總結
五視圖 CSDN??https://blog.csdn.net/nnsword/article/details/78109126
轉載文章如下
在實際工作中，我們經常聽到“架構”和“架構師”這樣的名詞，并不新鮮，但是總讓很多剛入門的?
???在實際工作中，我們經常聽到“架構”和“架構師”這樣的名詞，并不新鮮，但是總讓很多剛入門的人感覺很神秘，甚至是高深莫測。很少有人對“架構”有全面的了解和認識能并說清楚架構是什么，更談不上掌握了。事實上，也只有極少數人能成為或者被冠以“架構師”這樣的title。為此，筆者總結了對架構的一些理解，希望能夠補充很多初入門的人在這方面認識上的不足，糾正一些誤解。高手和老鳥就直接跳過吧。
對于“架構”來講，理論上劃分了5種架構視圖，分別是：邏輯架構、開發架構、運行架構、物理架構、數據架構。根據名字，大家都可能大概能猜到其側重點和含義。這里先用通俗的文字簡單介紹下，便于大家理解，大家可以不必糾結概念和這些理論。
邏輯架構：邏輯架構關注的是功能，包含用戶直接可見的功能，還有系統中隱含的功能。或者更加通俗來描述，邏輯架構更偏向我們日常所理解的“分層”，把一個項目分為“表示層、業務邏輯層、數據訪問層”這樣經典的“三層架構”。
開發架構：開發架構則更關注程序包，不僅僅是我們自己寫的程序，還包括應用程序依賴的SDK、第三方類庫、中間價等。尤其是像目前主流的Java、.NET等依靠虛擬機的語言和平臺，以及主流的基于數據庫的應用，都會比較關注。和邏輯架構有緊密的關聯。
運行架構：顧名思義，更關注的是應用程序運行中可能出現的一些問題。例如并發帶來的問題，比較常見的“線程同步”問題、死鎖問題、對象創建和銷毀（生命周期管理）問題等等。開發架構，更關注的是飛機起飛之前的一些準備工作，在靜止狀態下就能規劃好做好的，而運行架構，更多考慮的是飛機起飛之后可能發生的一些問題。
物理架構：物理架構，更關注的系統、網絡、服務器等基礎設施。例如：如何通過服務器部署和配置網絡環境，來實現應用程序的“可伸縮性、高可用性”。或者舉一個實際的例子，如何通過設計基礎設施的架構，來保障網站能支持同時10W人在線、7*24小時提供服務，當超過10W人或者低于10W人在線時，可以很方便的調整部署架構來支撐。
數據架構：數據架構，更關注的是數據持久化和存儲層面的問題，也可能會包括數據的分布、復制、同步等問題。更貼切來講，如何選擇需要的關系型數據庫、流行的NOSQL，如何保障數據存儲層面的性能、高可用性、災備等等。很多時候，和物理架構是有緊密聯系的，但它更關注數據存儲層面的，物理架構更關注整個基礎設施部署層面。
上面講了那么多，相信國內很少有公司是嚴格按照這五種視圖去分工和設計的。其實在筆者眼中，架構大致分為兩種：軟件架構、系統架構。前三種視圖，可以歸納為軟件架構，而后兩種架構，則歸為系統架構。這也比較符合國內大部分中小型互聯網公司的現狀。
根據應用特性的不同，關注側重點可能不同。例如，某些門戶類的互聯網應用，讀多寫少而且業務相對比較簡單，則更加關注“高性能、可伸縮性、可用性”等方面。對于更加復雜的應用，例如電商類大規模交易型的應用，對每個層面和每個環節都會比較關注。對于業務型的系統，例如一些生產型企業使用的ERP，或者僅供企業內部使用的一些MIS、OA應用，通常更關注功能和復雜的業務和實現和擴展，而對性能等方面又可能不要太高，這類應用則更關注純軟件架構層面。這里，不展開做具體討論。所以很多時候，架構師也需要是一個團隊，而不是一個人“全棧”。
在長期的技術招聘面試中，我發現在很多人眼中，架構就是分層，架構設計就是“三層架構”（或者四層、五層…反正分層越多就說明項目越復雜而且架構就越牛），或許是受到諸如PetShop之類的示例項目的影響，這里暫時不去追究原因了。
之前已經糾正過很多人的誤解-架構不只是軟件架構。說一下通俗點的理解：
軟件架構就是實用而且優雅的設計，它不在于分多少層，或者應用了多少種設計模式/架構模式等。它應該是以滿足實現用戶需求為前提，以開發人員普遍可接受為根本的，而且要符合系統特性和業務發展需要的，從軟件設計的角度，能夠達到層次清晰、可維護、可重用、可擴展…就非常優秀了，無需刻意去糾結分了多少層，是否使用了什么模式，有多么抽象等。以面向對象設計為例，基本目標是“高內聚、低耦合”，為此我們可能會遵循一些常見的設計原則（例如經典的SOLID設計原則）。最后糾正一點，通常我們所說的模式，其實又分為很多種，并不是僅僅指的是“設計模式”（設計模式也有千千萬，并不是只有常見的GOF 23種設計模式）。通常包括：企業架構模式、設計模式、SOA模式、企業集成模式等等。
強調一下，架構要講求“實用”，而且開發人員普遍可接受，要符合現狀的。否則，再“優雅”的設計，都會淪為高成本的“花架子”，生搬硬套和過度設計只會讓項目“流產”。
由于角色和分工不同,軟件架構是一個復雜的整體，軟件架構工程師不可能在一個視角、一下子講清楚，而利用多重軟件架構視圖的方法，可以一次只圍繞少數概念和技術展開，分別著重研究軟件架構的不同方面，使問題得以清晰公和簡化，利于軟件架構工程師完成架構設計工作。
因此軟件架構的每個視圖分別關注不同的方面，針對不同的目標和用途。目前常用架構設計五視圖方法進行軟件架構描述。它們分別是邏輯架構、開發架構、運行架構、物理架構和數據架構。
邏輯架構的設計著重考慮功能需求，系統應當向用戶提供什么樣的服務，關注點主要是行為或職責的劃分。邏輯架構關注的功能，不僅包括用戶可見的功能，還應當包括為實現用戶功能而必須提供的輔助功能。邏輯架構的靜態方面是抽象職責的劃分，動態方面是承擔不同職責的邏輯單元之間的交互與協作。
開發架構的設計著重考慮開發期質量屬性，關注點是在軟件開發環境中軟件模塊（包）的實際組織方式，具體涉及源程序文件、配置文件、源程序包、編譯打包后的目標文件、直接使用的第三方SDK/框架/類庫、以及開發的系統將運行于其上的系統軟件或中間件。
運行架構的設計著重考慮運行期質量屬性，關注點是系統的并發、同步、通信等問題，這勢必涉及到進程、線程、對象等運行時概念，以及相關的并發、同步、通信等。運行架構的靜態方面關注軟件系統運行時的單元結構，動態方面關注運行時單元之間的交互機制。
物理架構的設計著重考慮安裝和部署需求，關注點是目標程序及其依賴的運行庫和系統軟件最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性、持續可用性、性能和安全性等要求。
數據架構的設計著重考慮數據需求，關注點是持久化數據的存儲方案，不僅包括實體及實體關系數據存儲格式，還可能包括數據傳遞、數據復制、數據同步等策略。
在運用五視圖方法進行架構設計時需要注意兩個方面的問題：一是多個架構視圖間的同步問題，也就是必須保證不同視圖之間是互相解釋而不是相互矛盾的；另一個是架構視圖的數量問題，原則上是軟件系統不涉及某方面的要求時就不需要該方面的視圖，嚴格控制架構視圖的數量，但如果有需要，可以引入新的架構視圖，從而更加突出和明確地制定和表達特定方面的架構決策，如安全性。
構成每個架構設計視圖的元素不同，這些不同的元素撐起不同的思維空間，從而使每個架構視圖重點覆蓋不同種類的需求，最終所有架構設計視圖所表達的語義綜合左右一起，就構成了軟件架構設計方案。
?
