[置頂] 《技術大牛養成指南》

轉自：  https://mp.weixin.qq.com/s/92Cr_kE1djVDvB24N_kCvA

《技術大牛養成指南》

2017-03-02  李運華  StuQ

做者｜李運華
編輯｜Alice Qin

有的人想成爲大牛，卻未曾爲此努力。有的人辛苦耕耘，卻收穫寥寥。不少時候，你跟成功的差距並非能力，也不是運氣，或許只是正確的方法？這是一篇不雞湯的成功學指南，若是你相信且願意堅持嘗試，未必幫不到你！一碗有勺子的雞湯

我工做已經將近12年了（其實12年才混到這個地步，天資實在是通常），在華爲作了5年，在UC作了6年，如今主要負責阿里遊戲的中間件和組件的架構設計和實現，包括用戶消息推送、系統異步通知系統等等。

同時我還帶了三四十人的研發團隊，除了工做之外，我也喜歡寫博客，是CSDN、雲棲的社區之星和博客專家，InfoQ的簽約做者。

整體上來講，我如今雖然還算不上業界頂級的大牛，但在公司也算一頭小牛了，今天個人分享將綜合本身的成長經歷給你們談一談怎麼樣成爲一個大牛。我如今還在業界的大牛路上狂奔，但我以爲這些經驗和技巧應該是每一個同窗均可以用到本身的平常工做和生活當中的。

一舉成名背後是1萬小時的不斷練習

如何成爲大牛？這個問題以前有不少人問我：你是怎麼成爲技術上的一個大牛的？最開始的時候我也常常跟他們講你要去看看某某某開發方案，深刻學習UNIX的開發等等這些「術」的東西，後來我在思考，是否有成爲一種大牛的「道」上面的東西，也就是說無論你作產品、作運營、作運維、程序員仍是測試，經過這個方式都可以成爲一個大牛呢？

經過尋找和思考，後來真的讓我找到了應用到全部行業、全部職業我稱之爲成爲大牛的一個道，這是1萬小時理論。

我先簡單介紹一下1萬小時理論，我最初看到1萬小時理論是從《異類》這本書知道的，這是很出名的書，它很是有意思，我建議全部同窗都去看一下，它分析了不少成功人士背後一些咱們一般狀況下不了解或沒看到的一些現象，得出一些比較使人震撼的結論，其中有一個理論就是1萬小時理論。

它裏面有舉了一些例子，好比說莫扎特，你們都知道他是音樂神童，6歲就開始做曲了，你看完這本書就知道他真正出人頭地是20多歲的時候，也就是說他雖然6歲開始做曲，但他當時做的曲也是比較很差的。

因此《異類》這本書裏面提到了1萬小時的理論，它對我是頗有幫助的，成爲世界上頂級的專家惟一的方法就是1萬小時持續不斷地進行練習，你們要特別注意「惟一」，也就是說絕大部分專業是沒有什麼天才的，所謂的天才只是他一舉成名以後咱們才這樣以爲，在他成爲天才以前至少要通過1萬小時持續不斷的練習。

我第一次看到1萬小時的理論，以爲沒什麼神奇的，我算了算，我工做五年就會成爲業界頂級的專家了，但想一想這是不可能的，爲何呢？我反思了一下我本身的工做狀態，對於大部分人來講天天的工做不少時候是重複勞動，雖然咱們一天工做8小時，可是隻是重複以往的經驗，並無刻意去訓練提高本身。

有一個笑話是有一個10年工做經驗的人去面試，面試完了以後面試官跟他說其實你只有1年工做經驗，你把它重複了9年。

對於1萬小時理論來講若是你深刻思考其實它並無那麼簡單，這意味着什麼呢？意味着你天天要花3小時時間用於提高本身的技能，這樣一直作，要持續大約10年時間。你們想一想天天持續十年去作一件事情去提高本身，有幾個能作到，因此咱們看到雖然有些人工做了10年，可是也不必定能成爲業界的專家。

爲何我要強調天天3小時？持續10年提高本身，你不能把你重複的工做算進去，你要在專業廣度和深度上面不斷擴展，才能業界一個頂尖的大牛或者專家。

