爲何源碼分析味同嚼蠟？淺析技術寫做中的思惟誤區

優秀的技術社區天天都會生產出很多幹貨內容，《XX 框架源碼分析》就是其中的一類。然而，這類文章每每叫好不叫座，人氣經常不如《手把手教你 XX》。真的是咱們太浮躁了嗎？本文但願用另外一種角度看待這個問題。

從大學教材到技術寫做

中國的大學課堂以照本宣科而著稱，而各個學校本身編寫的大學教材也是出了名的枯燥無味。那麼，一本爛教材通常知足什麼條件呢？這裏隨便列出幾個：

1. 講述的主題自己很複雜，很難脫離課本自學。
2. 課程內容明明早有更好的經典國外教材，卻偏要本身重寫一套。
3. 幾乎不講每一個章節的意義，上來就是大段大段枯燥的定理、證實。
4. 帶了一大堆習題卻不給答案。
5. 小出版社沒有什麼審校，有各類明顯的錯漏。

而後讓咱們對比一下，一篇冷門的《XX 框架源碼分析》又知足什麼條件呢？

1. 分析的框架自己很複雜。
2. 這個框架已經被人分析過不少遍了。
3. 上來就是大段大段的代碼。
4. 某些關鍵的地方被略過了，貼完源碼仍是讀不懂。
5. 排版措辭混亂。

看到了嗎，這徹底一一對應啊！非要說兩者有什麼不一樣的話，可能就是爛教材收錢而爛文章免費了吧。

技術文章的價值觀

能寫源碼分析文章的同窗，多半是有很多靠譜乾貨的，我也毫不是說源碼分析的文章都是垃圾。在此，咱們不妨換個問題考慮一下，即爲何中國的大學教材會遭人唾棄？

沒有對比，就沒有傷害。讓咱們看看高等教育發達的美帝，其本科理工教材的行文方式是怎樣的吧：

1. 告訴讀者，這門課要作什麼，要解決什麼問題。
2. 用大段的文字描述，向讀者展現如何一步步庖丁解牛地分解問題。
3. 給出一些公式和推導過程，講解如何（在簡單情形下）解決問題的原理。

把美帝教材與天朝教材的編寫思路相對比，咱們就能夠總結出兩者在價值觀上的誤差了：

• 天朝：以規範爲本的價值觀，關注如何系統、結構地陳列知識。
• 美帝：以讀者爲本的價值觀，關注如何讓讀者理解知識。

這就是差異所在：許多【技術乾貨】和中國的大學教材同樣，並無把將知識傳達給讀者做爲第一訴求，而是花大量篇幅貼出代碼，告訴你【這個很複雜，我讀懂了！】。然而，即使是硅谷的白板技術面試，代碼量也不會超過 50 行，動輒幾十上百行美其名曰【完整示例】的源代碼，沒有讀過的讀者真的能在短短的幾分鐘閱讀時間裏看懂嗎？

然而，拜【先贊後看】的商業互吹風氣所賜，沒看懂這類文章的新手同窗多半不敢把看不懂的責任歸結到文章的行文思路上，而只會自卑地認爲本身【水平不夠】。因而，新人們爲了提高水平，也投入到了源碼閱讀的大軍裏來，在歷經困難後終於得到了成長，寫出了一篇對一樣框架一樣源碼的一樣分析，想要屠龍的勇士也終於變成了龍。

因此，許多讓人感受晦澀的技術文章，其問題可能並不是出在所介紹的技術內容自己，而是出在更基本的行文思路上。除了上面說起的源碼解析類文章，相似的技術內容還包括：

• 寫給本身看的 Debug 筆記，裏頭都是各類業務細節的流水帳。
• 介紹某個技術點的技術分享 PPT，上來就講一堆高級特性，生怕別人以爲深度不夠。
• 描述模塊接口的文檔，不講本身的特性和概況，直接就丟個【調用示例】把 API 調個遍。
• ……

然而只要稍稍轉變行文的價值導向，按照讀者的閱讀理解方式梳理一下，它們都很容易變成高質量、能讓讀者從中學到知識的乾貨：

