標籤:

如何在 GitHub 看源代碼學習呢?

比如我在學習 node,我想學習如何封裝某些模塊,應該如何去看呢?


只「看」源碼是沒辦法學習的。你必須將這個項目運行起來,在調試過程中動態分析它的處理流程,才能比較好的弄清楚其中的原理。幸運的是node.js的源碼非常容易編譯和調試,我就是通過下面的步驟來研究它的實現機制的。

先說明一下,我是在 Windows 7 環境下,採用 Visual Studio 2010 來調試的。(當然你要用其他環境也完全沒問題)

第一步,從 GitHub 上把源碼 clone 到本地(或者直接下載壓縮包也行)

第二步,通過其中自帶的 vcbuild.bat 腳本生成完整的 vs 項目解決方案文件

第三步,用 Visual Studio 2010 打開上一步生成的 node.sln 解決方案文件將其中的 node 設為主項目,然後就可以開始編譯和調試了

就這麼簡單。

開始調試後,隨意的跟一下執行流程還是有一定啟發意義的。但是接下來很快就需要明確一些學習目標——我到底想要搞清楚 node.js 哪方面的技術問題?如果我們連自己想研究什麼都不知道,那就純粹是在浪費時間了。

以我自己為例,我比較感興趣的是,node.js 的執行流程是如何啟動 v8 引擎的?做了哪些初始化工作?啟動引擎後,是以什麼方式在什麼時機轉入實際的 Javascript 腳本執行的?一旦進入 Javascript 執行階段,又做了哪些初始化工作?require() 函數是在哪裡實現的,如何實現的?事件機制又是如何實現的……

可以探索的問題很多,但是也應當有所側重。在這個過程里,你會發現一個嶄新的世界。通過學習頂尖的開發人員的作品可以幫助你更快的提升自己的技能。但是很顯然,你付出的努力和汗水也是成倍的。

我是在一年半前開始接觸 node.js 的。現在我最主要的項目基本都是依賴它來完成的。分析 node.js 的實現機制讓我收穫頗豐。但是回顧我的學習過程,最初卻並沒有考慮先從實現機制入手自底向上進行學習。而是站在「快樂傻瓜」的角度自頂向下先學習各項 API 的使用方法,適當的看一點點代碼。這樣學習起來會比較有方向性,和需求貼合的比較緊密,也容易有成就感,容易堅持。如果可能,你不妨也試試這種方法。


node,不是應該從 npm 上面安裝回來,然後想看啥看啥么?這樣簡單粗暴多好。

當然了,我覺得吧,在看別人代碼之前,要做幾件事情。然後過程基本如下。

1. 想想這是個什麼功能

2. 以自己的能力會大致怎麼做

3. 還有沒有其他做法

4. 還有沒有其他做法

5. 還有沒有其他做法

6. 還有沒有其他做法

7. 為什麼我覺得這個做法最合理

8. 我的做法簡直是神一般的存在

9. 看看人家怎麼做的

10. 為毛我和人家想的不一樣

11. 貌似人家的做法更簡單粗暴

12. 他的做法真的更好

13. 好吧,我應該學習他的方法


如果剛開始看代碼就看很大的repo的話,一是知識面太廣,很難消化,二是耗時比較長,不容易堅持。

所以建議先從體積比較小的repo開始看,比如先看一些有用的小插件,然後試著自己提一兩個pull request,慢慢建立起自信後就可以向更大的項目發起挑戰。


看100行源碼,不如自己動手敲10行。然後再考慮怎麼改進,最後尋找相關的項目,別人是如何實現的。這才能成長。


推薦閱讀:

要讀別人的代碼,應該如何入手?
如何優雅的管理 github 上 star 的項目?
如何看待大學CS課程中普遍存在的GOP(Github Oriented Programming)現象?
GitHub入門與實踐

TAG:GitHub | Nodejs |