舉一個例子，一個小孩子天天唱《兩隻老虎》，唱10年，你以爲他會成爲周杰倫嗎？確定不會。固然1萬小時理論不適合一些領域，尤爲是不適合炒股，特別是中國的股市，若是你花1萬小時去炒股，可能會傾家蕩產。

如何找到10000小時？  碎片化時間管理

Facebook提到了經過CI工具運行npm install時的問題，由於處於安全的考慮，他們的環境與互聯網是互相切斷的。最直接的解決方案就是單獨下載所需的模塊，並將它們包含到項目的源代碼中。可是，更新其中的某些數據模塊會帶來很大的影響。

1萬小時理論聽起來好像很簡單，天天持續3小時，也不難，但實際上真正作起來是很難的，就像咱們互聯網的人加班加成狗，感受身體每天被掏空，時間從哪來，這是一個現實問題，不要說天天抽3個小時提高本身，天天抽1個小時陪女友或者找女友的時間都不夠。具體怎麼作？

首先是找到3個30分鐘：

• 第一個30分鐘就是早上的30分鐘，假設你習慣8點起牀，明天你把鬧鐘改爲7點半，這就多了半個小時。

• 第二個30分鐘是睡覺前的30分鐘，假設你習慣玩遊戲到12點，明天晚上你玩遊戲就玩到11點半。

• 第三個30分鐘就是上班到你座位上的30分鐘，有的同窗擔憂說我這30分鐘會不會影響我這一天的工做效率，可能加班完不成，還讓我擠出30分鐘來，這不用擔憂，從個人經從來看擠30分鐘不會影響你總體的工做效率，持續一兩年，你會發現本身的收益很是大。

第二點是利用或節省路途時間

咱們天天上下班都是一兩個小時，好比像我這種，怎麼去利用時間呢？

首先是能夠利用上下班路上的時間去看書、聽書，也是能夠作的。若是你以爲上班路上是不能看書的，或者是不可能學習的，好比你坐廣州的3號線，這是聞名中外的擠得要命的，不要說看書了，把手伸出去都不知道去哪了，那就建議你們搬到離公司近一點位置，雖然每月多幾百塊錢的房租，可是你要相信這個投資節省下來的時間用於提高本身，它最終的收益是10倍回報都不止的。

第三點是週末4小時

週末仍是不用怎麼加班的，週末用於放鬆、睡覺、看電影、娛樂，你也能夠在週末裏面規定本身擠出4個小時，也就是天天2個小時，這樣算下來，一天大概就兩個多小時，再加上你在工做中的積累，天天3小時也不是很難。

接下來說一下我是怎麼作的，我如今有2個小孩，並且我住的比較遠，應該在座的比我忙的也不會不少，看一下我是怎麼作的，我是坐廣州的四號線，坐四號線天天來回能夠看一個小時的書，天天遲早30分鐘，週末4小時，有的同窗可能會有疑問，週末確定要帶小孩玩，本身也要休息，哪裏有4個小時，其實只要你去找，時間都會有的，我找的方法就是當我小孩睡覺的時候，由於小孩子睡覺通常要睡三四個小時，大人通常睡一個小時、半個小時就差很少了，因此經過這種方式，你們能夠看到2015年我一共看了84本書，有專業的，也有非專業的，人文社科、歷史這些都有。

不過特別提醒一下對於男程序員來講有一個時間千萬不能少，就是陪女友的時間，由於對程序員來講找女友不容易，別看了這篇文章回去以後女友也不要了，就每天回去提高，這也不是咱們想要的生活。

10000小時理論如何輕鬆落地？

雖然理論上很簡單，但真正要落地實行也並不那麼容易，實行10000小時理論的關鍵在於堅持，我認爲堅持的關鍵在於本身對於所從事的事業是否有「激情和興趣」。這點固然是核心，但若是隻靠激情支撐，持續10年也確實有挑戰，正如一個朋友在分享會後問個人「要持續10年才能成爲大牛啊，時間好長啊」！

