閱讀一些優秀開源項目的源碼對於編程思維與技巧等方面能力的提升是有很大幫助的，做開發的同學應該都明白其中的道理。
以前在大學裏的時候，總是想知道如何通過源碼去學習？
同時，因爲只是想着通過閱讀源碼來提升，但是“提升”這樣一個空泛的目標會讓學習過程無從下手。雖然有一個明確的“提升”方向，也就是要提高編程能力，但是你並不知道具體是要提高什麼？具體是要怎麼去提高？總之就是處於迷惘狀態，甚至連問題是什麼的思路都不清晰。
但是這一片迷霧可以歸結爲一個問題：什麼情況下可以切入某個項目去開始閱讀源碼呢？
“什麼情況下可以切入某個項目去開始閱讀源碼”、“如何通過源碼去學習”，這兩個問題就是本文要講的。
昨天我在調整個人博客的某個問題之後，我的小夥伴【辣雞Python開發】希望我把這個經驗教教他，因爲他問的時候我已經離開電腦，暫時不方便直接給他指出來這樣這樣-那樣那樣，所以我就只能動腦回顧了一下，然後順其自然就把整個解決該問題的過程給過了一遍，從最開始網上搜索、嘗試、無果自己閱讀博客框架的源碼、查官方文檔、再嘗試、調整……到最後終於成功解決問題。
咦，“閱讀源碼”、“查看官方文檔”，我不知不覺之中自己做了這兩件事情！
沒錯，前邊說不知道如何學習源碼、也不知道什麼契機可以切入某個開源項目去閱讀源碼，這兩個問題在不知不覺中都被我回答了。所以也纔有此文。
下邊具體分享一下昨天我解決問題的整個研究過程，記錄一下，同時給我那【辣雞Python開發】小夥伴一個交待，也希望讀者能有所收穫。
我的博客是使用 Hugo 搭建的，搭建之後它在博客首頁會顯示文章的“縮略樣式”，也就是顯示文章的頭幾十/幾百個字符，如果點擊“Read more”就可以跳轉查看完整內容。
但是我嫌這縮略也太長了，如下圖，數了一下，這篇文章“縮略”之後竟然還顯示了 15 行，真是醜爆了：
所以我就想通過設置把它調整少幾行。問題其實就這麼簡單，但是對於一個外行人來說，也是需要做一些研究才能搞定的，畢竟網上都搜不到這樣的問題。
真的搜索不到，這樣具體個性化的問題本身就不夠“通用”，而且關於 Hugo 相關的具體實踐也不多，大多停留在使用 Hugo 把博客搭建起來。
沒辦法，不知不覺自己打開了博客項目的源碼，網站結構很簡單，所以根據邏輯還比較好找，源碼一看也就知道相應的顯示效果是在哪裏被描述的，在網站主題下 Layout 下的 index.html 中：
<section class="section">
<div class="container">
{{ range sort .Paginator.Pages }}
<article>
<h2 class="subtitle is-6">{{ .Date.Format "January 2, 2006" }}</h2>
<h1 class="title"><a href="{{ .Permalink }}">{{ .Title }}</a>{{ if .Draft }} ::Draft{{ end }}</h1>
<div class="content">
{{ .Summary | plainify | safeHTML }}
{{ if .Truncated }}
...<a class="button is-link" href="{{ .Permalink }}" style="height:28px">
Read more
<span class="icon is-small">
<i class="fa fa-angle-double-right"></i>
</span>
</a>
{{ end }}
</div>
</article>
{{ end }}
</div>
</section>
這段代碼一看就知道它是對應了我前邊講到的那個文章“縮略”效果，而其中：
這裏的 {{ if .Truncated }} 也表明它在判斷文章是否被“截斷”，也就是被“縮略”，但我還是在這裏小小地測試了一下，把“…”/“Read more”稍候一個，看網頁效果，發現沒錯，就是這裏。
於是我就在源碼中查找 .Truncated 相關的東西，沒有找到任何定義與引用。
然後去網上搜索，發現被帶入了 Hugo 官方文檔，然後簡單學習了一下具體的 Page Variables（之前基礎有了解過，但是沒有看到過那麼多系統默認的項），不過還是沒有找到最終想要的 .Truncated。
於是我 Ctrl+F，bingo。
看到了一個 .Summary！
聯繫了一下前邊的源碼，在判斷 if .Truncated 之前確實有一個 .Summary：
於是我查看 .Summary：
寫得很清楚，.Summary 是用來表示文章截斷長度的，並且默認是 70 words，也就是前邊說的大約 15 行那麼長。但是 .Summary 是引用時用的，設置時用的是 summaryLength。
其實到這裏這個設置方式就已經知道了，不用再往下了。但我還是想看看最終這個 summaryLength：
完全沒問題，它的描述也驗證了上邊說的，而且只有到了這一步，纔不再有下一個鏈接！也意味着這是可見、可操作的最底層了！那麼對於整個模式也就理解了，以後我就知道所有這種配置和引用的“用詞”是分開的，而且它們在官方文檔中的層級關係是怎樣，就可以把這樣的經驗完全通用化，以後類似的問題就不再是問題了。
接着我就在 config 文件中添加了一個 summaryLength：
更新後再看博客：
縮略效果大概只剩下 7 行了。問題解決！
這個過程中，其實也才真正明白，Hugo 搭建的這博客，它的配置和引用配置的模式具體是怎樣怎樣，所謂的 Page Variables 具體又是如何使用；而且更重要的是，一旦明白了這一點，再加上知道了它的官方文檔使用起來這麼方便，那以後遇到同類型的問題就很容易解決了。
回過頭來總結一下：
一般來說，像我上邊分享的這一個研究過程，閱讀源碼的契機是當你需要解決特定問題的時候，這樣的動機，對於“提升編程能力”這麼一個大方向來說，纔是具體切實可實施的，也是最有效的。
擴展開來講，不管是面對什麼方面的問題，往往大家其實都有一個大方向、目標，但是爲什麼那麼多人最終都無法達成目標呢？就是因爲沒有一個真正可行的 roadmap，而沒有這個的原因是沒有一個真正時效性的動機。也就是說大方向、大目標是一種非時效性的動機，而實際問題正是一種需要當下解決的時效性動機，這一點再擴展開來講其實也可以講很多，比如“爲什麼人能自發地堅持做一件事？”、“持續性地刺激、打雞血的作用”……暫時打住了。讀者隨意發散思考吧。
這裏想說的是，當你想要解決問題的時候，如果查找不到相關資料，這時候你就可以去讀源碼！所以，關鍵是動起手來，先去應用一些開源框架/庫，先用起來，用的過程中遇到問題，你就很有機會會很自然地去閱讀源碼。
上邊講的是閱讀源碼的契機、切入點。另一方面，關於如何閱讀源碼，在我這個 case 中，其實很簡單，就是通過對於框架相關知識點的基本理解，大概知道整個框架的運行邏輯，加上思考框架運行的響應效果，那麼經過嘗試，就可以定位到相關源碼的具體位置，然後再一步步根據源碼去調試，去解決問題。而在解決問題的過程中，你又會做一些源碼級的搜索（這就不同於最開始你直接搜索怎麼解決這個問題），比如查找某個屬性的作用和用法，這裏也會自然地用到官方文檔！
當然定位相關源碼位置更專業的方法可能是“代碼級別的專業debug”。
在這整個過程中，你閱讀了源碼與文檔，不知不覺中就會學習到它的源碼是怎麼樣寫的，它的模式、它的代碼編寫邏輯等等內容，這就是在提升你的編程能力！