• 把流水帳按照多問問幾個 Why 的方式來總結，就是很是有借鑑意義的 Case Study；把其中業務性內容剝離，就是節約後來者時間的踩坑指南。
• 把分享 PPT 整屏整屏的代碼換成直觀的圖示與原理性的僞代碼，就是圖文並茂的入坑指南（Facebook 當年講 React 時，記得那個 PPT 只有寥寥幾行代碼）。
• 把內部不敢見光的技術文檔按照特性、示例、API 的流程講一遍，就是達到開源級別的靠譜文檔了。
• ……

價值觀上哪怕是簡單的改進，最終產出的內容每每都會有很大的不一樣。我我的的例子是：一樣是開發模擬器的總結，第一次寫 實現 Chip8 彙編模擬器 的時候，主題就是【我這個東西很厲害呢】，這時的內容就是典型的技術流水帳；而過了一段時間成長後，改進的 如何用 3KB 不到的 JavaScript 實現微機模擬器 就是一篇旨在分享，但願可以讓新人看懂的教程了。歡迎對照它們各自的行文方式，這樣就能對文章的可讀性作出評價啦。

源碼分析的套路與意義

上面介紹的是【轉換價值導向】的概念。對許多技術文章，理清思路就可以很大地改善閱讀體驗了，不過對於源碼解析類的文章，我的還有個大膽的想法：即它們的編寫難度可能並無標題看起來的那麼大，對新手向的讀者也缺少實際的用處。

這裏我提出一種算法，可以輕鬆地完成對任意框架的源碼分析：

1. 框架都會把底層複雜 API 封裝起來，在源碼裏找到某個調這類 API 的地方。這種地方隨便搜索一下，處處都是。
2. 在這裏加一行 throw 一個異常，運行框架來讓它報錯。
3. 找到錯誤堆棧裏的所有函數，把它們的順序反過來，依次複製到你的《XX 源碼分析》中，並把註釋翻譯成中文。

三步搞定！雖然這個算法十分荒唐而無聊，但筆者確實見過一些文章，寫得就像是經過這個方式堆砌出來的同樣。代碼的藝術在於化繁爲簡，而這樣的內容倒是在化繁爲繁，讀起來難受也是再正常不過的了。

另外，因爲代碼天生的特殊性，最好的代碼閱讀器恐怕不是技術社區的 App，而是強大的 IDE。源碼分析的文章可以拿來下斷點調試、可以拿來 mock 測試、可以拿來看運行時變量內容嗎？有源碼自己就足夠了吧。

這就形成了一個尷尬的結果，即咱們在想要了解代碼的實現細節時，第一選擇每每不是其餘人寫的源碼分析文章。好比，在以前編寫 Chip-8 模擬器的時候，我發現語言文檔中的某一條指令語焉不詳。這時我首先想到去參考的，是前人實現過的 Java 版項目源碼，而不是找一篇《模擬器源碼分析》來讀。既然多數狀況下源碼自己已是 Single Source of Truth，二手材料的優先級還會很高嗎？

不過，對源碼的解析難道就一無可取了嗎？這個想法就更加錯誤了。閱讀源碼的能力絕對算是開發同窗的硬技能，那麼在什麼場合會用到對源碼的解析呢？我卻是發如今一個場合它很是適合：寫 Pull Request 描述的時候。

在向社區提交 PR 的時候，咱們通常會說明【要解決什麼問題、什麼代碼引發了問題、解決方案是什麼】的三部曲，這時候閱讀者都是已有背景知識的維護者，故而這些信息很是有助於 PR 的討論與合併。

回想一下，中國的大學教材也不是一無可取吧？它們在考前複習的時候可方便了呢。源碼解析類的文章就像是這樣的提綱，須要給已經讀懂過一次的人，才能發揮出最大的價值。

總結

鑑於上文中看起來批評了很多內容，故而有必要在最後澄清本文的主題：

• 許多技術文章毫不是乾貨不夠，而是乾貨太乾，以致於閱讀起來十分乏味。
• 對行文思路簡單的改變，都能很大程度地改善閱讀體驗。
• 源碼分析類的內容更適合做爲 Pull Request 的討論描述，而非讓新人【理解框架原理】。

最後對於可能的質疑，做者我的的 Github 裏有很多槽點很高的玩具源碼，吐槽請不要客氣😅…