若是說作一件事要10年後才能修成正果，估計不少朋友就會放棄了，畢竟像唐僧那麼堅決的信仰者老是少數，大部分凡夫俗子都仍是須要持續不斷的激勵纔能有動力去作一件事，由於咱們的大腦在進化的過程當中已經造成了須要持續不斷的獎勵才能保持興奮的機制，也就是說相對於在第10年給一個大獎勵，還不如每一年給一個小獎勵。

那如何才能在10年漫長的路上讓咱們持續的堅持下去呢？答案其實就是首富的話：「先定一個能達到的小目標」！咱們來看如何將「10年成爲大牛」這個目標分解爲一個個能達到的小目標。我將這個方法概括爲「三段分解法」，即：將一個宏大或者長遠的目標通過3次分解，獲得一個個短時間內能達到的小目標。具體的分解方法以下。

 一段分解：分解「等級」

10年成爲大牛的目標雖然比較長遠比較宏大，但並不意味着在沒有成爲大牛前，咱們一直都是菜鳥。從菜鳥到大牛的過程當中，中間其實有幾個關鍵的里程碑，這些里程碑就是咱們的一段目標。

以技術人員爲例，技術人員典型的發展路徑基本上都是下面的這個模式：

1）0 ~ 1年：菜鳥，須要別人手把手來教

2）1 ~ 3年：初級，須要別人帶你作

3）3 ~ 5年：高級，能獨當一面，能夠帶初級技術人員了

4）5 ~ 8年：資深，能獨擋多面

5）8 ~ 10年：大牛，統籌規劃，高屋建瓴

經過上面的分解咱們能夠看到，雖說10年才能成爲大牛，可是3年就能夠達到初級水平，5年就能夠達到高級水平，8年就能夠達到資深水平，在這個過程當中咱們一直在成長和提高，而不是說沒有成爲大牛就是菜鳥；而且對於不少朋友來講，若是目標不是像首富那樣要賺就賺1億，能達到高級或者資深水平，其實已經能夠過得比較滋潤了。經過這種分解方法，再覈對一下本身目前所處的位置，而後先瞄準下一個目標，盡心盡力其實也就2 ~ 3年時間，這樣來看一段目標實際上是比較容易達成的。這種目標分解的方法除了適合技術人員外，其它不少領域也都適應，好比說產品人員、運營人員、甚至公務員！

 二段分解：分解「技能」

通過一段分解後，明確本身目前所處的位置和下一個目標，接下來就要看這個一段目標如何實現了。雖說每一個一段目標持續時間在 2~3年，但3年時間說長不長，說短也不短，若是沒有好好利用，可能到了2年多的時候回頭一看，好像什麼都沒達成，仍是原地踏步。所以，爲了更好的利用這3年時間，咱們須要進一步分解，這就是「二段分解」。

一段分解的維度是等級，二段分解的維度則不同，不能再分等級了，不然等級太細就無法區別了。二段分解的維度變成了「技能」，即：爲了達到一段目標，我須要具有什麼樣的技能。

仍是以技術人員爲例，假設通過自我評估，認爲本身目前處於初級階段，並且初級階段的事情已經作得比較順手和熟練了，那麼下一個一段目標天然就是達到「高級」水平。「高級」與「初級」相比，有哪些不一樣的技能要求呢？

這就須要咱們根據各自不一樣的行業和方向詳細列出來了，若是本身想不出來，網上有不少資料均可以搜索到，最方便的就是到一個招聘網站，多看看幾個招聘需求的描述，而後概括總結一下。

咱們隨便到網上搜索一個，例如拉勾網上滴滴的「高級Java開發工程師」招聘：

多看幾個相似的職位招聘，基本上咱們就能明白「高級Java開發工程師」的一些基本要求。固然實際上的技能要求比招聘需求的描述還要更加細緻，我我的的習慣是將這些要求整理爲一個思惟導圖，詳細列出每一個技術點。例如：

注意：以上這個圖只是示例，並非說全部Java高級工程師都必定是這個要求，例如互聯網行業和電信行業的要求不同）

有了這樣一個思惟導圖後，咱們就能夠開始真正進行二段分解了，分解的方法很簡單：哪裏不懂補哪裏！例如：我感受目前個人數據庫水平通常，僅僅會寫CRUD語句，其它的東西都不懂，那我就開始專攻數據庫這一部分，通過一段時間的專攻來提高本身的水平。

