我之前寫過幾篇關於微服務的文章，讀者們看完反饋不錯。
同時，也有讀者說：
看完文章是懂了，但是自己學的時候，還是有點懵，不知道怎麼下手
授人以魚不如授人以漁。
魚能解決一時之飢，卻不能解決長久之飢。讀者們需要知識，同時更需要學習知識的方法。
所以，這篇文章就說說漁，正文開始。
程式設計師的某些技術也會過時，就像冰箱裡的食物，長期不拿出來吃掉，就會過期和腐敗。所以，程式設計師這個行業，需要不斷的學習。
我現在已經從程式設計師轉成技術管理了，管理 100 多人團隊每天一堆事……還是寫程式碼、研究技術的日子比較純粹，沒有那麼多浪費時間的無聊會議，沒有那麼多技術無關的事。
雖然如此，但是技術也不能丟。每當出現非常流行的新技術，或者團隊技術棧準備升級，我都必須去學習這些新技術，爭取在短時間內，能把控住技術棧升級帶來的風險。
正是在這種形勢下，我也從中琢磨出了一些快速學習的套路和技巧。我分享出來，希望拋磚引玉，能對後來者有一些幫助和啟發。
第一步：技術棧需要先分類
當想要學習任何新技術的時候，我經常做的第一件事就是
對要學習的技術領域去做一個分類
比如，幾年前，公司的系統要改造成微服務架構，那我就必須去學習微服務的這套技術棧。但是，一學我才發現，微服務的技術棧怎麼這麼多……
這時候，就要對微服務的技術棧進行分類。目的也很簡單，就是為了對學習作出一個規劃，根據技術棧的分類，作出一個有著明顯輕重緩急的學習計劃。
就微服務而言，我將其劃分為如下幾類：
- 微服務的設計
- 微服務的原理
- 微服務的架構
- 微服務的開發框架和程式碼規範
- 微服務的安全
- 微服務的運維
分完類之後，再結合當時的情況，我的計劃是這樣的。
1.
首先，由於我是從零開始，需要設計到落地一條龍。所以，我決定優先摸熟微服務的設計。
這裡我會找書看，通過看書弄清楚概念和知道怎麼劃分業務。為什麼是看書不是看網上文章，原因後面會說。
2.
然後，再根據落地的需要，去學習微服務的架構最佳實踐以及微服務的開發框架和程式碼規範。學好這些內容，等以後把微服務落地的時候都用得上。
學的時候，先不需要去深入語法細節，我只需要明白框架的核心思想和程式碼規範，把控技術落地不會脫離大方向。技術的細節可以等後面真正寫程式碼的時候，再和同事們一起去鑽研，
3.
在微服務落地後，就需要微服務的運維了。而微服務的運維，其實可以淺嘗輒止的學習，重點是要知道微服務的運維元件和運維常規工作流程。
公司有專門運維團隊的，剩下的工作交給運維同事就好了。
4.
在微服務運維後，我感覺只靠學習市面上的微服務套路肯定還不太夠，如果要讓微服務能更好的適合我們自己的業務，還需要根據底層微服務的原理，去搞透微服務最佳實踐為何這樣做的原因。
很顯然，這塊的學習難度非常大，需要不少知識儲備。
但是，再難學也值得學，因為極有可能我們需要結合自己公司的業務，對微服務作出個性化的定製。
建議：找幾個兄弟一起組隊學習原理這塊。
5.
微服務的安全，主要是閘道器的安全措施，大部分公司都有安全團隊，這部分交給他們負責就好了。
所以，再經過分門別類之後，我們就很清晰了。
微服務的學習順序就是：
微服務設計 > 微服務架構 > 微服務開發框架和程式碼規範 > 微服務原理 > 微服務運維 > 微服務安全
學習內容的詳盡程度則是：
- 微服務設計、微服務原理需要多讀幾本書，尤其是原理，要深入學習 + 和牛人廣泛討論；
- 其他部分的學習，優先順序沒那麼高。
第二步：選擇合適的書
當我們根據技術棧分類定出學習計劃後，接下來就要選擇合適的書籍學習了。
這裡需要強調一下，以我的經驗，對一門全新的技術學習，不建議完全通過看網上的文章。
因為網上的文章有好也有壞，壞的是真坑人，而且作為初學者，你沒有什麼經驗，不知道文章是否有錯誤。
我舉個例子，網上的鏈路跟蹤，尤其講 SkyWalking 的相關文章，很多都是錯的，如果對鏈路跟蹤不熟悉，就很難分辨出錯誤，到時候不慎把錯誤的觀念用到了系統裡，再改正就非常費勁了。
所以，入門階段還是老老實實的找一些權威書籍看吧。
但是，權威書籍也有問題，因為書的受眾不一樣，如果一些書讀的不合適，比如，選的書籍講的都是過時的技術，又或者有的書籍講的非常晦澀，理解起來非常費勁，那這些書就不合適我們去讀，讀了要麼浪費時間，要麼錯用過時的技術。
怎麼選擇合適的書？
比如，我想學微服務設計，我發現微服務設計和領域驅動設計又是緊密關聯的。領域驅動設計又有很多的書，有講理論的，有講實戰的，甚至還有混雜著其他技術棧的。
我當時需要的是理論 + 實戰的書，並且最好有在已有專案移植到微服務的相關案例的書。
接下來就是去網上看書評了。一般來說，現在豆瓣、噹噹、京東的書評和書籍簡介都比較不錯了。
不過，我更偏好英文書一些，所以，當時根據亞馬遜的評價找到了一本《Implementing Domain-Driven Design》，這本書後來翻譯成中文了，叫《實現領域驅動設計》—— 我粗看過，我認為翻譯的不好。
事後證明，這本書確實解決了我的問題，讓我摸清楚了域、子域、邊界上下文之類的關鍵概念。
第三步：讀書需要技巧
選完了書，就要去讀書。但是，任何一本 IT 書籍，可都是不薄的。
像我前面舉例的《Implementing Domain-Driven Design》，這本書就是六百多頁的厚度。如果一天讀 20 頁，需要 30 多天，這個時間就太慢了。所以，就需要技巧：
先速讀後精讀
一般來說，對於六百多頁的書，尤其是講解的概念穿插實戰的，應該開始的時候，快速閱讀。我大概一天是 100 - 200 頁左右，時間控制在 4 個小時，連續不斷的閱讀。
這種閱讀，看上去很難，其實是建立在快速的跳讀和略讀上的。讀取的時候，只找關鍵詞，尤其是名詞。
找到關鍵詞後，一般就要提取知識點。三五個關鍵詞，就能提取出一個關鍵知識點來。遇到不會的，也可以當做關鍵詞提取出來。
關鍵詞往往和小章節的標題能對應上，根據關鍵詞，找到章節中的解釋，看明白了，就能跳過別的章節內容。
速讀，弄懂即可，不需要把所有的內容都讀完。
這樣，一本六百多頁的書，大概一週就讀完了。
讀完後，彆著急，然後就需要根據你提取的關鍵詞和知識點去做精讀了。
這時候，由於書籍的關鍵點已經提取出來了，你只需要精心學習提取的知識即可。
一般而言，知識點提取後，需要精讀的內容往往只有原來整體內容的幾分之一。
我精讀這本書大概花了一週左右。
在精讀期間，如果有一些發現理解不足的，還需要去查一些別的資料來補充理解，或者動手實踐，或者和別人一起交流，除了講解自己的看法和理解，也需要能汲取別人的看法和理解。
精讀的最佳結果是，你能用自己的話把原來的概念和別人講清楚。
這樣，總的算下來，讀這本六百多頁的書需要花十天、半個月的時間。
說起來，其實大家可以問問身邊認識大廠的高手，你會發現，他們大多數人讀書，都是我這樣類似的讀法，確實非常有用。
第四步：落地實踐
書讀完了，肯定有很多不足的地方。這時候，就需要通過技術實踐去加深理解、彌補不足。
實踐分為兩種：
1. 書中的實驗
大部分技術書籍，大部分都有些對應的課後習題或者實驗。
因為這些實驗都是附屬在某些具體講解、某些概念的章節後，針對性非常強。所以，如果能不看書，根據自己的理解，去順利把實踐做出來，那就證明，確實學習到位了，可以把學到的東西用到實戰中了。
2. 實際中的場景
當書中的實驗都做完了，就可以考慮真實的專案場景了。
可以先根據工作需求，打造出一個包含了所學新技術全棧的 Demo 出來。
比如，微服務，就可以搭建一套，有閘道器、有配置中心、有鏈路跟蹤的 Demo。
Demo 搭建之後，還可以採取一些測試用例對這個 Demo 進行測試，不管是業務測試還是效能壓測，都要進行。
當 Demo 的指標達到要求後，就可以考慮抽取出一個不重要的專案進行新技術棧的嘗試了。
總結
如上所說，這就是我日常學習技術的幾板斧：
-
我是先通過對要學習的技術分類，去減少學習負擔。
-
再去根據技術分類，提取出要解決的一些問題。
-
然後，根據問題去預測出想要讀的書的內容範圍。又根據這些範圍，去各種賣書、評書網站去選書。
-
選書完，採用一些讀書技巧，去快速學習。
-
學習完後，必須實踐，加深理解。如此，完成一整套新技術學習。
原創不易，看完覺得有幫助，來個三連支援。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號，關注後可以領取高併發、演算法學習資料。
