研究js框架源碼用處真的大么？

01-06

比如angularjs的源碼，時間精力的投入和產出有點不成正比。還是說官方給的api用的熟練就可以了？

研究 JS 框架源碼用處大小在於你想要從裡面知道什麼。

有些概念你看文檔資料不太明白，非常想搞懂，那麼可以研究下源碼，有時候好代碼比文檔容易懂，那麼研究源碼給你帶來了很大的用處。

你遇到了一個棘手的問題，不知道怎麼實現，研究下競品的 JS 源碼看看他們怎麼實現的，然後解決了你的問題，那麼研究源碼給你帶來了很大的用處。

你發現有個庫的用法比較奇特，想在自己組件裡面用，你研究了下它是怎麼實現的，然後成功遷移了，被同事稱讚，那麼研究源碼給你帶來了很大的用處。

你看了一個知乎回答，感覺閱讀過源碼會比較牛逼，雖然不需要，就是硬著頭皮看一遍，然後跟別人說我已經看過 xxx 的源碼，那麼研究源碼除了浪費你時間之外，沒有帶來什麼用處。

合適的源碼閱讀方法請參見之前回答：哪些 JavaScript 框架（庫）的源代碼最值得閱讀和學習？

=== 回答問題

Angular 你在使用的時候遇到什麼無法通過文檔資料了解到的知識嗎？如果有，請尋找相關的源碼看，如果沒有，不需要看，等你有了好奇心和問題再看，強行硬看基本沒用。

如果只是為了做項目，說實話目前市面上任何一個框架的API調熟了，上懟產品經理，下懟客戶就夠了。但是如果對於自身學習而言或者說需要自定義輪子的時候，讀別人的源碼絕對是一種提高。這就相當於讀書時你明明這道題你選C肯定對，但是大神帶你把這道題思路捋了一遍，那種感覺很爽的，下次自己就可以舉一反三。孔子就曾經說過：常在git走哪有不造輪。熟讀源碼三百篇，不會寫碼也會抄。

不過話又說回來了，每次看大神源碼之後有種功力大增，仰天感嘆：程序員沒有輪子跟鹹魚有什麼區別？PM跑來打斷：那個死跑龍套的，新活，兩周poc。

扒幾口盒飯，繼續搬磚咯。

擼源碼並不適合初學者，中文技術圈不適合擼源碼的和適合擼源碼的人，比例大概99：1，這99%的人概念不懂，寄希望一個猛子扎進源碼，本質仍然是貪婪懶惰，想看點直接酸爽的，一勞永逸。聽過摸過這塊狗皮膏藥的，會情不自禁想賣給你。他們沒看過源碼，只是愛上這種感覺。不要成為這樣的人，會浪費寶貴時間和精力。

不理解語言的概念，看到的只是代碼，理解概念，看到的是設計。有些庫的代碼容易讀，也值得讀，也有很多庫的代碼很不可讀，未必值得讀。

源碼不等於質量，源碼也不等於理解。源碼提供了一個抽象層次，在需要的時候會對理解問題有幫助而已。

這個問題，要看在什麼場景下。我們經常講技術有廣度和深度兩個維度。廣度決定你的技術視野，深度決定你解決問題的效率。

顯然，研究源碼，是一種提升技術深度的手段。在廣度足夠的情況下，遇到了問題，而且這問題不能通過查文檔，搜索等方式解決的，並且你需要弄清問題的原理性知識的時候，就需要通過閱讀文檔來解決。對於問題本身，可能覺得性價比不高，但是對於提升自己的技術深度來說，是非常有用的，以後遇到類似的問題，可以非常快速的定位問題的根源所在，知其然和其所以然。

所以，閱讀源碼，最好帶著問題去閱讀，否則會覺得很枯燥，性價比不高。

作為閱讀源碼的狂熱分子，強烈建議通過閱讀源碼的方式來達到精通的目的。

但並不能盲目的閱讀，必須行知有效，如果從沒用過 jquery, 上來就看 jquery 的源碼，只能說自討沒趣。

回到正題，閱讀源碼到底是否值得，我的答案是肯定的，如果不了解其設計思路、架構原理、實現細節，那麼永遠不能說精通，最多只能是熟練。但通過學習其源碼，並能夠造個輪子，那麼在看待與之相關的問題時，你將會看到更多的東西，懂得更多，也能創造出更多。

另外一點想說明的是，js 開源的庫或框架大多數都不足兩千行，多也不過萬行，如果方法得當，其實學習的成本也不會很大。