二段目標持續時間通常建議是6個月，既不能過短也不能太長。過短容易讓人陷入爲了目標而作的誤區，沒有真正獲得有效提高；時間太長的話，3年時間又不夠完成其它目標了，例如要是我定一個目標說2年提高數據庫，那操做系統怎麼辦？網絡怎麼辦？……等等。以6個月爲一個週期，基本上剛恰好。

通過分解，最終的二段目標能夠分解爲以下的幾個更小的目標：

1）2016.06 ~ 2017.01：提高數據庫水平

2）2017.01 ~ 2017.06：提高Linux水平

3）2017.06 ~ 2017.12：提高網絡和網絡編程水平

固然，二段分解目標並非一成不變的，不少時候須要根據咱們工做的內容進行調整。例如老大正好安排我來負責優化系統性能，下降機器負載，那麼我徹底能夠將「提高Linux水平」安排到「提高數據庫水平」以前。

 三段分解：分解「行動」

二段分解獲得技能的小目標後，接下來的關鍵就是要實現這個目標，這就是三段分解的主要目的，即：將技能目標分解爲具體要作的事情，而後按照計劃執行。

好比說個人二段目標是「提高Linux水平」，那怎麼樣才能提高呢？能夠上網搜索（知乎是個好地方），也能夠去問有經驗的朋友。明確要作的事情後，三段分解須要將二段分解的6個月目標更加細化，分爲1個月或者兩個月一個目標。

以我當時加入UC的狀況爲例，我在華爲的時候是在Windows平臺上用VC6進行開發，而到了UC的時候是在Linux平臺上用C++開發，我當時定了「提高Linux水平」的目標，而後經過上網查，找別人問等方法，最終將這個目標分解爲幾個步驟：

1）1個月：通讀《UNIX環境高級編程》

2）1個月：通讀《Linux系統編程》

3）2個月：通讀《UNIX網絡編程 卷1》

4）1個月：Linux經常使用命令實戰：tcpdump、ps、top等

經過這種方法，將6個月的目標又進一步分解爲1個月的目標，實施起來就簡單多了，每1 ~ 2個月專一一個具體目標，每次完成後都頗有成就感，既感受本身的水平有了提高，又佩服本身可以堅持按計劃按目標完成任務，雙重獎賞讓本身更有動力進行下一個目標。

我大約花了2年的時間將Linux、網絡、MySQL三個重點技能從一無所知提高到高級的水平，不少同事都問我以前在華爲是否是就是作這方面的，由於他們以爲短期能達到這個水平是不太可能的。

綜合前面的分析，咱們將三段分解提煉一下：一段分解「等級」，二段分解「技能」，三段分解「行動」。經過前面咱們的案例就能夠看出，本來一個宏大的「10年成爲技術大牛」的目標，通過三段分解，最終獲得的是1 ~ 2個月可執行的具體行動，經過這種一步一個腳印的行動，最終就能夠達成「10年成爲技術大牛」的目標。

每天寫業務代碼，如何成爲技術大牛？  幾個典型的誤區

• 拜大牛爲師

知乎上有人認爲想成爲技術大牛最簡單直接、快速有效的方式是「拜團隊技術大牛爲師」，讓他們平時給你開小竈，給你分配一些有難度的任務。我我的是反對這種方法的，主要的緣由有幾個：

大牛很忙，不太可能單獨給你開小竈，更不可能天天都給你開1個小時的小竈；並且一個團隊裏面，若是大牛平時常常給你開小竈，不免會引發其餘團隊成員的疑惑，我我的認爲若是團隊裏的大牛若是真正有心的話，多給團隊培訓是最好的。然而作過培訓的都知道，準備一場培訓是很耗費時間的，課件和材料至少2個小時（還不能是碎片時間），講解1個小時，大牛們一個月作一次培訓已是很高頻了。

