在開源社群上看到一個提問了，技術大佬們都是怎麼學習的?發現一樓有位答主回答的特別好，特此分享給各位處於迷茫期的小夥伴。

01熟悉更多業務

不管是不是你負責的;熟悉更多程式碼，不管是不是你寫的。

這樣做有很多好處，舉幾個簡單的例子：

需求分析的時候更加準確，能夠在需求階段就識別風險、影響、難點。問題處理的時候更加快速，因為相關的業務和程式碼都熟悉，能夠快速的判斷問題可能的原因並進行排查處理。方案設計的時候考慮更加周全，由於有對全域性業務的理解，能夠設計出更好的方案。

02熟悉端到端

比如說你負責 Web 後臺開發，但實際上使用者發起一個 HTTP 請求，要經過很多中間步驟才到你的伺服器(例如瀏覽器快取、DNS、Nginx 等)。

伺服器一般又會經過很多處理才到你寫的那部分程式碼(路由、許可權等)這整個流程中的很多系統或者步驟，絕大部分人是不可能去參與寫程式碼的。

但掌握了這些知識對你的綜合水平有很大作用，例如方案設計、線上故障處理這些更加有含金量的技術工作都需要綜合技術水平。

“系統性”、“全域性性”、“綜合性”這些字眼看起來比較虛，但其實都是技術大牛的必備的素質，要達到這樣的境界，必須去熟悉更多系統、業務、程式碼。

03自學

一般在比較成熟的團隊，由於框架或者元件已經進行了大量的封裝，寫業務程式碼所用到的技術確實也比較少。

但我們要明白“唯一不變的只有變化”，框架有可能要改進，元件可能要替換，或者你換了一家公司，新公司既沒有元件也沒有框架，要你從頭開始來做。

這些都是機會，也是挑戰，而機會和挑戰只會分配給有準備的人，所以這種情況下我們更加需要自學更多東西，因為真正等到要用的時候再來學已經沒有時間了。

以 Java 為例，大部分業務程式碼就是 if-else 加個資料庫操作，但我們完全可以自己學些更多 Java 的知識，例如垃圾回收，調優，網路程式設計等。

這些可能暫時沒用，但真要用的時候，不是 Google 一下就可以了，這個時候誰已經掌握了相關知識和技能，機會就是誰的。

以垃圾回收為例，我自己平時就抽時間學習了這些知識，學了 1 年都沒用上，但後來用上了幾次，每次都解決了卡死的大問題。

而有的同學，寫了幾年的 Java 程式碼，對於 stop-the-world 是什麼概念都不知道，更不用說去優化了。

你負責的系統和業務，總有不合理和可以改進的地方，這些“不合理”和“可改進”的地方，都是更高級別的怪物，打完後能夠增加更多的經驗值。

識別出這些地方，並且給出解決方案，然後向主管提出，一次不行兩次，多提幾次，只要有一次落地了，這就是你的機會。

例如：

重複程式碼太多，是否可以引入設計模式?系統性能一般，可否進行最佳化?目前是單機，如果做成雙機是否更好?版本開發質量不高，是否引入高效的單元測試和整合測試方案?目前的系統太龐大，是否可以透過重構和解耦改為3個系統?阿里中介軟體有一些系統感覺我們也可以用，是否可以引入?

只要你去想，其實總能發現可以改進的地方的;如果你覺得系統哪裡都沒有改進的地方，那就說明你的水平還不夠，可以多學習相關技術，多看看業界其它優秀公司怎麼做。

我 2013 年調配到九遊，剛開始接手了一個簡單的後臺系統，每天就是配合前臺做資料增刪改查，看起來完全沒意思，是吧?

如果只做這些確實沒意思，但我們接手後做了很多事情：

解耦，將一個後臺拆分為 2 個後臺，提升可擴充套件性和穩定性。雙機，將單機改為雙機系統，提高可靠性。最佳化，將原來一個耗時 5 小時的介面最佳化為耗時 5 分鐘。

還有其他很多最佳化，後來我們這個組承擔了更多的系統，後來這個小組 5 個人，負責了 6 個系統。

04Do exercise

在做職業等級溝通的時候，發現有很多同學確實也在嘗試 Do more、Do better，但在執行的過程中，幾乎每個人都遇到同一個問題：光看不用效果很差，怎麼辦?

