首先申明，文章是我在碼農網摘過來的，那裡沒有分享，我感覺程式設計師也需要雞湯，或者說這篇文章更應該是一篇一個過來人的經驗，以及對我們這些想學計算機或者其他各行各業的人的一個簡單的闡述。讀完文章後，感覺收穫很多，作者說的對，堅持，一鳴驚人需要堅持不斷地做一件事。我是前端小學生，每天晚上都會練習程式碼，並瀏覽微博，前端路上，有你有我。

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

一碗有勺子的雞湯

我工作已經將近 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 小時？

碎片化時間管理

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

首先是找到 3 個 30 分鐘：

1. 第一個 30 分鐘就是早上的 30 分鐘，假設你習慣 8 點起床，明天你把鬧鐘改成 7 點半，這就多了半個小時。
2. 第二個 30 分鐘是睡覺前的 30 分鐘，假設你習慣玩遊戲到 12 點，明天晚上你玩遊戲就玩到 11 點半。
3. 第三個 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 倍……等等。

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

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

所以我認為：業務程式碼都寫不好的程式設計師肯定無法成為技術大牛，但只把業務程式碼寫好的程式設計師也還不能成為技術大牛。

上班太忙沒時間自己學習

很多人認為自己沒有成為技術大牛並不是自己不聰明，也不是自己不努力，而是中國的這個環境下，技術人員加班都太多了，導致自己沒有額外的時間進行學習。

這個理由有一定的客觀性，畢竟和歐美相比，我們的加班確實要多一些，但這個因素只是一個需要克服的問題，並不是不可逾越的鴻溝，畢竟我們身邊還是有那麼多的大牛也是在中國這個環境成長起來的。

我認為有幾個誤區導致了這種看法的形成：

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 伺服器，模擬返回各種 s 來觀察瀏覽器的反應。

還有很多方法，這裡就不一一列舉，簡單來說，就是要將學到的東西真正試試，才能理解更加深刻，印第安人有一句諺語：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，都需要花費時間和精力，這個過程中可能很苦逼，也可能很枯燥，這裡我想特別強調一下：前面我講的都是一些方法論的東西，但真正起決定作用的，其實還是我們對技術的熱情和興趣！