以 vue （不了解的自行查看相關文檔）為例，官網介紹，它是一個數據響應驅動的前端框架，具有非常簡潔的 API，你可以通過簡單的學習就能夠入手，並經過一段時間的項目實戰，基本就能玩得很溜。那麼你可以說自己精通 vue 了嗎？

* vue 的 dom 更新最小單元是什麼？

* vue 的 dom 更新是同步還是非同步？

* 有遇到過命名衝突的問題嗎？

* 是否 data 中的數據都是響應式的，data 中的數據發生了變化都會觸發視圖更新嗎？

* 對於列表循環為什麼要設 key值？其作用是什麼？

* 數組為什麼不能直接通過索引操作，更改數組的元素後並重新賦值給它與直接更改數組元素的值渲染性能有什麼不同嗎？

* 什麼功能用自定義指令更好而不是自定義組件？

如果沒有深入的去了解其源碼的話，恐怕是不能給出確定的答案的，所以說行之有效的源碼學習是非常值得的。

看源碼是需要你具備一定的水平之後才看的，你要是對以下概念不深入理解的話（我先列幾個框架中常用到的概念），還是先打好基礎

0. prototype

1. 繼承

2. 閉包

3. this

4. apply,call,bind

5. pub/sub模式

6. 正則表達式

更不用說其他什麼數據結構和演算法，設計模式一類的概念了

一個框架是作者思想的載體，你想了解框架的運行機制和作者的思想，首先得知道這個框架想表達什麼，這個框架作者想讓我們怎麼玩，我們實際使用的時候能夠怎麼玩，我們玩得爽不爽，有沒有什麼壁壘和雷區，帶著好奇心，帶著探究本質的精神，去看源碼，debug，畫時序圖，分析之間的關係，你會慢慢從整體架構上了解作者是怎麼架構這個框架的，他為什麼要這麼做，這樣做的好處是什麼，有更好的方案處理嗎，等你對框架庖丁解牛了，你也就達到了你的目的。這個時候，你可以總結，學習其中的思想，數據結構，演算法，設計模式，奇技淫巧或者自己不知道的事情。其實到這個時候，你的收穫已經大大超過你剛開始只是了解框架運行機制和作者思想的初衷了。當然，這個時候你也完全可以照本宣科的擼個類似的東西了。哎，比如說，這個時候，你的公司有個這樣的業務場景，你恰好可以運用自己所學的東西發揮自己的價值了。然後項目完成，老闆覺得你做得很不錯，升職加薪指日可待了。之後的事。。。可能就有無限可能了。。。

看優秀的源碼才能知道大牛在想些什麼

比如prototype.js是很多人首推薦的

講真，沒有目的的看，看不出什麼門道，如果你能給js框架提個issue或pr，那用處很大

看你對自己的定位了
如果想做一個快樂的技術從業者，以後都打算吃技術飯，那麼這些開源框架的源碼是很值得學習的。其中的設計思想，實現技巧都是很有水平的。讀讀代碼能極大的提高自己的水平。

這方面我想多說兩句，讀框架源代碼是有技巧的。經常看很多新手一上來就讀最新版本的源代碼。讀了幾天（甚至幾小時）就迷失在調用棧中，一個框架幾十層的調用棧非常正常。於是乎痛苦不堪，決定放棄。其實源代碼的閱讀應該首先先了解原理，再去看具體實現。可以選擇框架的0.x版本去閱讀，雖然可能代碼和最新的有很大區別，但是基本思想不會變。讀源代碼其實並不是目的，只是方法，理解框架原理才是目的。

另一方面，如果想干幾年程序員，轉產品經理或者管理層。那麼可能更加需要去了解業務相關的知識。技術上掌握會用就ok。提升空間可能就不在技術上。

綜上，需不需要讀源代碼取決於你對自己的未來職業規劃。

就像玩遊戲一樣，技能點不能加錯呀

在基本功紮實的情況下。

先去用熟那個框架，了解那個框架的特性，適合解決的問題，順便去看看一些大牛對這些框架的看法。

之後從這個框架最核心的api和特性開始分析，慢慢了解其實現原理。到這一階段開始有針對的閱讀不同模塊的源碼(不用太急，分模塊看)。

剛畢業不久，前段時間也在研究一些框架和類庫的源碼，以上算是我自己讀一些框架的過程心得吧。

重要。但是是一個循序漸進的過程。不是一上來就擼源碼的。正確的順序是，先是js基礎，框架的理念學習，框架按照最佳範式熟練使用，大量的項目實踐，項目開發效率構建流程優化，然後才是通讀源碼，從而進行項目性能優化，提升debug能力，技術重構。

