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