來源：《程式設計師》
作者在 IT 業從業多年，翻譯過多本技術圖書，對英語的學習方法也有頗多積累。在本文中，他更是敞開心扉，分享了自己壓箱底的三大絕技。
總的來說，程式設計師算是英語水平比較好的群體，因為在這個行業，英文資料是最全面、最及時、需求也最迫切的。因此，據我觀察，即便剛入門不久的程式設計師，面對陌生的問題，一般也能查閱英文文件，找到需要的資訊。但同時，我也發現，經常閱讀英文文件的程式設計師，英語水平許多時候卻並不像“經常閱讀英文” 的樣子。下面我列幾點自己的學習心得，供大家參考。
讀文件不能只讀程式碼
讀文件只讀程式碼，是很多程式設計師的習慣，也是導致程式設計師雖然讀了很多英文資料，英文水平卻沒有相應提高的原因之一。以前曾在《程式設計師》上看到介紹 閱讀技術圖書方法的文章，提出過“先程式碼後文字”的方法，也就是“先看程式碼，看不明白再看文字”。這種閱讀法能極大提高閱讀效率，但如果技術圖書只看程式碼 就足夠，還要文字幹什麼呢？很多時候，程式碼只是冰山一角，程式碼背後的思維和邏輯才是真正的重頭戲，只有寫成文字才能解釋，也只有閱讀文字才能理解。
比如，程式碼都是“x = 5;”，有時的說明是x should be not more than five，有時的說明是x should be no more than five。不查詞典，你能弄清楚兩種說法的區別嗎—前者是“x必須小於等於5”，後者是“x應當只有5”，意思不同，應用的方法與場合也不相同。
這些年來經常有希望翻譯技術文件的程式設計師來找我討論翻譯問題，希望瞭解一些句子應該如何表達。一開始，我也認為這是中文表達的問題，但後來逐漸 發現，其實更多的問題出在英文閱讀上，所以我的回答經常是：你覺得作者這裡說的是什麼意思？引導對方把原文的意思逐步表達出來，其實這時候，真正的譯文已 經浮出水面了。
最近的例子來自這句話：“But as with any web-based system, atom-based solutions trade scalability for latency， making atom often inappropriate for very low-latency notifications”。這句話之所以難翻譯，問題似乎在於，除去句子的主幹，之前有一個 But as…，之後又有一個 making…。然而我最後發現，對這個句子有疑問的程式設計師其實根本沒搞懂 trade…for…的用法（翻譯為“基於 atom 的解決方案需要權衡延遲和性擴充套件性”），如果明白它是“犧牲 xx 換取 xx”之後，整個句子就相當好理解，也非常容易翻譯了：與所有基於 web 的系統一樣，基於 atom 的解決方案為追求可擴充套件性，增大了延遲，所以 atom 通常並不適用要求極低延遲的提示。
要解決這個問題，首先要做的是改變“只看程式碼不看文字”的習慣，至少要做到“閱讀文字之後，認識到它的意思與程式碼是一致的”；其次是通過閱讀純文字的英文資料來學習某些新的知識（比如關於深入原理的細緻講解），這個方法我推薦給許多朋友，非常有效。
注意讀音
以前總聽人說，中國人學了很多年英語，其實是啞巴英語。不知道現在的情況有多少改觀，但就我所見，不少程式設計師雖然閱讀了大量英文資料，也會加入英文的討論組，也敢開口說，但還會在讀音上出現許多問題。這裡說的“讀音”，並不是字正腔圓的口音，而是一些術語的讀音。
眾所周知，電腦科學的術語來源非常廣泛。例如設計模式裡，有一種模式叫 Facade，許多人往往直接讀作[‘fəkɑ:d]，其實這個詞來自法文，正確的讀音其實是[fə’sɑ:d]；再比如虛擬碼的“偽”pseudo，正 確的讀音是[‘su:dəu]，但我很少遇到程式設計師能把它讀對，許多人乾脆不會發這個音。
也許有人說，這些問題不重要，大家“將錯就錯”，約定俗成就得了，但事情沒有這麼簡單。最近我參加某個技術聚會，有一位嘉賓（技術高手）把框架 名 chameleon（變色龍）讀成了[‘t∫əmiljən]，而正確的讀音是[kə’miljən]，因為沒有文字資料，許多人聽了半天才知道他說的是 什麼，一些不熟悉 chameleon 的聽眾更是到結束也沒明白。中國人聚會尚且如此，如果有機會參加中外技術交流，讀錯造成的問題就更大了。
要解決這個問題，有一個非常好的辦法，就是學習美國大學的公開課，耶魯、史丹佛等學校的計算機系都放出了許多高質量的公開課，學習其中的一些精 品課程，不但能夯實基礎，還能順帶學會許多每天都要遇到但不會或者讀錯的術語。比如我就從中學到，資料型別 char 的讀音是[kɑ:]，而不是[t∫ɑ:]。
鍛鍊英文表達
如果你背過單詞，大概聽到過“被動單詞”和“主動單詞”的說法，前者是指“看到了能認出來”的單詞，後者指“表達時能主動應用”的單詞。據我觀察，許多程式設計師掌握的大多數英語，都屬於“被動英語”——看到了能認識，但要表達同樣的意思，未必說得出來。
平時這樣似乎沒有問題，但如果要查閱資料，不會表達就造成了大的障礙。相比中文技術資料世界中“無責任/不負責轉貼”氾濫的情況，英文技術資料 的質量要高得多，Google 搜尋資料的準確性也遠高於百度；但要能夠順利應用英文資料，需要“主動”輸入資訊，描述問題，這時候“被動英語”就成了大問題。
我遇到過很多次這樣的情況：即便答案近在咫尺，輸入正確的關鍵詞，Google 的第一條結果就是答案，但程式設計師就是一籌莫展——因為他不知道計算機的“嘟嘟”聲是 beep，不知道搜“多執行緒”資料應該用 concurrency，也不知道“當機”是 system halt，“黑屏”是 blank screen……
要解決這個問題，最好的辦法是在閱讀資料時多用心，記住這些說法；另一方面，沒事的時候多瀏覽 stackoverflow 之類的網站，不要因為問題與自己無關而忽略，要多留心這些問題到底是什麼，是如何表達的。這樣，在自己遇到問題時，才能迅速找到可能的解決方案，節省時 間。
結束語
有人說，以漢語為母語的程式設計師，學習英語已經是迫不得已，不但要會閱讀，還要會表達，真是難上加難。這種說法有一定道理，但在目前並沒有更好的 解決方案的情況下，學會閱讀、認準讀音、鍛鍊表達，確實可以給自己帶來好處。長遠來看，要改變這種情況，需要中文技術圈的所有人員努力貢獻高質量的資料 （原創和翻譯都可以），如果只是“無責任轉貼”，既不親自驗證，也不整理格式，中文技術資料的整體質量只會持續惡化，反向逼迫更多的人把英語學好。
作者餘晟，曾任盛大創新院高階研究員，現任廣州某電商和物流公司技術負責人。關注技術如何解決實際的問題。業餘翻譯、審校過若干本技術書籍，並撰寫了一本講解正規表示式的書。