問答專欄Q & A COLUMN
抓住主線，分析源碼首先就是宏觀上知道這個源碼的目的是什么，例如spring就是實現了IOC和DI的功能，概念比較抽象，也可以直接去實踐一下，沒有spring和有spring寫一下創建對象的代碼有啥不同，加深對框架的理解，只有清楚了整個框架帶來的價值之后，分析源碼才能避免“不識廬山真面目” 的尷尬。
區分jar的邊界與職責，很多框架都是一堆的jar去不斷的集成，我們分析源碼首先要宏觀的去看待整個框架做了什么事情，然后再分清楚每個jar對應大概做了什么事情，然后這樣就能在分析源碼的時候盡量不迷路。
抽象思維，對于開源框架來說，其很重要的一個特性就是要把通用需求給穩定化，在此基礎上進行迭代，不斷的添加最新的特性，在這個過程中保持良好的兼容性與擴展性，這就要求對其他框架采取解耦的方案，保持非入侵的方式。這樣帶來的代碼上的體現就是處處是接口，處處是抽象類，很多方法都是模板方法。這里的行話，就是不要“寫死”。依賴抽象而不是實現，這樣就可以盡量的松耦合，所以有意識的增強對于接口和抽象類的理解，所以很多人也認為 要比較好的閱讀源碼首先要熟悉經典設計模式與設計原則等面向對象理論。
底層代碼能力，這一塊是對于一些偏底層的一些技術實現的熟悉，例如反射，動態代理，字節碼植入，或則是范型的使用，函數編程等語法糖的熟悉。當然如果能熟悉JUC包的東西，多線程的理解也非常重要。
帶著問題看源碼，單純的閱讀的確很容易枯燥，但是我們在使用的過程中，由于前期可能主要關注在如何快速上手可能網上隨便搜索入門教程就開始使用后，滿足了日常工作需求就沒再深入的動力，但是其中某個特性為什么實現，例如mybatis定義的mapper接口沒有實現類，是如何注入到spring容器，帶著這樣的疑問，我們就很自然的產生了好奇心。
畫圖，圖像是比文字更容易加強記憶和理解的東西，語言是后天的，但眼睛是天生的，我們應該善于利用這點，閱讀感覺有點混亂的時候就開始進行思維導圖的整理，流程圖的整理等等，這樣的腦圖是很有價值的，當然也不要因此打斷閱讀的連貫性，而是一個大的階段整理一下即可，每個人的邏輯思維強度會有些不同，可以按需掌握節奏。
評論0
加載中...
犯困就對了，剛開始看不暈才是不正常的，這東西看個大概就行，除非你真需要這一塊兒的設計模式，否則就算看懂，不到兩天保準兒忘，建議還是會用，而不是上來就研究源碼，而且這東西每版源碼都不一樣看不過來，如果不是在大廠去研發新框架就沒啥必要看源碼
評論0
加載中...
看一天是不可能看明白的，我看spring源碼看了一個星期才開始看明白，堅持了一個多月才看明白容器部分。至于注解部分，我沒有空過，僅僅分析過scope注解。注解要看明白，要找到注解的processor，注解本身并沒有什么內容。找到Processor，才能知道注解的真相。
評論0
加載中...
其實直接看源碼就是比較讓人難以琢磨的，因為很多時候源碼的底層是計算機深層技術，和
表面看到的邏輯是不大一樣的，源碼分析，可以從某一個技術點來看，自己看純理論的說明
的話，倒不如看一些圖例分析或者視頻講解來得更明了一些，只要是大白話一些能給你舉幾
個現實的事物比較，就更加形象啦，比如說一個bean實例的創建過程，可以看看這篇文章，
https://m.toutiaocdn.com/i6745978831934325260/?app=news_article×tamp=1593417076&use_new_style=1&req_id=202006291551150101300371352404BFFB&group_id=6745978831934325260
看看不同時期做的具體操作和為什么這樣的做，源碼的底層一般效率都是比較高的，尤其
這種設計風格，在以后自己的代碼風格中可以多多借鑒！ 就像通信技術，簡單地看一個短連接和長連接的區別，以及這樣做的優缺點，加以分析和比較！[呲牙][呲牙][呲牙]
評論0
加載中...
帶著問題去看代碼，為了解決問題去看代碼，如果不是為了具體的開發目標，而是為了提高技術水平，應該按教程學習或自己開發開源軟件。 這類似于學習語言，放到 這個語言的環境下，經過一段時間，無意識就學會了。而想考高分而突擊背單詞，肯定一背就犯困。就比如這個問題，transaction 你看懂后，是要修改transaction 哪部分功能? 到達什么目的，先把這些想清楚
評論0
加載中...
10
回答0
回答0
回答0
回答2
回答0
回答0
回答0
回答0
回答0
回答
