資訊專欄INFORMATION COLUMN
摘要：一些方法不應該這樣不應該漫無目的地隨手拿起一分源碼，試圖去通讀。應該這樣精心挑選要閱讀的源碼項目。這最好是與你的編程語言你的工作內容你的興趣所在相關的，這樣才能更切實地感受到閱讀源碼給你帶來的益處，更有動力繼續。
怎么閱讀源碼
"沒有經驗的技術差底子薄的初級程序員，如何閱讀項目源碼？ "
"有人閱讀過 mybatis 的源碼嗎 ？就看一個初始化過程就看的已經頭暈眼花了，小伙伴們支支招吧！"
"源碼應該怎么閱讀，我曾經嘗試閱讀一些源碼，例如alibaba的druid中sqlparser部分，spring-mvc，但是發現很吃力，都說debug是最好的閱讀方式，我在debug時經常有跟丟的現象……就是走著走著感覺好像進入了一些我當前不太關注細枝末節。 "
。。。。。。
估計很多人都有這樣的疑惑。
我非常能理解小伙伴們的痛苦，因為我也是這么痛苦著走過來的。
閱讀優秀源碼的好處想必大家都知道，學習別人優秀的設計，合理的抽象，簡潔的代碼...... 總之是好處多多。
但是真的把龐大的代碼放到你的面前，就如同一個巨大的迷宮，要在其中東轉西轉尋出一條路來，把迷宮的整個結構搞清楚，理解核心思想，真心不容易。
在閱讀由面向對象的語言如Java寫的代碼時，會發現接口和具體的實現經常對應不起來，不太清楚一個功能到底是怎么在哪個實現類中才能找到。 不像C語言，就是函數調用函數，相對還好點。
如果是動態語言如Ruby,Python， 一個變量的類型甚至都不容易知道，閱讀的難度大大增加。
還有一個重要的原因，現在我們看到的源碼基本上都經過若干年發展、經過很多人不斷地完善的，枝枝蔓蔓非常多，魔鬼都在細節中。 閱讀的時候很容易陷進去， 看了幾十層函數調用以后，就徹底懵了，就放棄了： 甭管你把源碼吹得天花亂墜， 老子再也不看了。
經過很多痛苦的掙扎以后，我也算有一些成功的經歷，今天用治學的三個境界來類比， 給大家分享一下：
昨夜西風凋碧樹，獨上高樓，望盡天涯路
想把源碼搞懂，吃透，首先得登高望遠，瞰察路徑，明確目標與方向，了解源碼的概貌。
所以有些準備工作必須得做。
閱讀源碼之前，需要有一定的技術儲備。
比如設計模式，在很多Java源碼中幾乎就是標配，尤其是這幾個：模板方法，單例，觀察者，工廠方法，代理，策略，裝飾者。
再比如閱讀Spring源碼，肯定得先了解IoC是怎么回事，AOP的實現方式，CGLib，Java動態代理等，自己動手，寫點相關的代碼，把這些知識點掌握了。
必須得會使用這個框架/類庫， 最好是精通各種各樣的用法。
上面剛提過，魔鬼都在細節中，如果有些用法根本不知道，可能你能看明白代碼是什么意思，但是不知道它為什么這些寫。
先去找書，找資料，了解這個軟件的整體設計。
都有哪些模塊？ 模塊之間是怎么關聯的？怎么關聯的？
可能一下子理解不了，但是要建立一個整體的概念，就像一個地圖，防止你迷航。
在讀源碼的時候可以時不時看看自己在什么地方。
搭建系統，把源代碼跑起來！
相信我，Debug是非常非常重要的手段， 你想通過只看而不運行就把系統搞清楚，那是根本不可能的！
衣帶漸寬終不悔，為伊消得人憔悴。
根據你對系統的理解，設計幾個主要的測試案例，定義好輸入，輸出。
運行系統，慢慢地debug ，一步步地走，這是個死功夫，沒有辦法繞過。
Debug一遍肯定是不行的，需要Debug很多遍。
第一遍盡可能拋棄細節，抓住主要流程， 比如有些看起來不重要的方法就不進去看了。
第二遍、第三遍....再去看那些細節。
一個非常重要的工作就是記筆記（又是寫作！），畫出系統的類圖（不要依靠IDE給你生成的）， 記錄下主要的函數調用， 方便后續查看。
文檔工作極為重要，因為代碼太復雜，人的大腦容量也有限，記不住所有的細節。 文檔可以幫助你記住關鍵點， 到時候可以回想起來，迅速地接著往下看。
要不然，你今天看的，可能到明天就忘個差不多了。
給大家看看我做的一些筆記， 格式不重要，很隨意，方便自己看懂就行。
主要的測試案例搞明白了，豐富測試案例，考慮一些分支流程。
繼續Debug......
總之，靜態地看代碼 + 動態地debug (從業務的角度)， 就會慢慢揭開這個黑暗森林的面紗。
這一步會非常非常地花費時間，但是你做完了，對系統的理解絕對有質的飛躍。
眾里尋他千百度，驀然回首，那人卻在燈火闌珊處。
沒有千百度的上下求索，不會有瞬間的頓悟和理解，衷心祝愿閱讀源碼的朋友們都能達到這一境界。
最后一點，也是最關鍵的一點： 要能堅持下去。
我不是一個聰明人， 但是笨人自有笨辦法：什么事都架不住不斷的重復，一遍看不明白，再來第二遍， 兩遍搞不明白，再來第三遍......
可能有人要問： 你怎么能這么堅持地刨根問底呢？
答案就是好奇心： 這玩意兒到底是怎么實現的？！
閱讀源碼的意義與方法思索了這兩個問題良久，也去知乎找了一些相關話題的問答，但并沒有標準答案。所以，我這里也只是記錄一些我對此的看法，也許會隨著 RTFSC 閱歷的豐富而發生變化，我會記錄更新于我的博客里面
意義
在我看來，閱讀源碼的意義在于學習優秀的「套路」。
這里的「套路」所指范圍很廣，大到架構設計，小到可取的命名風格，還有設計模式、實現某類功能使用到的數據結構和算法等等。所謂高手，其實就是能比大部分人更早更快地掌握套路并熟練運用之人。
埋頭在自己的天地里耕蕓固然也能逐漸進步和成長，但總會有時候會遇到一些場景，你苦思良久也無法做出良好的設計，總會有一些時候，糾結如何為一個變量命名讓你停下飛速敲擊的手指。這些令你為難的場景，先賢們也許早就遇到過，并且給出了優雅的解決方案。看優秀的源碼的時候，將這樣的場景與對應的方案收入囊中，或者僅僅在腦中留下一個印象也好，以便在需要的時候，你的武器庫里總能掏出一把稱手的家伙來。
源碼閱讀三要素
源碼分析是一種臨界知識，掌握了這種臨界知識，能不變應萬變，源碼分析對于很多人來說很枯燥，生澀難懂。
源碼閱讀，我覺得最核心有三點：技術基礎+強烈的求知欲+耐心。
我認為是閱讀源碼的最核心驅動力。我見到絕大多數程序員，對學習的態度，基本上就是這幾個層次(很偏激哦)：
只關注項目本身，不懂就baidu一下。
除了做好項目，還會閱讀和項目有關的技術書籍，看wikipedia。
除了閱讀和項目相關的書外，還會閱讀IT行業的書，比如學Java時，還會去了解函數語言，如LISP。
找一些開源項目看看，大量試用第三方框架，還會寫寫demo。
閱讀基礎框架、J2EE規范、Debug服務器內核。
大多數程序都是第1種，到第5種不光需要濃厚的興趣，還需要勇氣：我能讀懂嗎？其實，你能夠讀懂的。
耐心，真的很重要。因為你極少看到閱讀源碼的指導性文章或書籍，也沒有人要求或建議你讀。你讀的過程中經常會卡住，而一卡主可能就陷進了迷宮。這時，你需要做的，可能是暫時中斷一下，再從外圍看看它：如API結構、框架的設計圖。
源碼知識點是程序員都繞不開的話題，說到這里，也給大家推薦一個交流平臺：架構交流群650385180，里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，以下的知識體系圖也是在群里獲取。相信對于已經工作和遇到技術瓶頸的碼友，在這個群里一定有你需要的內容。
一些方法
不應該這樣
不應該漫無目的地隨手拿起一分源碼，試圖去通讀。這一方面會過目即忘無所收獲，另一方面會枯燥得讓你迅速從著手到放棄。學習的方式有很多種，閱讀源碼并不一定是最適合你當前的情況的。
應該這樣
精心挑選要閱讀的源碼項目。
這最好是與你的編程語言、你的工作內容、你的興趣所在相關的，這樣才能更切實地感受到閱讀源碼給你帶來的益處，更有動力繼續。
如果你想學習的知識點有官方文檔，先看文檔再看源碼。
直接從源碼著手，搞清楚原理固然是好，但是源碼有可能是難啃的，先熟悉官方提供給所有人看的文檔，能較為平滑地對這方面的知識先有個大概的了解，然后再結合源碼去深入。
提出具體的問題，然后帶著問題到源碼中找答案。
比如在使用 Toast 的過程中，你可能會想到一些問題：Toast.makeText(...).show() 時發生了什么？Toast 能不能在非 UI 線程調用？能不能自定義 Toast 布局？諸如此類。在源碼中探尋完你想要的答案，你的目的也就達到了。
從一些共性層面入手。
大部分的程序里都會使用到的東西，比如線程模型、UI 組織結構、任務調度方式等等。針對某一個方面去了解，比漫無目的要有效率得多。
最好能夠編譯運行起來。
如果一份代碼你只能看不能跑，那可能讀到一些地方你只能猜這個地方的數據值和跳轉結構是怎么樣的，而很有可能你猜的是錯的。但如果你能編譯運行，那在需要的時候你可以修改，加日志等等來更好地觀察和驗證你的想法，得到正常的理解。
做一些筆記。
一方面是將你的學習成果保留下來，方便隨時查閱，畢竟只憑腦子記憶是不靠譜的；另一方面在學習的過程中，也能幫助理解。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/71254.html
摘要：構造函數參數太多錯誤的對象狀態使用模式在我們的示例中，改造下召喚師類齊天大圣孫悟空上單基石天賦戰爭雷霆瘟疫之源圖奇下路基石天賦戰陣熱誠皎月女神戴安娜中單建造者模式讓我們寫的代碼更具可讀性，可理解為建立復雜的物體。 建造者模式（Builder Pattern）屬于創建型模式的一種，將多個簡單對象構建成一個復雜的對象，構建過程抽象化，不同實現方法可以構造出不同表現（屬性）的對象，還提供了一...
摘要：單機游戲重視沉浸感和體驗感。這是我做判斷時的一條重要準則。在我的心目中，我是廣外的走讀生。所以我對廣外總是有一種特別的感謝之情。而這段時間是最純粹穩定的。這種崗位確是挺對口的。還是相當感謝同學們的。本來題目是沒有年齡的。只是在網上常看到已經25歲是否還適合轉行當程序員之類的問題，就覺得有必要暴露下我的年齡。 在過去的2018年，我從新媒體藝術的小圈子里面跳出來，自學編程，轉行前端。現已經入職...
摘要：最常見的有簡稱和簡稱。計算的高度時，浮動元素也參與計算。遇到這種情形，我們如何處理處理方法其實有很多，在元素中添加或者使其父元素形成一個也可以在元素中添加或是這些都可以有效解決父子元素重疊問題。解決這個問題，只需要把把父元素變成一個就行了。 一、什么是BFC Formatting context 是 W3C CSS2.1 規范中的一個概念。它是頁面中的一塊渲染區域，并且有一套渲染規則，...
閱讀 1743·2021-09-22 15:25
閱讀 1307·2019-08-29 12:34
閱讀 1908·2019-08-26 13:57
閱讀 3188·2019-08-26 10:48
閱讀 1443·2019-08-26 10:45
閱讀 793·2019-08-23 18:23
閱讀 733·2019-08-23 18:01
閱讀 1945·2019-08-23 16:07
