如何看待Linus「從不認為閱讀別人的代碼是了解某個想法的一種有用的方法」言論？
採訪 Linus Torvalds 的問答整理
- [3] 是否會閱讀其它操作系統實現的源代碼，來瞭解某個功能是怎麼實現的，或者純粹是為了娛樂或學習的目的？
- Linus
表示他從不認為閱讀別人的代碼是瞭解某個想法的一種有用的方法，所以他從不會為了瞭解某個功能是如何實現的去閱讀代碼。他閱讀代碼通常是為了瞭解某個功能
為什麼不工作，這些代碼通常也不是別的操作系統的代碼。比如他閱讀 zlib 的代碼，是因為他想知道為什麼 git
在運行某些庫函數時耗了那麼長時間。- 通常他會通過閱讀某些書籍來瞭解某些知識。比如他通過閱讀 &
來瞭解 Unix 是如何工作的，以及人人都知道的 & 。 其實我有我自己的一套路子，我也知道自己不是Linus，大牛說的話不一定是真理，也許只是個性流露，但他的話讓我有所思：這年頭，還是深深覺得看書比看代碼更重要。以前代碼看得多是為了彌補書看不懂的弱理解力，現在又回到書籍閱讀的節奏上，哪怕是新項目也從相關手冊和論文入手。代碼接觸多了，理解力得到提升，愈發覺得文字比編程語言才是交流思想的更好途徑，另一方面自己愈發重視思想思維，至於實現則是信手拈來之事。
之所以提這個問題是因為我很有興趣知道別人是怎麼看這個問題的，純屬交流。
Jeff Atwood說過這麼一句話：「Code Tells You How, Comments Tell You Why」.
其實，Jeff這句話並不準確，另外，我把其擴展一下——
代 碼 =&> What, How Details
文檔/書 =&> What, How Why可見，代碼並不會告訴你 Why，看代碼只能靠猜測或推導來估計Why，是揣測，不準確，所以會有很多誤解。而且，我們每個人都知道，Why 這個東西是讓你一通百通的東西，也是讓人醍醐灌頂的東西。（這也是樓主為什麼喜歡看書的原因，我也是）
但是，代碼會告訴你細節，這是書和文檔不能給你的，細節是魔鬼，細節決定成敗，這樣的話我們不但聽過很多了，我們做技術的也應該體會過很多了。當然，我們也要承認，這些代碼細節給人帶來的快感畢竟不如知道Why後的快感大（至少對我是這樣的）
書和文檔是人對人說的話，代碼是人對機器說的話。
所以，- 如果你想知道人為什麼要這麼搞，那麼你應該去看書，看文檔（就像Effective C++、Code Complete、Design Pattern、Thinking in Java等等這樣的書）
- 如果你要知道讓機器幹了什麼？那你應該看代碼！(就像Linus去看zlib的代碼來找性能問題)
因此，我認為都比較重要，關鍵看你的目的是什麼了。
- 如果，你想要了解一種思想，一種方法，一種原理，一種思路，一種經驗，恐怕，讀書和讀文檔會更有效率一些，因為其中應該會有作者的思路的描述。比如像Effective C++之類的書，裡面有很多對不同用法和設計的推敲，像TCP/IP詳解裡面也會對TCP演算法的好壞的比較……這些思維方式能讓你對技術的把握力更強。光看代碼很難達到這種級別。（現在你知道什麼樣的書是好書了吧 ;-)）
- 如果，你想了解的就是具體細節，比如：某協程的實現，某個模塊的性能，某個演算法的實現。那麼，你還是要去讀代碼的。因為代碼中會有更具體的處理（尤其是對於edge case或是一些代碼技巧的東西）
另外，看看下面的幾個現像，你可以自己比較一下：
- 很多時候，我們去讀代碼，那是因為沒有文檔，或是文檔寫得太差。
- 很多時候，你在google, stackoverflow, github過後，你會發現，你掌握的知識就是一塊一塊的碎片，即不系統，也不結構化，更別說融匯貫通了。你會覺得你需要好好地讀一本書，系統地掌握知識，這種感覺你一定很強烈吧。
- 很多時候，在你去讀別人代碼的時候，你會因為基礎知識或是原理不懂，或是你不知道為什麼的情況下，你要麼完全讀不懂代碼，要麼就是會誤解代碼。（比如：如果你沒有C語言和TCP原理的基礎，你根本讀不懂linux下TCP的相關代碼的。我們因為誤解代碼用意而去修改代碼造成的故障還少嗎？）
- 很多時候，看到一個演算法時或是一個設計時，比如Paxos這樣的，你是不是會有想去看一下這個演算法的實現代碼是什麼樣的？如何才能實現的好？（但是如果你沒看過Paxos的演算法思想，我不認為你光看代碼實現，就能收穫到Paxos的思想）
- 很多時候，當你寫代碼的時候，你能感覺得到自己寫的代碼有點彆扭，怎麼寫都彆扭，這個時候，你也會有想去看別人的代碼是怎麼實現的衝動。
- …… ……
從代碼中收穫得大，還是從書中收穫的大，不同的場景不同的目的下會有不同的答案。
這裡，談一談人的學習過程吧，從學習的過程中，我們來分析一下看代碼和看書這兩個活動。
人對新事物的學習過程基本都是從「感性認識」 到 「理性認識」的。- 如果你是個新手，那應該多讀代碼，多動手寫代碼，因為你需要的是「感性認識」，這個時候「理性認識」對你來說你體會不到。一是因為，你沒有切身的感受，告訴你Why你也體會不到，另一方面，這個階段，你要的不是做漂亮，而是做出來。所以，在新手這個階段，你會喜歡Github這樣的東西。
- 如果你是個老手，那麼你有多年的「感性認識」了，你的成長需要更多的「理性認識」，因為這個階段，一方面，你會不滿足於做出來，你會想去做更牛更漂亮的東西，另一方面，你知道的越多，你的問題也越多，你迫切地需要知道Why！這個時候，你就需要大量的找牛人交流（讀牛人的書，是一種特殊的人與人的交流），所以，這個階段，你會喜歡讀好的書和文章的。
然而，對於計算機行業這個技術創新超強技術繁多的行業來說，我們每個人都既是新手，也是老手。
（最後，謝謝樓主專門來微博上邀請我回答）
我從來都沒覺得看源代碼學習適合我。
看源碼容易陷入無休止的細節，我只在 debug 的時候看源碼。
反而聽作者講實現思路和大體脈絡是最有效的。
指路靠大佬，細節自己搞。
如果有書，那肯定看書最好，因為書是人和人交流的一個平台。但現實是，很多工具都不會有現成的書可看，那麼當你使用它碰到困難或瓶頸的時候，就需要拿起源碼來閱讀了。
其實每個工具的源碼都是作者的思想表達，代碼展示的是這個工具如何在計算機中工作的抽象模型。如果你想了解代碼如何工作的更深的細節，就讀源碼，看書是達不到這種粒度的。
而對於linus這種大神來說，整個虛擬世界都是他創造的，幾乎大部分軟體的工作原理估計他都心中有數，一念一世界的境界，他不需要讀源碼，他讀源碼估計像老師看小學生的作文（可能有點誇張），就像題主說的，他看zlib源碼是為了看看這小子代碼怎麼寫的，怎麼把俺的git搞這麼慢！牛人通常比較偏執，只專心做自己的
對我來說, 看書是為了系統性地查漏補缺, 看別人代碼一般是想要進行二次開發. 確實偶爾會從中學習到一些, 但是相較於看代碼的時間成本, 並不是特別划算, 算上燒死的腦細胞就...
我覺得我是認可 "閱讀別人的代碼並非了解某個想法的有效方法" 這一觀點的, 除非沒有其他更好的路子可以走.
對於開源社區來說, 有時候閱讀相關代碼是 contribute 的前提, 但並不意味著通過閱讀代碼獲得的知識性的收穫是等價於時間上的付出的 (當然很多可能從來不在開源社區里閱讀別人代碼但依舊吹捧開源能從本質上提高知識傳播速度的人或許不這麼想).讀好書比看代碼效率高，但是識別好書相當的難。這個道理一千年前就有總結了：書山有路勤為徑。為什麼Linus說他不讀代碼，因為他讀代碼「爬山」的時候那個山才一點點高啊！然後他就一直站在山頂上一起成長。這個問題的可以拆分成：
- 如何掌握核心思想讀代碼無疑是最笨的方法，但是風險最小，就好比沿著盤山公路爬山。讀書是個捷徑，別人總結好了思路把精華都講出來了。風險就是讀了一本作者自己也半吊子的書，被帶到溝里了。就好比坐纜車，也許就跑到別的山頭上去了。
- 已經掌握核心思想後如何進步不讀代碼了，寫書。
他講的挺對的。＝＝＝＝＝＝＝
- 讀源碼就想發現一個工具箱，挨個擺弄裡面的工具，慢慢摸索出工具為什麼這麼設計以及工具間如何組合使用。
- 讀書（文檔）就像發現了工具箱的使用說明書以及設計原理，照著說明書去使用工具肯定要比自己摸索來的快和有效。
看代碼就是比看書要慢, 這是顯而易見的.
只是很多情況下你沒有書可以看, 就只能看代碼了.- 搞清楚某個非核心的API族是怎麼用的（參數怎麼構造、先後順序）看別人的代碼片段比自己去研究一遍節省時間。核心API族必須仔細研究，不能圖省事一味參考別人
- 演算法類的主要看專門論述的書籍和論文。代碼看不看不是很重要
- 架構類的主要靠作實驗、作性能測試。對瓶頸運用自己的智慧來解決（無論用什麼辦法，瓶頸解決了就是解決了）。基本上沒有什麼例子可以100%照搬，盲目照搬往往還會壞事。架構類也靠啟發，讀讀雜誌上的文章收穫很大
- 產品構思類的，主要看思想境界。這個也和代碼無關
我覺得應該理解為 "高手看別人寫的代碼那就是一坨屎"
話說我在第一次寫代碼的時候如果沒有事先閱讀過hello world源碼，我想我是絕對寫不出一行完整的代碼來的。
對於資質一般的屌絲來說，過程是這樣的，先讀文檔，然後實現，然後對比大牛的實現，改進自己的實現，再讀文檔，感悟一把。
當然現在，Linus 表示他已經不再閱讀任何操作系統書籍，甚至計算機相關的書籍也很少了。
你怎麼不順便把原文中這一段也貼上?看過 linus 自傳就知道，他看那些個書的時候，是他剛開始寫 linux 的時候。那個時候他看了那本操作系統設計與實現，就開始寫自己的系統了。。根本就不能推導出你那些關於看書和看代碼之間優劣之類的結論。。先讀文檔，知道這東西是什麼，然後有興趣再讀代碼，看看他是怎麼做的。大牛天賦異稟，非我凡人能比
不請自答。對@陳皓的答案不能再贊更多...特別是出來實習後體會更是深切！！贊！！
---------------------------------------------------------------------------------------------------------------------------------------不要沒有大神的命（智商？效率？）卻得了大神的病。這個問題讓我想起小馬過河的故事，別（牛）人怎麼說我們在沒有實踐之前便信了，然後就去一味的模仿。當然，無可否認，模仿大神的學習方式縱然一定程度上能提高自己的水準。可是在學校待了那麼多年，難道你沒發現身邊那些每天同樣是伏案苦讀寒窗十載，接收著相同的知識灌溉，每天重複著同樣的勞動的同學，而輸出結果呢？有的從來面帶笑容淡定優雅不費吹灰之力就去了清華北大，一切都是那麼理所當然；而有的......
拿高中學習經歷來說是因為大家的學習方式和學習時間都差相差無幾。造成如此差異的結果的原因我不說大家也都明白。所以，Linus的學習方法的普適性是有限度的，不是對每個人都合適的。學習是一個考驗智商和毅力的腦力活動，與蠻力不同的是在學習的過程中大腦所處的活躍狀態，這決定著我們是在主動學習還是在被動學習。有些人喜歡看文檔綜述來快速獲得知識和經驗，有的人卻喜歡沉浸在原滋原味的源碼之中來獲得滿足感。效果因人而異，沒有人說看源碼就一定比看書籍高端或者怎樣怎樣牛逼，找到適合自己的學習方法最重要！！！（很俗卻但很真理的一句話）
還有一個原因很重要，Linus之所以這麼說 我覺得是他在閱讀書籍的時候對於其所描述知識的實現方式和細節有非常肯定的把握和信心，畢竟人家是寫操作系統的...再讀源碼不是純粹浪費時間么。當然，噴人之前我覺得應該會看一下... =.=#
最後，我想說的是對於一個剛剛熟悉的知識和概念，在閱讀完書籍之後不看看源碼（如果有的話）難道心裡不痒痒么？！代碼是實踐，看書更多是理論性的認識，大部分人還是先實踐後理論，兩者不衝突，想要提高代碼質量，提高悟性還是多看書，實踐+理論多配合。只看書看文檔，那就是紙上談兵了。但是coding 要多思考這件事情本身就是很理論，你會發現，交流的更多的思想，談的理論。可以說理論是戰略核心，代碼是策略重點