首先要說，這并不是一篇教你如何學習的文章，因為到今天為止我也沒有找到一種通用的方法來解決如何學習的問題。但是在探索的道路上，我確實產生過一些思路，我想把這些思考的過程分享出來讓大家探討。如果這對你有幫助的話，那我會非常高興。

我最近在學習 Rust ，這是一門很酷但是相對冷門的語言（學習冷門語言可能是我的一大愛好，比如我就非常喜歡 CoffeeScript ，這是 JavaScript 的一門方言）。自從在某些語言的舒適區待久之后，經常會產生自己無所不能的錯覺，這也是我不斷想學習新語言的一大動力。

而我的學習過程跟大多數人類似，就是先在網上找文檔然后自學。而在看文檔的過程中，我就發現了一些問題。

手冊的作用

“去看文檔嘍。”這是老鳥在面對新手時最喜歡扔的一句話，我通常也是這么扔給自己的。但當你打開一門語言的手冊，你會發現它除了教你語法外，幾乎沒有教你什么其它東西。于是你會陷入這樣一個境地：

“背下來了么？”
“背不下來，太難懂了。”
“再看一遍，給我背下來。”
。。。
“背下來了么？”
“大部分背下來了。”
“給我寫個程序，實現個XX功能。”
“不會。。。”
“。。。”

在一個高級開發者眼里，你會了語法理所當然就應該會寫程序了，但實際情況并非如此。這讓我想起前段時間跟一個朋友關于目前編程教育市場的一個討論。我出于自己的經驗提出一個想法：讓大牛開發者來教新手入門。在我的設想中，大牛開發者擁有強大的實戰經驗，以及豐富的專業知識，更是自帶光環，這不比現在市場上那些半吊子的講師好多了。在我為自己“偉大”的想法得意的時候，朋友給我澆了一盆冷水。他告訴我這樣根本行不通，大牛根本不知道菜鳥需要什么知識，你可能以為基礎語法講清楚就好了，人家卻連編輯器是什么都不清楚。設想一下，讓一個大學教授去教一群小學生，這對兩者來說都是一種災難吧。

這些語言的創造者，或者文檔的作者，無疑都是一些大神。它們在撰寫一個語言手冊的過程中，只能盡量負責地把這個語言的全貌準確地有組織地展現給你。然而這種全面的展現，對于一個沒有任何引導的初學者來說并不完全是一件好事。簡單來說就是，你會在一些次要的事情上浪費太多時間，而一些主要的概念又沒有理解透徹。

關于看真實代碼

當覺得文檔滿足不了你的時候，老鳥們往往會扔給你第二招：看代碼。看什么代碼呢？那還用說，當然是被業界奉為經典的，在 GitHub 上至少有一萬顆星的知名開源項目代碼啦。

當你懷著崇敬的心情，打開扔給你的網址，看著滿屏幕的代碼時，你會對自己問出那三個經典的哲學問題。這是什么東西？它是怎么做到的？為什么要這么寫？搞不好某些人還會因為驚嚇過度，從而失去了學習下去的信心。

那么讓我們一起來看看這些代碼里有什么鬼東西，會嚇得新手信心不足。

大段的注釋

說一件事你們不要笑，在我還是個萌新的時候，我曾經對這些穿插在代碼中的神秘文字產生了深深的困惑，我還以為它們對代碼有某種加成作用，以至于我還試驗過把注釋去掉會對代碼執行產生什么影響。而現實中好的代碼會讓后面的維護者方便很多，但不好的甚至錯誤的注釋會讓人迷惑不已。

語法糖

語法糖是個好東西，它大大簡化了我們的編程過程，高手用起語法糖寫起代碼來簡直不要太爽，所以越強大的項目這玩意兒越多。但是對于初學者來說，語法糖隱藏了一些細節，而且讓語法看起來很怪異。有些代碼如果你用標準語法來寫是很好懂的，但如果用語法糖來寫的話很難讓人一下子明白。