例如：

學習了 JVM 的垃圾回收，但是線上比較少出現 FGC 導致的卡頓問題，就算出現了，恢復業務也是第一位的，不太可能線上出現問題然後讓每個同學都去練一下手，那怎麼去實踐這些jvm的知識和技能呢?Netty 我也看了，也瞭解了 Reactor 的原理，但是我不可能參與 Netty 開發，怎麼去讓自己真正掌握 Reactor 非同步模式呢?看了《高效能 MySQL》，但是線上的資料庫都是 DBA 管理的，測試環境的資料庫感覺又是隨便配置的，我怎麼去驗證這些技術呢?框架封裝了 DAL 層，資料庫的訪問我們都不需要操心，我們怎麼去了解分庫分表實現?

諸如此類問題還有很多，我這裡分享一下個人的經驗，其實就是 3 個詞：learning、trying、teaching!

05Learning

這個是第一階段，看書、Google、看影片、看別人的部落格都可以，但要注意一點是“系統化”，特別是一些基礎性的東西，例如 JVM 原理、Java 程式設計、網路程式設計，HTTP 協議等等。

這些基礎技術不能只通過 Google 或者部落格學習，我的做法一般是先完整的看完一本書全面的瞭解，然後再透過 Google、影片、部落格去有針對性的查詢一些有疑問的地方，或者一些技巧。

06Trying

這個步驟就是解答前面提到的很多同學的疑惑的關鍵點，形象來說就是“自己動手豐衣足食”，也就是自己去嘗試搭建一些模擬環境，自己寫一些測試程式。

例如：

JVM 垃圾回收：可以自己寫一個簡單的測試程式，分配記憶體不釋放，然後調整各種 JVM 啟動引數，再執行的過程中使用 jstack、jstat 等命令檢視 JVM 的堆記憶體分佈和垃圾回收情況。這樣的程式寫起來很簡單，簡單一點的就幾行，複雜一點的也就幾十行。Reactor 原理：自己真正去嘗試寫一個 Reactor 模式的 Demo，不要以為這個很難，最簡單的 Reactor 模式程式碼量(包括註釋)不超過 200 行(可以參考 Doug Lee 的 PPT)。自己寫完後，再去看看 Netty 怎麼做，一對比理解就更加深刻了。MySQL：既然有線上的配置可以參考，那可以直接讓 DBA 將線上配置發給我們(注意去掉敏感資訊)，直接學習;然後自己搭建一個 MySQL 環境，用線上的配置啟動;要知道很多同學用了很多年 MySQL，但是連個簡單的 MySQL 環境都搭不起來。框架封裝了 DAL 層：可以自己用 JDBC 嘗試去寫一個分庫分表的簡單實現，然後與框架的實現進行對比，看看差異在哪裡。用瀏覽器的工具檢視 HTTP 快取實現，看看不同種類的網站，不同型別的資源，具體是如何控制快取的;也可以自己用 Python 寫一個簡單的 HTTP 伺服器，模擬返回各種 HTTP Headers 來觀察瀏覽器的反應。

還有很多方法，這裡就不一一列舉，簡單來說，就是要將學到的東西真正試試，才能理解更加深刻。

印第安人有一句諺語：I hear and I forget. I see and I remember. I do and I understand ，而且“試試”其實可以比較簡單，很多時候我們都可以自己動手做。

當然，如果能夠在實際工作中使用，效果會更好，畢竟實際的線上環境和業務複雜度不是我們寫個模擬程式就能夠模擬的，但這樣的機會可遇不可求，大部分情況我們還真的只能靠自己模擬，然後等到真正業務要用的時候，能夠信手拈來。

07Teaching

一般來說，經過 Learning 和 Trying，能掌握 70% 左右，但要真正掌握，我覺得一定要做到能夠跟別人講清楚。

因為在講的時候，我們既需要將一個知識點系統化，也需要考慮各種細節，這會促使我們進一步思考和學習。

同時，講出來後看或者聽的人可以有不同的理解，或者有新的補充，這相當於繼續完善了整個知識技能體系。

這樣的例子很多，包括我自己寫部落格的時候經常遇到，本來我覺得自己已經掌握很全面了，但一寫就發現很多點沒考慮到。

出處：oschina.net/question/3774191_2320056