挺多童鞋問我是怎麼學習新知識的，乾脆寫篇文章總結一下，希望對大家有所幫助。對照書、技術部落格、極客時間等學習的方式我就不說了。在15年及更早，由於知識儲備少，基礎偏弱，大致採取了如下的步驟：
值得一提的是，記筆記非常重要，一是可以形成相對完整的知識體系，二來也能應對面試——面試之前花點時間看看筆記就能很快記憶喚醒。
俗話說，學以致用，為學而學是沒有意義的——即使有意義，過段時間也會遺忘。所以個人在掌握基礎知識點以及常見用法後，一般都會做個簡單的專案。作用主要有幾點：
從15年起，個人每年都會定"做乙個side project"的kpi——這個專案能承載如上三點作用即可。
順便說下，這些專案的核心基本一樣，但每次又有優化——每次拷貝老**前，都再思考一下，看有沒有改進的空間——這不正是"重構"？既是對自己過去**的重構，也是對自己技術的重新審視。
15年後，由於工作好幾年了，知識面、知識深度都達到一定程度——特別是15年初自學hadoop以及spark後。
一點趣聞於是我採取了demo驅動的方式學習。以學習 spring boot 為例，spring boot官方提供了 spring boot samples[4] ，把**clone下來玩一遍，就能相對系統得了解spring boot提供的能力。學習hadoop和spark的契機：當時大資料很火，工資很高，於是面向工資程式設計，想轉型大資料。當時正好所在公司高層變動非常頻繁，大佬們都忙著政治鬥爭——倒是爽了我這種小技術經理以及開發兄弟，整整乙個半月，沒有任何需求。於是投入全日制學習，偶爾改改bug。
後來發現，學習hadoop和spark是個笑話——因為學完發現在南京找不到大資料崗位——
面試中興，技術通過了，開17k，部長面也過了，結果卡在學歷，說民辦本二算本三，不符合他們的學歷要求，我也是醉了。
面試鴻信：對方說自己有1t資料，規模在南京排前三。我嘴上不說心裡想1t算個毛的大資料……後來又繼續搞web了。但學習還是有好處的——
大資料知識點雜，有時候還涉及不同語言……這鍛鍊了自己的知識整合能力；
hadoop、spark本身普遍是分布式應用，這為後來玩微服務打下很好的基礎；
很多時候，知識點是相通的，如果能探索到本質，會發現很多所謂高大上的東西其實也就是那麼回事。
tipsdemo驅動入門後，我一般會對照官方文件擼一遍，例如學習spring cloud時，我把官方文件中的用例都過了一遍。
官方文件帶來的好處如下：
能體會官方的意圖
感知該軟體的發展趨勢(例如閱讀release log)
系統、詳盡。
很多人可能覺得自己英文水平欠缺，不敢閱讀英文文件，這點我只能說硬著頭皮上吧，其實堅持一段時間後，你會發現也就那麼回事。大部分英文文件還是比較通俗易懂的——再者，現在谷歌翻譯質量非常高，進一步降低了閱讀英文文件的難度。
我的 kubernetes開源書[5] ，本質就是官方文件翻譯(一般看一邊翻譯) + 個人理解 + 批註。
總的來說，it行業人才分布也是符合二八定律的——80%的普通人，20%的高手；20%高手裡面，80%的普通高手，20%的大佬。我覺得英文不好不是藉口，主要還是看你想成為哪個20%——付出和回報是成一定比例的。
另外還有10000小時理論，也可以給大家共勉——要想成為某一領域的精英，必須在這一領域深耕10000小時——如果連英文文件都不敢去碰，怎麼可能成為精英？
大道理大家都懂，不再廢話了。
閒話和之前一樣，還是做個簡單的專案玩玩，專案能起到練手的目的即可。13年個人定了乙個原則，就是不找客觀藉口。因為客觀藉口只要想找，永遠可以找100個。失敗是客觀事實，但很多失敗都是由於主觀因素導致的。失敗就是失敗，首先要有勇氣直面。如果連嘗試都不敢，就失敗了，那真的是可恥到極致的失敗。
進入阿里後，我的思想再次發生變化。以前有時候我會覺得由於我沒有xx資源，所以我做不了xx事；但現在，我的思想變成因為我要做xx事，所以我需要xx資源，如果沒有，那我就去爭取；如果沒有那我就想辦法搶。我離成功還很遠，但我會繼續努力。技術上成功的難度，對我來說相對低一些，所以我堅持技術路線。
起源於在焦點科技的一場面試——焦點科技面試官是對我職業生涯中造成影響的面試官，雖然只有一面之緣，甚至連對方的名字也不知道。
與其說是面試，倒不如說是"切磋"——一般面試，往往是你問我答，ok，next。回答對不對，到不到位，往往不會揭曉答案。
這位面試官很有意思，他會從乙個簡單的問題逐步深入，並且如果回答不上來，對方會給你很多提示，就像武俠片裡**給徒弟喂招一樣——這樣面試下來會有所收穫，也會了解自己欠缺的地方；更好玩的是，如果你聊到對方不了解的地方，也會問到他懂為止——這其實是考察候選人的溝通能力的常見手法之一，但目前業界又有多少面試官能做到呢？
這次面試給我的啟發是：如果廣度已經很好，是不是應該深挖呢？
深入，最好的方式就是閱讀**。而為了看**而看**，在我看來是浪費生命、浪費時間。所以，我選擇在遇到問題時，帶著問題分析原始碼——這裡的遇到問題，並不是**執行報錯，或者是專案出異常；而是指對***感到好奇，想要了解原理，於是帶著問題閱讀**。
個人比較喜歡看科技新聞，大學開始，常年在煎蛋、cnbeta、36氪等科技站上潛水。然而，從15年開始，就一直在995/996，跳到哪兒哪兒加班……時間不夠用，必須做出取捨。
經過分析，發現開源動態對自己更有價值。於是堅持每天花10-15分鐘刷開源中國的"軟體更新諮詢"欄目——軟體更新欄目相信很多人有所了解，其實就是某某開源軟體又發布了新版本的新聞列表。
然而，長期關注至少能獲得如下幾點資訊：
長期關注的收益：
我在15年玩spring cloud、16年玩docker、17年玩kubernetes，時間基本都在業界流行之前。之所以有這種行業敏感性，和長期刷開源中國是分不開的。
tips16年，因為一些契機，從開發轉型成為架構師。角色的轉變，帶來的是思考視角的轉變。之前做技術經理時，名下只有四五個人，多數問題口頭交流就ok了；但成為架構師後，負責的麵變大了，有時得和幾十個人溝通，而很多溝通是重複的。再安利就變成開源中國軟文了……相信我，開源中國沒有給我錢……
此時，我意識到，不如把大家常見問題總結總結，寫成手把手的文件——
再後來，發現寫spring cloud開源書、部落格、實體書……
寫作本身也是總結的過程，而且不僅要自己懂，還要想辦法讓別人也能看懂。
可能是寫手把手系列多了，所以我的文章一直也是手把手、附具體步驟、配詳細**，原理、原始碼分析寫得相對少一些，這點也被一些人詬病。個人對部落格的定位，主要是引導新手，其次是個人心得總結。如果人家已經入門了，還需要到處找文章嗎？自己研究研究就ok了。
那些喜歡看原始碼解讀的"高手"，有多少是真高手，有多少是偽高手？我相信有原始碼閱讀經驗的，都不會覺得閱讀原始碼是一件高大上的事情——多數情況下，看懂開源軟體原始碼真的比看懂你所在專案的遺留**簡單多了！
趣聞以上是我歷年學習方法的分享。其實總結起來就一句話：我不夠聰明，但我會死磕，逐步積累；我不找客觀原因，硬上。18年在華為面試 ，和面試官聊到zuul相關原始碼。大致問題是：聊聊zuul errorfilter存在的bug。這個bug其實在camden已經修復了，但是我好說歹說面試官都不信。結果再一打聽，原來面試官看到《spring cloud微服務實戰》是這麼寫的——這本著作是基於spring cloud brixton撰寫的，該版本確實有bug，所以作者非常貼心地給出了解決方案，卻被這位面試官拿來做考察乙個人對spring cloud是否深入的尺子。
學習新知識的方法
先了解知識的背景，然後了解該知識要解決的問題，最後了解知識的目的。知識的背景 這個知識產生的原因，是在什麼情況下產生的，這個知識產生之後，問題解決了多少，解決到什麼程度。舉例 泰勒公式的目的就是為了用多項式更好地擬合複雜函式，使得複雜函式可以做更多的事情。學到的知識要去實踐，才能對其精髓體會更深。先...
學習新知識的過程
做程式設計都好幾年了，每次剛開始學習新知識的時候都是乙個比較痛苦的過程，然後等學會了以後就又是充滿喜悅和成就感！哈哈 突然感覺這樣的過程很奇妙，這就是實實在在的生活，它能夠讓我們每天都特別充實。其實總結一下每次學習新知識的過程都有規律可循的。首先將要學習的內容確定了，然後給自己定乙個目標，什麼時間可...
學習新知識的正確方式
首先我們學習知識的時候，第一步就是要明白這個知識的目的是啥？帶著目的去學習才不會被文字元號或者是複雜的邏輯給蒙蔽了雙眼。才能不至於淹沒到知識的海洋中，不至於從入門到放棄。時刻都要想著目標，沒有目標的學習就是浪費生命。接下來我們討論一下學習中遇到的常見的具體問題。我們學習知識會經常遇到自己不清楚，或者...