?2016-2026 Matools All rights reserved,
粵ICP備17059708號
標簽： 源碼學習方法
我們?yōu)槭裁匆丛创a？
這個小標題好像有點扯淡，不過我感覺還是有必要聊一聊。
最近搞 Blazor，手邊常備 AspNetCore 源碼，遇到問題了就翻源碼。
然后有同樣關注 Blazor 的同學會一起討論一些問題，我知道的問題會直接分享，我不知道的問題，我就，甩一句，“看源碼”
然后有的同學炸了，說，“不是每個人都可以像你一樣看源碼，源碼不是每個人都能看的，不是每個人都想看源碼”
當然原話不是這樣，后兩句是我添油加醋的，不過這兩句想必是大部分同學的心聲，心里害怕看源碼，覺得看源碼都是大神才會看的。
看源碼的正確姿勢
st=>start: 遇到問題 search=>operation: 百度谷歌 isOk=>condition: 能解決嗎？
donotusecode=>end: 好了你可以不用繼續(xù)看了 usecode=>end: 分析源碼解決 st->search->isOk
isOk(yes)->donotusecode isOk(no)->usecode
看源碼的錯誤姿勢
st=>start: 聽說看源碼能學到很多東西，能通過面試，能XXXXX usecode=>end: 看源碼 st->usecode
感覺第二個流程圖像是在扯犢子，其實第二個圖也并非完全錯誤，只是在強調(diào)你不能為了看而看，你要帶著問題去看，但如果這樣的話，那其實又變成了第一張流程圖了
看源碼的方法
很多同學在滿足第一個流程圖的條件之后，可能看源碼仍然感覺累，沒有頭緒，這是沒掌握看源碼的技巧，可能存在以下幾種情況
* 拿著 github 在線看源碼，這和拿記事本看源碼沒好到哪去
* 真的就拿著記事本看源碼，或者拿著 VSCode 看源碼（我不是黑它）
* 不擅于使用 VS 的相關功能
看源碼一定先編譯源碼
不用編譯直接打開 VS 一把梭，不是很好嗎？
不好，確實是可以打開的，但是這個時候往往因為沒有編譯過導致 VS 的很多功能不可用，例如轉(zhuǎn)到定義、查找引用。
對我而言，編譯源碼是個艱難的過程，看源碼反而簡單。特別是 AspNetCore 的源碼，編譯起來要了半條命。
關于怎么編譯，每個開源項目都不一樣，有的項目簡單，打開 VS 直接就能編譯，但是像 AspNetCore
這種，必須嚴格按照官方給的編譯步驟文檔，還得保證網(wǎng)絡暢通，編譯過程中很容易被勸退。
五大板斧不可少
有很多同學看源碼的過程讓我比較著急，咋看的呢？
CTRL+F，輸入搜索詞，全解決方案搜索，不管是怎樣的情況全是這樣搞，解決方案比較大的話一搜一大堆出來。
也許只是我周圍的同學是這樣的吧。
我看源碼的過程中常使用這些方法
* 轉(zhuǎn)到定義，F(xiàn)12
* 轉(zhuǎn)到實現(xiàn)，CTRL + F12
* 查找引用
* 調(diào)用堆棧
* 解決方案管理器搜索
這五大板斧中，除了調(diào)用堆棧，其他的幾乎都是靜態(tài)分析代碼的必備方法，調(diào)用堆棧一般屬于動態(tài)分析代碼的辦法。
這五大板斧用好了，只要源碼的變量命名不要太坑爹，基本上是不需要看注釋的，我看開源項目的源碼從來不看注釋，開源項目的源碼的命名一般都是比較好的。
下面我將舉例來分享我看源碼的過程，把上面這幾個方法用上
問題實例：怎么根據(jù)路由獲取對應的組件？
這是我在編寫 BlazAdmin
時遇到的問題，我需要根據(jù)當前路由得到這個路由對應的那個組件，然后做一些操作，我甚至不知道如何搜索，因為關鍵詞不好搞，隨便搜了幾個也沒找到答案。
下面開始分享我針對這個問題的解決思路，下載編譯 AspNetCore 源碼的步驟我就不寫了
第一個問題，從哪兒開始？
萬事開頭難，剛開始看源碼更難，無頭蒼蠅的感覺。
我們的需求是，怎么根據(jù)路由獲取對應的組件，這里面有兩個關鍵詞，一個是路由，一個是組件
我們換位思考一下，假如由我們來開發(fā)這個功能，我們會寫哪兩個類？
答案應當很明顯，Router 和 Component，當然也許不是這么命名的，都有可能。但好像知道這兩個名字了還是沒啥用？根本問題在于
AspNetCore 解決方案太多，我們壓根不知道應該打開哪個解決方案，也就無從搜索這兩個類名。
我的辦法是，也許這兩個類我們是可以直接使用的，那么如果可以直接用的話，我們應該可以在代碼的任意地方調(diào)用這兩個類，那么我們就試試。
在我們自己項目的 Program.cs 文件中，隨便找個地方，我們首先嘗試 Router 關鍵字。
好像有戲，我們已經(jīng)看到命名空間了，那么根據(jù)這個命名空間，我們嘗試找到對應的解決方案，這個命名空間的關鍵詞是什么呢？Microsoft？AspNetCore？這兩個關鍵詞太大眾化了，那么只剩下兩個，Components
和 Routing，我們一個一個來
沒啥好說的，既然找到了，管它是不是，先打開看看再說。
我們直接在解決方案管理器中搜索這 Router 這個類。
我們的入口點已經(jīng)顯而易見了
第二個問題，這個類是如何找到 Component 的？
這個類中有這么些方法
根據(jù)方法猜功能，沒錯，看源碼全靠猜，猜錯了換條路繼續(xù)
OnAfterRenderAsync 這個應該不是
OnLocationChanged 這里面都有些啥？
這里面調(diào)用了 Refresh 方法，F(xiàn)12 跟進去
開始發(fā)暈了，咋這么多呢，而且還不明顯，我們一行行看，一行行猜
看第五第六行，這兩行有點意思，跟當前路由有關，也許是我們想要的
F12 進 RouteContext，看看里面有啥
好吧啥也沒有，我們繼續(xù)看第六行，F(xiàn)12 進 Route 方法
越來越像了，Match 方法里面又是什么呢？F12 進去
這個方法中看起來也不像那么回事，不過還是有點有用信息，最后一句代碼將 Handler 賦值了一下，但問題是 Handler
是啥？看這命名有點像當前路由的處理器，那么這個處理器可能就是我們要找的 Component，從構造方法中可以看出這個 Handler
是由構造方法傳過來的，構造方法可以看到還有一個引用，意味著有地方在顯示調(diào)用，那么我們通過查找引用跳過去看看
看來這就是我們要找的了，越來越近了，這里應該是在分析路由模板，那么路由模板應該是調(diào)用這個方法的地方傳過來的，再次查找引用跳過去
兩個地方在調(diào)，咋辦？明顯可以看出第一個地方是單元測試調(diào)的，所以其實只有第二個地方在調(diào)
Template 就是路由的模板，而這個模板是由 RouteAttribute 特性來得到的，而這個特性是標記在每一個組件的 Type
上的，也就是說，只要獲取所有組件的 Type，就可以拿到所有組件對應的路由，這樣一來，我的問題解決了
總結(jié)
* 大膽猜測，小心求證
* 換位思考，如果是我，我會怎么命名，這個常用于尋找分析入口點
* 英語別太差，不過一般來說你堅持看源碼英語會提升的
* 不要 CTRL + F，不要 CTRL + F，不要 CTRL + F，多用 F12，查找引用
* 在某些特殊情況下，例如別人都是通過反射調(diào)用的，那么就只能 CTRL + F 了
可以看到，解決這個問題的過程幾乎全是靠猜，猜錯了就回過頭去猜下一個，猜對了那就對了。所以如果說某個開源項目的命名太糟糕，那就確實不好找了。當你看源碼看多了之后，你就不需要猜了，因為你已經(jīng)知道命名是啥了。
在這個示例中，我們沒有使用轉(zhuǎn)到實現(xiàn)，因為其實這個示例所涉及到的代碼還是簡單的，沒有涉及到太多的多態(tài)，因此不需要轉(zhuǎn)到實現(xiàn)。如果涉及到多態(tài)，那么過程會復雜很多，因為要看的路徑太多，但總歸是能看完的，相比用谷歌去搜索半天壓根就沒有頭緒，花點時間猜源碼還是值的。
熱門工具 換一換