要想成為技術大牛， 
首先還是 要明白“主要靠自己”這個道理，不要期望有個像武功師傅一樣的大牛手把手一步一步地教你。適當的時候可以通過請教大牛或者和大牛探討來提升自己，但大部分時間 還是自己系統性、有針對性的提升

業務程式碼一樣很牛逼 
有人認為寫業務程式碼一樣可以很牛逼，理由是業務程式碼一樣可以有各種技巧，例如可以使用封裝和抽象使得業務程式碼更具可擴充套件性，可以通過和產品多交流以便更好的理解和實現業務，日誌記錄好了問題定位效率可以提升 10 倍等等。業務程式碼一樣有技術含量，這點是肯定的，業務程式碼中的技術是每個程式設計師的基礎，但只是掌握了這些技巧，並不能成為技術大牛，就像遊戲中升級打怪一樣，開始打小怪，經驗值很高，越到後面經驗值越少，打小怪已經不能提升經驗值了，這個時候就需要打一些更高階的怪，刷一些有挑戰的副本了，沒看到哪個遊戲只要一直打小怪就能升到頂級的。成為技術大牛的路也是類似的，你要不斷的提升自己的水平，然後面臨更大的挑戰，通過應對這些挑戰從而使自己水平更上一級，然後如此往復，最終達到技術大牛甚至業界大牛的境界，寫業務程式碼只是這個打怪升級路上的一個挑戰 
而已，而且我認為是比較初級的一個挑戰。

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

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

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

1. 1）上班做的都是重複工作，要想提升必須自己額外去學習 形成這個誤區的
2. 主要原因還是在於認為“寫業務程式碼是沒有技術含量的”，而我學習需要大段的連續時間 很多人以為要學習就要像學校上課一樣，給你一整天時間來上課才算學習，而我 們平時加班又比較多，週末累的只想睡懶覺，或者只想去看看電影打打遊戲來放鬆， 所以就沒有時間學習了。

3. 實際上的做法正好相反：

   首先我們應該在工作中學習和提升，因為學以致用或者有例項參考，學習的效果是最好的； 其次工作後學習不需要大段時間，而是要擠出時 間，利用時間碎片來學習。

正確的做法

Do more 
做的更多，做的比你主管安排給你的任務更多。 
我在 HW 的時候，負責一個版本的開發，這個版本的工作量大約是 2000 行左右，但是我除了做完這個功能，還將關聯的功能全部掌握清楚了，程式碼（大約 10000行）也全部看了一遍，做完這個版本後，我對這個版本相關的整套業務全部很熟悉了。經過一兩次會議後，大家發現我對這塊掌握最熟了，接下來就有趣了：產品討論需求找我、測試有問題也找我、老大對外支撐也找我；後來，不是我負責的功能他們也找我，即使我當時不知道，我也會看程式碼或者找文件幫他們回答。最後我就成了我這個系統的“專家”了。雖然這個時候我還是做業務的，還是寫業務程式碼，但是我已經對整個業務都很熟悉了。 
以上只是一個簡單的例子，

其實就是想說：要想有機會，首先你得從人群中冒出 來，要想冒出來， 
你就必須做到與眾不同，要做到與眾不同，你就要做得更多！ 
怎麼做得更多呢？

可以從以下幾個方面著手： 
1）熟悉更多業務， 
不管是不是你負責的；熟悉更多程式碼，不管是不是你寫的這樣做有很多好處， 
舉幾個簡單的例子： 
● 需求分析的時候更加準確，能夠在需求階段就識別風險、影響、難點 
● 問題處理的時候更加快速，因為相關的業務和程式碼都熟悉，能夠快速的判斷問 
題可能的原因並進行排查處理 
● 方案設計的時候考慮更加周全，由於有對全域性業務的理解，能夠設計出更好 
的方案

2）熟悉端到端

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

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

3）自學

一般在比較成熟的團隊，由於框架或者元件已經進行了大量的封裝，寫業務程式碼所用到的技術確實也比較少，但我們要明白“唯一不變的只有變化”，框架有可能要改進，元件可能要替換，或者你換了一家公司，新公司既沒有元件也沒有框架，要你從頭開始來做。這些都是機會，也是挑戰，而機會和挑戰只會分配給有準備的人， 所以這種情況下我們更加需要自學更多東西，因為真正等到要用的時候再來學已經沒有時間了。

以 java 為例，

大部分業務程式碼就是 if-else 加個資料庫操作，但我們完全可以 自己學些更多 java的知識， 
例如垃圾回收，調優，網路程式設計等，這些可能暫時沒用， 但真要用的時候，不是 google 
一下就可以了，這個時候誰已經掌握了相關知識和技 能，機會就是誰的。以垃圾回收為例，我自己平時就抽時間學習了這些知識，學了 1年都沒用上，但後來用上了幾次，每次都解決了卡死的大問題，而有的同學，寫了幾年的 java 程式碼， 對於 stop-the-world 是什麼概念都不知道，更不用說去優化了

Do better

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

例如：

1. 重複程式碼太多，是否可以引入設計模式？
2. 系統性能一般，可否進行優化？
3. 目前是單機，如果做成雙機是否更好？
4. 目前的系統太龐大，是否可以通過重構和解耦改為 3 個系統？
5. 只要你去想，其實總能發現可以改進的地方的；
6. 如果你覺得系統哪裡都沒有改進的地方，那就說明你的水平還不夠，可以多學習相關技術；
7. 多看看業界其它優秀公司怎麼做。

我 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 來觀察瀏覽器的反應。

還有很多方法，這裡就不一一列舉，簡單來說，就是要將學到的東西真正試 試，才能理解更加深刻，而且“試試”其實可以比較簡單，很多時候 我們都可以自己動手做。

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

3）Teaching

一般來說，經過 Learning 和 Trying，能掌握 70% 左右，但要真正掌握，我覺 
得一定要做到能夠跟別人講清楚。因為在講的時候，我們既需要將一個知識點系統 
化，也需要考慮各種細節，這會促使我們進一步思考和學習。同時，講出來後看或者聽 
的人可以有不同的理解，或者有新的補充，這相當於繼續完善了整個知識技能體系。

這樣的例子很多，包括我自己寫部落格的時候經常遇到，本來我覺得自己已經掌 
握很全面了，但一寫就發現很多點沒考慮到；組內培訓的時候也經常看到，有的同學 
寫了 PPT，但是講的時候，大家一問，或者一討論，就會發現很多點還沒有講清楚， 
或者有的點其實是理解錯了。寫 PPT、講 PPT、討論 PPT，這個流程全部走一遍， 
基本上對一個知識點掌握就比較全面了。

後記

成為技術大牛夢想雖然很美好，但是要付出很多，不管是 Do more 還是 Do better 還是 Do 
exercise，都需要花費時間和精力，這個過程中可能很苦逼，也可能 很枯燥，

這裡我想特別強調一下：前面我講的都是一些方法論的東西，但真正起決定 
作用的，

其實還是我們對技術的熱情和興趣！

總結： 平時碰到問題 要深入研究 ，然後 反覆反覆反覆 總結 ，找到問題的本質

轉載出處:https://blog.csdn.net/dgutliangxuan/article/details/80938263