由於第一個緣由，因此通常要找大牛，都是帶着問題去請教或者探討。由於回答或者探討問題無需太多的時間，更多的是靠經驗和積累，這種狀況下大牛們都是很樂意的，畢竟影響力是大牛的一個重要指標嘛。然而也要特別注意：若是常常問那些書本或者google可以很容易查到的知識，大牛們也會很不耐煩的，畢竟時間寶貴。常常有網友問我諸如「jvm的-Xmn參數如何配置」這類問題，我都是直接回答「請直接去google」，由於這樣的問題實在是太多了，若是本身不去系統學習，每一個都要問是很是浪費本身和別人的時間的。

大牛很少，不太可能每一個團隊都有技術大牛，只能說團隊裏面會有比你水平高的人，即便他天天給你開小竈，最終你也只能提高到他的水平；而若是是跨團隊的技術大牛，因爲工做安排和分配的緣由，直接請教和輔導的機會是比較少的，單憑參加幾回大牛的培訓，是不太可能就成爲技術大牛的。

綜合上述的幾個緣由，我認爲對於大部分人來講，要想成爲技術大牛，首先仍是要明白「主要靠本身」這個道理，不要指望有個像武功師傅同樣的大牛手把手一步一步的教你。適當的時候能夠經過請教大牛或者和大牛探討來提高本身，但大部分時間仍是本身系統性、有針對性的提高。

 業務代碼同樣很牛逼

知乎上有的回答認爲寫業務代碼同樣能夠很牛逼，理由是業務代碼同樣能夠有各類技巧，例如可使用封裝和抽象使得業務代碼更具可擴展性，能夠經過和產品多交流以便更好的理解和實現業務，日誌記錄好了問題定位效率能夠提高10倍……等等。

業務代碼同樣有技術含量，這點是確定的，業務代碼中的技術是每一個程序員的基礎，但只是掌握了這些技巧，並不能成爲技術大牛，就像遊戲中升級打怪同樣，開始打小怪，經驗值很高，越到後面經驗值越少，打小怪已經不能提高經驗值了，這個時候就須要打一些更高級的怪，刷一些有挑戰的副本了，沒看到哪一個遊戲只要一直打小怪就能升到頂級的。

成爲技術大牛的路也是相似的，你要不斷的提高本身的水平，而後面臨更大的挑戰，經過應對這些挑戰從而使本身水平更上一級，而後如此往復，最終達到技術大牛甚至業界大牛的境界，寫業務代碼只是這個打怪升級路上的一個挑戰而已，並且我認爲是比較初級的一個挑戰。

因此我認爲：author >業務代碼都寫很差的程序員確定沒法成爲技術大牛，但只把業務代碼寫好的程序員也還不能成爲技術大牛。

 上班太忙沒時間本身學習

不少人認爲本身沒有成爲技術大牛並非本身不聰明，也不是本身不努力，而是中國的這個環境下，技術人員加班都太多了，致使本身沒有額外的時間進行學習。這個理由有必定的客觀性，畢竟和歐美相比，咱們的加班確實要多一些，但這個因素只是一個須要克服的問題，並非不可逾越的鴻溝，畢竟咱們身邊仍是有那麼多的大牛也是在中國這個環境成長起來的。

我認爲有幾個誤區致使了這種見解的造成：

1）上班作的都是重複工做，要想提高必須本身額外去學習

造成這個誤區的主要緣由仍是在於認爲「寫業務代碼是沒有技術含量的」，而我如今上班就是寫業務代碼，因此我在工做中不能提高。

2）學習須要大段的連續時間

不少人覺得要學習就要像學校上課同樣，給你一成天時間來上課纔算學習，而咱們平時加班又比較多，週末累的只想睡懶覺，或者只想去看看電影打打遊戲來放鬆，因此就沒有時間學習了。

正確的作法正好相反：

首先咱們應該在工做中學習和提高，由於學以至用或者有實例參考，學習的效果是最好的；其次工做後學習不須要大段時間，而是要擠出時間，利用時間碎片來學習。（參照前文10000小時理論）

 正確的作法

• Do more

作的更多，作的比你主管安排給你的任務更多。