初學者為了弄懂這些語法往往要花大量時間，但其實這些時間在這個階段是沒必要的浪費。你看不懂它覺得它是一個很重要的東西，其實它只是一個做工精巧的小玩意兒，離開了它這些代碼照樣能工作。而隨著你的經驗豐富，也可以隨時隨地用起來，用的方法可能也不盡相同。

代碼里的重點

對于一個開源項目來說，往往 50% 的代碼可能都是在適配各種不同的運行環境，將系統的 API 抽象成項目里通用的接口，這部分代碼除非你自己要做類似的項目，要不然的話對初學者來說參考意義不大。更何況，為了適配某些系統奇葩的運行環境，開發者往往會大開腦洞，創造出一些非常奇怪的代碼。這些旁門左道充滿了玄學和不確定性，初學者看多了可能會發生如武俠小說里練功出差錯的結果：走火入魔。

剩下的代碼里 20% 是項目內部的接口抽象和定義，最后 30% 才是真正值得看的東西，它們往往散落在各個地方，但又為了一個設計核心服務。讓初學者識別出這些代碼來，未免太強人所難。

野文檔

這是我自己的一個定義，我把一切非官方的開發文檔都稱為野文檔。初學者會在搜索引擎里得到大量的相關文檔，他們很多是學習心得，很多人在寫這篇文章時水平可能比你也高不了多少。這就造成了這些文檔的水平參差不齊，所面向的重點也不同，也許你花了大把時間弄懂的是一個錯誤的或者過時的知識。而大部分號稱教你入門的文章，可能也就是告訴了你如何搭建一個運行環境，這門語言的精髓和重點作者自己估計也沒弄明白。

而如果你碰到一篇被奉為經典的好的入門文章，那你真的要好好感謝作者。因為這意味著作者付出了大量的深入思考，深入淺出這四個字說起來簡單，做起來可是需要相當的功底的。

相對較好的做法

在這么多語言的學習過程中，我也總結了一些相對比較好的學習方法。我認為看代碼是非常有必要的，因為光死記語法是無法掌握好這門語言的。但是去看一些大型項目代碼的缺點我在上面也說了，到底該如何是好呢？

我建議大家可以去看官方給出的，專門供初學者學習的 Step-By-Step 代碼，這種代碼一般在官方的文檔頁就可以找到鏈接入口，它有如下好處：

1. 由淺入深，富有層次。這些代碼往往是跟隨者文檔的深入，慢慢把語法細節展開的。不會一下給你展現太多，讓你無法 GET 到重點。每段代碼都會有一個重點要表現的特性，這樣看起來會一目了然。
2. 有質量保證。這些代碼的撰寫一般是官方人員負責，這可以在很大程度上保證準確性。
3. 更新及時。我們知道很多語言的細節是會隨著版本的升級有所改變的，而很多網上的第三方文檔往往缺乏維護，但官方文檔一般都會同步更新。

我建議大家一邊看手冊一邊看代碼，這樣印象會更深刻。眼睛看了之后，我認為要盡快找一些好的例子來練手，不需要一上來就搞比較復雜的大型項目，也是由淺入深。這種練手項目去哪里找呢，很多語言的 tutorial 板塊就是干這個的，做的比較完善的甚至還提供在線的教學體驗環境，大家應該好好利用。

寫在最后

這篇討論學習方法的文章引發了我的一些額外思考。我經常在開發者社區里看到老鳥和初學者互懟，寫這篇文章的過程也讓我理性思考了產生這些矛盾的原因。總的來說就是一些信息的不對稱造成的。老鳥認為這個問題根本不是問題，網上一搜一大把，不愿多講甚至冷嘲熱諷。而初學者卻覺得這些信息根本理解不能，老鳥的嘲諷就是一種羞辱。

我認為要打破這種不對稱需要雙方付出耐心，而這種耐心的付出是相互的，你付出的多回報的就越多。而最先邁出付出這一步的，應該是初學者，畢竟從情理上來說是你請求人家辦事。而你需要付出的不過是把自己的問題講明白，說出你的思考過程，附上必要的信息。一個好學的人是不會讓人討厭的，但前提是你得有一個不讓人討厭的姿態展現出來。