程序員如何自我學習？阿里資深技術專家這樣做
阿里妹注：作者長居在美國，故學習渠道有些許不同。我們可以舉一反三，領會即可～
為何要持續學習，靠經驗積累不行嗎？
很多人都說程序員的薪資水平不錯，可以媲美醫生和律師。而程序員和醫生、律師的不同點在于持續學習上。不是說醫生和律師不需要學習，醫生、律師能夠憑之前的case積累非常多的經驗（這也是大家看病喜歡找年紀大的醫生的原因之一），而且這些經驗很大程度上可以被復用（很多病因和判罰案例帶有相似性）。
程序員這個職業則不同，主要是因為行業更新得太快，積累的經驗很快就不適用了。
舉幾個例子：
如果你是Java程序員，且非常擅長Struts + JSP開發，解決了很多Struts框架的問題。但今天，這部分知識已經過時，需要重新學習。如果仍堅持使用之前的技術，會給同事和公司帶來很大的技術負擔。大家回顧一下自己從畢業到現在有多少技術都已經看不到蹤影了。就阿里巴巴內部來說，很多技術也都已經被淘汰不用了。
就編程來說，有很多編程語言和門第之爭。你在這個語言積累的經驗到另外一個語言就未必行得通。我很少聽說Java組招一個.Net的資深工程師，即便有，那也是給產品做.Net SDK client的。
軟件的經驗積累還會體現在一個架構設計上。很多同學會說經驗積累得多，架構就設計得好，這在今天來說也未必。大家都在云上啦，云上提供的服務基本都是類似的，架構思路和使用的云上服務基本一致。
Amazon的售前人員個個都是行業架構師，給你很好的架構和解決方案，包括遷移方案，所以你就知道架構的門檻了。非資深程序員可以花半天時間看一下 Learn how to design large-scale systems （ https://github.com/donnemartin/system-design-primer ），雖然說是primer，但是還是非常實用的，配合一下 Awesome list ( https://github.com/topics/awesome ) 架構思路和模式都有了。框架和開發包的具體特性和對比了解了，一天就能夠成為架構師。
有個笑話：一個產品經理找一個有個性的設計師去設計原型和交互稿。該設計師頭都沒有抬說道：“你抄的是哪個網站或App? 告訴我，我下午給你做。”如果你看了system design primer，當有架構師找你，你就可以說你參考的是哪個網站的架構。我們回頭理解一下然后按照這個設計編寫代碼就可以了。在云上，架構設計基本都是pattern的，再花很多時間討論架構設計，就有點想不通了。但對云上的產品做徹底的理解，這個還是需要的。 行業發展得太快，你必須學習，純靠經驗積累行不通，技術淘汰的速度遠大于你經驗積累的速度。
非雞湯：不要和程序員談自己的編程歷史，很多的經驗在今天已經不適用了。只要2-3年不關注技術，就基本快和程序員和編程絕緣啦，不是絕對，但是通常不會錯。
工具要非常熟練
有人跟我說：“不要吹啦，你就是IDEA使用得再熟練，也沒有必要將學習和使用工具掛上鉤吧。” 說句實在話，看到一些硅谷工程師的培訓教程中他們對工具的熟練使用程度，我只能說我還是小白。
有一次和幾個google的工程師吃飯聊天，問了一下他們遇到的哪些人比較牛？ 一個工程師說他的leader太牛了，在幫助他找bug的時候，工具和debug使用的熟練程度讓人眼花繚亂。很多工具都是他聽都沒有聽過的，而且Python腳本編寫幾乎如行云流水般。究其原因并非是這個leader一眼就能看出問題所在，有些問題他也是第一次遇到，但他在單位時間內嘗試的次數特別多，就很快把問題給逼出來了。
非雞湯：在排查問題和寫代碼上，如果你1個小時只能嘗試一種方法，別人卻能夠嘗試10次，那么別人就是比你牛。天下武功唯快不破，你后續寫demo、查問題、工具的熟練程度都會決定你學習和嘗試新事物的速度。
讀書 & 看文檔
學習還需要系統化。并非單靠看一篇文章就能明白原理。
個人強烈推薦：
https://www.safaribooksonline.com/
Safari應該是出版社聯盟，IT類圖書基本都能找到。兩個小問題是：需要收費，一年大概400刀；圖書都是英文的。 Safari Books Online的圖書非常全，幾乎涵蓋絕大多數出版社，我們熟知oreilly, apress, manning, packtpub，addison wiley，而且更新速度非常快。另外Sarafi提供的Learn path也非常有用，能幫助你系統地了解一些技術，如blockchain，ai，machine learnging等等。現在視頻資料也非常多，包括專家知識培訓和一些技術大會的視頻。
除了圖書，我們還需要關注文檔(reference)。現在很多框架和技術的參考文檔已經非常好了。首先是文檔的質量越來越高，現在技術都是協作的。Java程序員可以看看Spring Framework，Hibernate，Kotlin，Groovy的文檔，質量都非常高。
如果你還停留在文檔就是幾頁介紹和demo，那你的觀點可能要改一下了。你看CNCF上的項目，幾乎每個項目的文檔質量都是非常高的。現在很多項目不是一兩個程序員單打獨斗，而是一個團隊加上像github那種協作非常好的平臺，所以文檔和代碼、新特性不匹配已經非常少了，很多issue都是關于文檔的。
另外一些新的技術，剛開始只有文檔，在圖書還沒有來得及出版的情況下，你只能閱讀文檔。個人在做Service Mesh的時候，對應的圖書比較少，只能閱讀Envoy + Istio的官方文檔，但這沒有關系，會稍微難閱讀點，但多讀兩遍就可以啦，畢竟我們不是天才，也不是這個領域的專家。
非雞湯： 如果money允許的話，Safari Books Online的服務還是值得個人或者團隊訂閱的。另外時不時重新閱讀一下官方文檔，畢竟官方文檔還是最權威的，也是最新的。
視頻學習
之前個人是看書比較多，視頻學習方面最多是在youtube上看一下大會的視頻。 近一年比較關注視頻教學。
視頻和圖書有什么區別？
首先圖書編寫比較費時（packtpub的快餐書除外），圖書作者要有一定的寫作水平，這點對技術牛但寫作不在行的人或者沒有充裕時間的人就比較麻煩了。Java程序員可能比較了解Josh Long這個人，他的《Cloud Native Java》花了一年多的時間才出版，而期間他已經發了非常多的視頻。
視頻還有一些文字表達不了的功能：圖書中只會貼一段代碼，而視頻中這些代碼是需要輸入的，這時你會發現作者很多的黑科技或者黑技巧，你也能學習到。如React入門書籍中，一般只會說明或者引用Redux，而教學視頻中，會打開對應的網站，給你列舉一些重點特性。另外圖書中一些比較容易忽略的東西，在視頻中可能會被很好地補充。而且很多的視頻制作者，本身是來自框架和技術的開發團隊，而不是第三方的圖書作者，所以新鮮度和技巧性都非常明顯。
不少人對大段文字，尤其是理論和學術很強的圖書比較過敏。比如很多人問如何學習domain driven design，但是能將DDD圖書看完2-3章不犯困的就很難得。主要是因為文字太多，沒有什么代碼，又不像小說有情節，不犯困反而很難的。反之，DDD培訓視頻就不一樣，PPT制作得非常好，而且有動畫，相關的說明貼切，更容易學習。
這里列舉一下比較有名氣的視頻培訓網站，有Pluralsight, Lynda 和 Udemy等。
Udemy的視頻是需要單個購買的，一個3-4個小時的視頻需要10刀。如果你的閱讀量比較大，花費會比較多，而且Udemy不是只關注IT，專業度方面會不夠。 Lynda和Pluralsign都是會員制的，你交會費后，可以看所有的視頻教學。 Lynda內容非常多，很多人反映內容過時，我個人沒有訂閱過，搜索一下確實有這個感覺。
個人推薦Pluralsight，這個也是我訂閱的服務。內容非常多也比較新，而且有一些是系列的，對跨界學習幫助特別大。 如在做Service Mesh的時候，可能涉及到SDN，讓我在Safari上閱讀一本SDN的圖書，我只能說臣妾做不到，尤其跨界學習的同學，難讀啊。但是Pluralsight上一個2個小時的視頻教學，我馬上就看懂啦。 Java程序員要學ES 6 + React開發，如果找JavaScript圖書先看，然后再React圖書，周期太長，而Pluralsight上一個ES 6 + React Learning Path視頻教學，馬上讓你快速入門、投入開發。回頭把圖書和文檔補充一下，知識也一起鞏固了。
非雞湯： 還是money問題。條件允許的話，購買一個pluralsight會員，每月29刀，絕對非常值得。Pluralsight的視頻基本都有英文字幕，配合作者的ppt，英語不好的同學學習也沒有問題。下班沒事的時候，找個會議室，幾個志同道合的同學，搞點飲料，播放一個跨界或者新技術的視頻，看完20分鐘，大家討論一下。英文好的、有技術功底的同學多發表一些觀點，其他的同學都也都能了解。
技術新聞，twitter上技術大牛 & 參加技術大會
前面介紹的圖書、文檔和視頻教學，讓我們可以了解和深入某一項技術，對付工作應該沒有問題。但如果要緊跟潮流，獲取靈感，可能還需要關注一些技術新聞，follow twitter上的技術大牛。
每個人都有惰性，大牛也不例外。有時候他們可能不會寫文章、文檔或者拍視頻，只會隨意說一下。比如，我第一次了解Spring Fu這個技術時，是在Twitter上。項目還沒有啟動，Kotlin + Spring的核心團隊就開始不經意流露一些消息，你可能由此獲得不錯的想法，而且大牛會轉發技術新聞，這些新聞都經過他們過濾的，你挑選的成本也就低很多啦。
技術新聞沒有很好的地方平臺統一管理，相對凌亂一些，你需要有自己的方法，不然找尋成本比較高。 很多人喜歡 Hacker News （ https://news.ycombinator.com/ ），但是沒有歸類，這個有點麻煩。 https://thenewstack.io/ 的歸類好很多。 Google Reader關閉后，個人轉投Feedly，還是有訂閱blog的習慣。
Medium （ https://medium.com/ ）非常不錯， a place to read and write big ideas and important stories，這里推薦一下，很多技術牛人在Medium上，不少技術公司的blog也都在medium上有文章。據說還有付費的會員，個人沒有嘗試過，強烈推薦。 reddit可以歸類一些topic，關注一下。 如果你持續關注某一技術，最好加入該技術的Slack或者gitter討論群，大家都會在群里將相關的好新聞、技術文章進行分享，我在的Kotlin Slack中就了解非常多新的框架和關聯技術，大家畢竟還是樂意分享的。
如果時間和金錢都允許的話，個人建議可以參加技術大會，畢竟現場氛圍是不一樣的。2-3天內，不用工作，不想其他事情，圍繞這個話題，而且keynote，和眾多同行在一起，這種感覺是不同的。你需要堅信你找對了一個方向，讓你更有動力深入了解下去。技術大會有很多的展臺，將這個行業非常優秀的企業和技術聚集起來，也是非常不容易的。
非雞湯： Twitter上技術大牛follow一下，關注對應的技術新聞和blog，平時逛逛slack和gitter，還是有一定的收獲的。技術大會一般是美國較多，這對英文和獨立出行有些挑戰。大家可以結伴或找當地的同學接待，成本會低不少。但是目前技術大會的門票都非常高，基本上都是1500-2000刀，早點訂可能在1000刀左右。雖然時間成本稍微高一些，但95%到99%的提升就是要花更多時間、精力和金錢。
做項目，寫Demo，看源碼
前面說了學習，但是程序猿不寫Demo是不行的。項目中可以考慮嘗試新的技術。我們現在推行微服務，所以技術棧還是有自由度的，就看你能否hold住啦。不一定所有的技術都能用到項目中，有些是啟發性的或者觸類旁通的，你需要寫Demo，磨磨刀沒有錯的。文章前面說過，工具要非常熟練，不然一個demo花掉一個小時不值得。讀了很多，看了很多，如果再用代碼輔助一下，就更好啦。我不是說這些知識都是為了代碼，不少是為了架構的。比如，學習ES 6 + React，如果沒有代碼，很難想象要如何掌握這個知識。
看源碼是非常重要的一個技能。至少你code review技能提升，但成本確實高。個人是對Kubernetes還算比較了解，但是讓我看Kubernetes源碼，壓力很大，尤其是不擅長的領域。看Spring Fu的源碼沒有問題，但是要看Istio和Envoy源碼，壓力太大。但是你如果決定投入，看源碼幫助還是很大的。
非雞湯： 項目中多嘗試一下你學到的新知識，不能慣性使用你熟悉的技術，要知道你熟悉的東西很快會被淘汰，被淘汰后再調整就來不及了。多寫一些demo，多磨磨刀。對你本行業的技術，一些源碼還是要能看懂的。跨界技術，閱讀源碼量力而為，讓Java程序去看JS框架源碼或者C++源碼，是需要心理準備的。
如今閱讀的人少了
看到youtube上一個技術人員講述閱讀的觀點，還是比較獨特的。 其實現代人閱讀量是比以前多，每天打開手機，各種新聞、文章、視頻和朋友圈，閱讀量相較以前變大了。對比圖書等，這些知識只是生命周期太短，而且營養不高，這也是為何大家覺得閱讀少的原因，沒有幫助你增長知識。
如果你不是產品經理或者需要對行業進行分析，就技術人員來說，新聞類app對你來說可能用處不大。 這些新聞都是幫助你找找聊天話題，做為飯后談資，沒有什么大用，反而浪費你不少時間，你可能半個小時都在刷新聞，而且現在新聞都有智能算法，保證能黏住你。大家都在搶用戶時間，他們可不會在乎你的知識進步，就是讓你停留時間長點，多看一些廣告。
非雞湯：音樂是不錯的，好像有針對程序員編碼的音樂，個人不是發燒友，但是還是推薦一下。
適當的硬件支持
進辦公室看一下同事的電腦，你就大概能區分一些職業。用13寸的MacBook Pro或者Air，絕對不是Java程序員。如果是Golang或者C++程序員，一定不會用JetBrains的IDE工具，基本都是Editor類等。對硬件建議僅僅適合Java類的程序員，硬件好點是讓你速度更快。蘋果最新的MacBook Pro 2018確實非常不錯，終于有32G內存，大家可以考慮入手。
總結
如果沒有圖片、視頻，只是純粹的文字，讀起來會比較枯燥。大家在學習的過程中可能有不少自己的心得，如好用的知識整理方法、做筆記的方法、時間管理法等。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
