程式設計師的某些技術也會過時，就像冰箱裡的食物，長期不拿出來吃掉，就會過期和腐敗。所以，程式設計師這個行業，需要不斷的學習。

我現在已經從程式設計師轉成技術管理了，管理 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 的指標達到要求後，就可以考慮抽取出一個不重要的專案進行新技術棧的嘗試了。

總結

如上所說，這就是我日常學習技術的幾板斧：

• 我是先通過對要學習的技術分類，去減少學習負擔。

• 再去根據技術分類，提取出要解決的一些問題。

• 然後，根據問題去預測出想要讀的書的內容範圍。又根據這些範圍，去各種賣書、評書網站去選書。

• 選書完，採用一些讀書技巧，去快速學習。

• 學習完後，必須實踐，加深理解。如此，完成一整套新技術學習。

原創不易，看完覺得有幫助，來個三連支援。

你好，我是四猿外。

一家上市公司的技術總監，管理的技術團隊一百餘人。

我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。

我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。

歡迎關注我的公眾號，關注後可以領取高併發、演算法學習資料。