如何學習一門新的語言

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

我最近在學習 Rust ，這是一門很酷可是相對冷門的語言（學習冷門語言多是個人一大愛好，好比我就很是喜歡 CoffeeScript ，這是 JavaScript 的一門方言）。自從在某些語言的溫馨區待久以後，常常會產生本身無所不能的錯覺，這也是我不斷想學習新語言的一大動力。

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

手冊的做用

「去看文檔嘍。」這是老鳥在面對新手時最喜歡扔的一句話，我一般也是這麼扔給本身的。但當你打開一門語言的手冊，你會發現它除了教你語法外，幾乎沒有教你什麼其它東西。因而你會陷入這樣一個境地：

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

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

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

關於看真實代碼

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

當你懷着崇敬的心情，打開扔給你的網址，看着滿屏幕的代碼時，你會對本身問出那三個經典的哲學問題。這是什麼東西？它是怎麼作到的？爲何要這麼寫？搞很差某些人還會由於驚嚇過分，從而失去了學習下去的信心。

那麼讓咱們一塊兒來看看這些代碼裏有什麼鬼東西，會嚇得新手信心不足。

大段的註釋

說一件事大家不要笑，在我仍是個萌新的時候，我曾經對這些穿插在代碼中的神祕文字產生了深深的困惑，我還覺得它們對代碼有某種加成做用，以致於我還試驗過把註釋去掉會對代碼執行產生什麼影響。而現實中好的代碼會讓後面的維護者方便不少，但很差的甚至錯誤的註釋會讓人迷惑不已。

語法糖

語法糖是個好東西，它大大簡化了咱們的編程過程，高手用起語法糖寫起代碼來簡直不要太爽，因此越強大的項目這玩意兒越多。可是對於初學者來講，語法糖隱藏了一些細節，並且讓語法看起來很怪異。有些代碼若是你用標準語法來寫是很好懂的，但若是用語法糖來寫的話很難讓人一會兒明白。

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

代碼裏的重點

對於一個開源項目來講，每每 50% 的代碼可能都是在適配各類不一樣的運行環境，將系統的 API 抽象成項目裏通用的接口，這部分代碼除非你本身要作相似的項目，要否則的話對初學者來講參考意義不大。更況且，爲了適配某些系統奇葩的運行環境，開發者每每會大開腦洞，創造出一些很是奇怪的代碼。這些旁門左道充滿了玄學和不肯定性，初學者看多了可能會發生如武俠小說裏練功出差錯的結果：走火入魔。

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

野文檔

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

而若是你碰到一篇被奉爲經典的好的入門文章，那你真的要好好感謝做者。由於這意味着做者付出了大量的深刻思考，深刻淺出這四個字提及來簡單，作起來但是須要至關的功底的。

相對較好的作法

在這麼多語言的學習過程當中，我也總結了一些相對比較好的學習方法。我認爲看代碼是很是有必要的，由於光死記語法是沒法掌握好這門語言的。可是去看一些大型項目代碼的缺點我在上面也說了，到底該如何是好呢？

我建議你們能夠去看官方給出的，專門供初學者學習的 Step-By-Step 代碼，這種代碼通常在官方的文檔頁就能夠找到連接入口，它有以下好處：

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

我建議你們一邊看手冊一邊看代碼，這樣印象會更深入。眼睛看了以後，我認爲要儘快找一些好的例子來練手，不須要一上來就搞比較複雜的大型項目，也是由淺入深。這種練手項目去哪裏找呢，不少語言的 tutorial 板塊就是幹這個的，作的比較完善的甚至還提供在線的教學體驗環境，你們應該好好利用。

寫在最後

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

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

拓展閱讀

• 對 SegmentFault 社區提問標準的一些解釋