我在HW的時候，負責一個版本的開發，這個版本的工做量大約是2000行左右，可是我除了作完這個功能，還將關聯的功能所有掌握清楚了，代碼（大約10000行）也所有看了一遍，作完這個版本後，我對這個版本相關的整套業務所有很熟悉了。通過一兩次會議後，你們發現我對這塊掌握最熟了，接下來就有趣了：產品討論需求找我、測試有問題也找我、老大對外支撐也找我；後來，不是我負責的功能他們也找我，即便我當時不知道，我也會看代碼或者找文檔幫他們回答……最後我就成了我這個系統的「專家」了。雖然這個時候我仍是作業務的，仍是寫業務代碼，可是我已經對整個業務都很熟悉了。

以上只是一個簡單的例子，其實就是想說：要想有機會，首先你得從人羣中冒出來，要想冒出來，你就必須作到不同凡響，要作到不同凡響，你就要作得更多！

怎麼作得更多呢？能夠從如下幾個方面着手：

1）熟悉更多業務，無論是否是你負責的；熟悉更多代碼，無論是否是你寫的

這樣作有不少好處，舉幾個簡單的例子：

需求分析的時候更加準確，可以在需求階段就識別風險、影響、難點

問題處理的時候更加快速，由於相關的業務和代碼都熟悉，可以快速的判斷問題可能的緣由並進行排查處理

方案設計的時候考慮更加周全，因爲有對全局業務的理解，可以設計出更好的方案

2）熟悉端到端

好比說你負責web後臺開發，但實際上用戶發起一個http請求，要通過不少中間步驟纔到你的服務器（例如瀏覽器緩存、DNS、nginx等），服務器通常又會通過不少處理纔到你寫的那部分代碼（路由、權限等）這整個流程中的不少系統或者步驟，絕大部分人是不可能去參與寫代碼的，但掌握了這些知識對你的綜合水平有很大做用，例如方案設計、線上故障處理這些更加有含金量的技術工做都須要綜合技術水平。

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

3）自學

通常在比較成熟的團隊，因爲框架或者組件已經進行了大量的封裝，寫業務代碼所用到的技術確實也比較少，但咱們要明白「惟一不變的只有變化」，框架有可能要改進，組件可能要替換，現有技術可能已經沒法知足業務需求，或者你換了一家公司，新公司既沒有組件也沒有框架，要你從頭開始來作。這些都是機會，也是挑戰，而機會和挑戰只會分配給有準備的人，因此這種狀況下咱們更加須要自學更多東西，由於真正等到要用的時候再來學已經沒有時間了。

以java爲例，大部分業務代碼就是if-else加個數據庫操做，但咱們徹底能夠本身學些更多java的知識，例如垃圾回收，調優，網絡編程等，這些可能暫時沒用，但真要用的時候，不是google一下就能夠了，這個時候誰已經掌握了相關知識和技能，機會就是誰的。

以垃圾回收爲例，我本身平時就抽時間學習了這些知識，學了1年都沒用上，但後來用上了幾回，每次都解決了卡死的大問題，而有的同窗，寫了幾年的java代碼，對於stop-the-world是什麼概念都不知道，更不用說去優化了。

特別是不少開源軟件，更加須要本身平時去自學，例如Nginx、Redis、Mongodb、ElasticSearch等，在合適的時機引入這些技術，可以帶來很大的價值。

• Do better

要知道這個世界上沒有完美的東西，你負責的系統和業務，總有不合理和能夠改進的地方，這些「不合理」和「可改進」的地方，都是更高級別的怪物，打完後可以增長更多的經驗值。識別出這些地方，而且給出解決方案，而後向主管提出，一次不行兩次，多提幾回，只要有一次落地了，這就是你的機會。

例如：

重複代碼太多，是否能夠引入設計模式？

系統性能通常，能否進行優化？

目前是單機，若是作成雙機是否更好？

版本開發質量不高，是否引入高效的單元測試和集成測試方案？

目前的系統太龐大，是否能夠經過重構和解耦改成3個系統？

阿里中間件有一些系統感受咱們也能夠用，是否能夠引入 ？

只要你去想，其實總能發現能夠改進的地方的；若是你以爲系統哪裏都沒有改進的地方，那就說明你的水平還不夠，能夠多學習相關技術，多看看業界其它公司怎麼作，BAT都怎麼作。