以你在學習的angular為例

1.你要先學習ng的雙向綁定開發模式，mvvm架構理念。

2.框架使用規範。合理使用依賴注入實現模塊化中，service，factory等的正確使用場景，如何實現組件化，如何實現良好的解耦分治數據隔離。

3.提升開發效率。提升directive復用率，使業務邏輯更加清晰，提升構建速度，版本管理，多人合作管理。

4.通讀源碼。理解dirtycheck，知道為什麼單頁綁定數量不應該超過2000個，知道要用once來優化。知道ng依賴注入的實現方式，從知道為什麼某些情況下使用uglify會產生問題。源碼不要求通讀與背誦，源碼的理解服務於項目。

5.發現ng過時了，開始看react和vue...然後重構。。。

是啊，你什麼時候聽說做設計要看photoshop實現原理的了

從問題著手看源碼意義大一些，如果你是老司機，帶著思想按理解一塊一塊看是可以的。我嘗試過，一次看不了太多，拆分了慢慢看更好點，還有要知道為什麼這麼寫，而不是這樣寫的表面意思。

重點在於你希望從源碼中獲得什麼，如果只想要熟練使用，沒有更高的需求，那麼，看看文檔，能夠滿足實際需求即可。如果想學習其中的實現方法，思想，可以借鑒學習。

很多碼農都想有自己的庫，學習這些源碼，以後完成自己的庫的時候可以參考，有什麼好的思路可以借鑒。

當然，如果可以很好地理解，在用這些庫的過程中出現問題，也可以更好的解決。

大！

每一個優秀的庫與框架，都像是一本名人傳記，

中間有很多新鮮的思路值得學習。

同時每一個庫與框架都有他最初的目的，它始終是別人的代碼。

所以肯定有一些不適用於我們自己的業務場景，

只有閱讀過代碼才能對全局有更好的掌握。

讀源碼這事沒有什麼範式，最終能收穫多少可能受到很多因素影響，源碼好不好讀，思路跟你合不合，你的知識儲備夠不夠，如果一切具備的話，收穫會很多，一些小技法或者一些解題思路，還是挺珍貴的。

就像讀一本好書一樣，你可能得到作者深思熟慮後的思想結晶，也可能沒讀懂，或者不不屑一顧，或者乾脆知難而退，選一個合適的level其實很重要。

還是比較有幫助的。

通過閱讀源碼，能夠讓開發者在開發中更好的了解代碼運作的流程和原理，在此基礎上才能夠寫出更優雅，性能更好的應用。同時，很多框架之所以流行，其設計思想也必然有著極其精妙的地方，通過學習源碼，汲取這些優秀的程序設計思想，無形中也能夠提升自己的技術水平。

不過我認為源碼閱讀並不應該一上來就通讀代碼，而是應該有側重的循序漸進，首先選取框架中最精華最重要的一些部分來學習。比如對於koa來說，應該優先學習其非同步回調同步化的機理，以及中間件的實現原理。

還有一種學習的方法我認為是逆向的，就是在充分理解了一個框架的原理之後，可以自己嘗試實現一個類似的簡易框架，底層一些細節可以摳的不那麼細，只需要實現最核心的一些功能和思想即可，這種方法不但鍛煉自己的動手編碼能力，同時在實踐中也更加深了對相應框架原理的理解。我自己就通過這種方法研究了諸如koa，redux，requirejs等一些庫和框架，覺得還是十分有益處的。底下是兩篇我對於koa核心機制的分析，就是通過自己寫一個對應的實現，來加深理解：

深入探析koa之中間件流程式控制制篇 | 馬齡陽的個人網站

深入探析koa之非同步回調處理篇 | 馬齡陽的個人網站

會開車的多了，即會開車又會修車的不多。

有沒有意義，取決於你的目標是老司機還是駕駛員。

不然怎麼更好地給框架寫拓展，其實最重要是從源代碼中體驗框架所宣傳的理念，學各種思想和技巧，這樣甩開這個框架，你自己造一個簡易版也能完成你的任務

說一下個人觀點吧，其實鄙人是覺得很重要的，為什麼呢？一個是很多框架都是至於原生寫的，所以很多原理性的東西對於技術了解或者是個人發展來說是非常重要的，不但鍛煉你的邏輯能力，還鍛煉你的思維方式，簡單說是讓你知道這東西是怎麼來的，有一天也許你們要做類似東西時有一個參考。因為很多東西對你來說可能是不合適業務發展的，這時候自己寫一個東西就顯得特別重要了。