我2013年調配到九遊，剛開始接手了一個簡單的後臺系統，天天就是配合前臺作數據增刪改查，看起來徹底沒意思，是吧？若是隻作這些確實沒意思，但咱們接手後作了不少事情：

• 解耦，將一個後臺拆分爲2個後臺，提高可擴展性和穩定性；

• 雙機，將單機改成雙機系統，提升可靠性；

• 優化，將原來一個耗時5小時的接口優化爲耗時5分鐘

還有其它不少優化，後來咱們這個組承擔了更多的系統，後來這個小組5我的，負責了6個系統。

• Do exercise

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

例如：

學習了jvm的垃圾回收，可是線上比較少出現FGC致使的卡頓問題，就算出現了，恢復業務也是第一位的，不太可能線上出現問題而後讓每一個同窗都去練一下手，那怎麼去實踐這些jvm的知識和技能呢？

Netty我也看了，也瞭解了Reactor的原理，可是我不可能參與Netty開發，怎麼去讓本身真正掌握Reactor異步模式呢？

看了《高性能MySQL》，可是線上的數據庫都是DBA管理的，測試環境的數據庫感受又是隨便配置的，我怎麼去驗證這些技術呢？

框架封裝了DAL層，數據庫的訪問咱們都不須要操心，咱們怎麼去了解分庫分表實現？

諸如此類問題還有不少，我這裏分享一下我的的經驗，其實就是3個詞：learning、trying、teaching！

1）Learning

這個是第一階段，看書、google、看視頻、看別人的博客均可以，但要注意一點是「系統化」，特別是一些基礎性的東西，例如JVM原理、Java編程、網絡編程，HTTP協議。。。。。。等等，這些基礎技術不能只經過google或者博客學習，個人作法通常是先完整的看完一本書全面的瞭解，而後再經過google、視頻、博客去有針對性的查找一些有疑問的地方，或者一些技巧。

2）Trying

這個步驟就是解答前面提到的不少同窗的疑惑的關鍵點，形象來講就是「本身動手豐衣足食」，也就是本身去嘗試搭建一些模擬環境，本身寫一些測試程序。例如：

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，並且「試試」其實能夠比較簡單，不少時候咱們均可以本身動手作。

固然，若是可以在實際工做中使用，效果會更好，畢竟實際的線上環境和業務複雜度不是咱們寫個模擬程序就可以模擬的，但這樣的機會可遇不可求，大部分狀況咱們還真的只能靠本身模擬，而後等到真正業務要用的時候，可以信手拈來。

3）Teaching

通常來講，通過Learning和Trying，能掌握70%左右，但要真正掌握，我以爲必定要作到可以跟別人講清楚。由於在講的時候，咱們既須要將一個知識點系統化，也須要考慮各類細節，這會促使咱們進一步思考和學習。同時，講出來後看或者聽的人能夠有不一樣的理解，或者有新的補充，這至關於繼續完善了整個知識技能體系。

這樣的例子不少，包括我本身寫博客的時候常常遇到，原本我以爲本身已經掌握很全面了，但一寫就發現不少點沒考慮到；組內培訓的時候也常常看到，有的同窗寫了PPT，可是講的時候，你們一問，或者一討論，就會發現不少點尚未講清楚，或者有的點實際上是理解錯了。寫PPT、講PPT、討論PPT，這個流程所有走一遍，基本上對一個知識點掌握就比較全面了。

後記

成爲技術大牛夢想雖然很美好，可是要付出不少，無論是Do more仍是Do better仍是Do exercise，都須要花費時間和精力，這個過程當中可能很苦逼，也可能很枯燥，這裏我想特別強調一下：前面我講的都是一些方法論的東西，但真正起決定做用的，其實仍是咱們對技術的熱情和興趣！

本文系InfoQ原創文章，已經受權StuQ公衆號轉發傳播。

做者介紹

李運華，阿里遊戲資深軟件工程師，帶領多個研發團隊，承擔架構設計、架構重構、技術團隊管理、技術培訓等職責；專一於開源技術、系統分析、架構設計，對互聯網技術的特色和發展趨勢有較深刻的研究，對系統解耦、高性能、高可用架構有豐富的經驗。