小編特地從阿裡技術協會（ata）分享一篇内部文章：
不管是開發、測試、運維，每個技術人員心理多多少少都有一個成為技術大牛的夢，畢竟“夢想總是要有的，萬一實作了呢”！正是對技術夢的追求，促使我們不斷地努力和提升自己。
然而“夢想是美好的，現實卻是殘酷的”，很多同學在實際工作後就會發現，夢想是成為大牛，但做的事情看起來跟大牛都不沾邊，例如，程式員說“天天寫業務代碼還加班，如何才能成為技術大牛”，測試說“每天都有執行不完的測試用例”，運維說“扛機器接網線敲shell指令，這不是我想要的運維人生”。。。。。。知乎上類似的問題“天天寫業務代碼的程式員，怎麼成為技術大牛，開始寫技術代碼？”關注人數有6k+，答案有120+，當時我也回答了并且點贊數最多，後來做職業等級晉升面評和溝通的時候，又有了新的發現和想法，于是有了系統的整理一篇文章的想法，希望讓更多同學在技術大牛的路上能夠少走一些彎路。
由于我是程式員，是以以下的一些例子都是基于程式開發的，但大道理是相通的，測試、運維都可以借鑒。
拜大牛為師
知乎上有人認為想成為技術大牛最簡單直接、快速有效的方式是“拜團隊技術大牛為師”，讓他們平時給你開小竈，給你配置設定一些有難度的任務。
我個人是反對這種方法的，主要的原因有幾個：
大牛很忙，不太可能單獨給你開小竈，更不可能每天都給你開1個小時的小竈；而且一個團隊裡面，如果大牛平時經常給你開小竈，難免會引起其他團隊成員的疑惑，我個人認為如果團隊裡的大牛如果真正有心的話，多給團隊教育訓練是最好的。然而做過教育訓練的都知道，準備一場教育訓練是很耗費時間的，課件和材料至少2個小時（還不能是碎片時間），講解1個小時，大牛們一個月做一次教育訓練已經是很高頻了。 因為第一個原因，是以一般要找大牛，都是帶着問題去請教或者探讨。因為回答或者探讨問題無需太多的時間，更多的是靠經驗和積累，這種情況下大牛們都是很樂意的，畢竟影響力是大牛的一個重要名額嘛。然而也要特别注意：如果經常問那些書本或者google能夠很容易查到的知識，大牛們也會很不耐煩的，畢竟時間寶貴。經常有網友問我諸如“jvm的-xmn參數如何配置”這類問題，我都是直接回答“請直接去google”，因為這樣的問題實在是太多了，如果自己不去系統學習，每個都要問是非常浪費自己和别人的時間的。 大牛不多，不太可能每個團隊都有技術大牛，隻能說團隊裡面會有比你水準高的人，即使他每天給你開小竈，最終你也隻能提升到他的水準；而如果是跨團隊的技術大牛，由于工作安排和配置設定的原因，直接請教和輔導的機會是比較少的，單憑參加幾次大牛的教育訓練，是不太可能就成為技術大牛的。
綜合上述的幾個原因，我認為對于大部分人來說，要想成為技術大牛，首先還是要明白“主要靠自己”這個道理，不要期望有個像武功師傅一樣的大牛手把手一步一步的教你。适當的時候可以通過請教大牛或者和大牛探讨來提升自己，但大部分時間還是自己系統性、有針對性的提升。
業務代碼一樣很牛逼
知乎上有的回答認為寫業務代碼一樣可以很牛逼，理由是業務代碼一樣可以有各種技巧，例如可以使用封裝和抽象使得業務代碼更具可擴充性，可以通過和産品多交流以便更好的了解和實作業務，日志記錄好了問題定位效率可以提升10倍。。。。。。等等。
業務代碼一樣有技術含量，這點是肯定的，業務代碼中的技術是每個程式員的基礎，但隻是掌握了這些技巧，并不能成為技術大牛，就像遊戲中更新打怪一樣，開始打小怪，經驗值很高，越到後面經驗值越少，打小怪已經不能提升經驗值了，這個時候就需要打一些更進階的怪，刷一些有挑戰的副本了，沒看到哪個遊戲隻要一直打小怪就能升到頂級的。成為技術大牛的路也是類似的，你要不斷的提升自己的水準，然後面臨更大的挑戰，通過應對這些挑戰進而使自己水準更上一級，然後如此往複，最終達到技術大牛甚至業界大牛的境界，寫業務代碼隻是這個打怪更新路上的一個挑戰而已，而且我認為是比較初級的一個挑戰。
是以我認為：業務代碼都寫不好的程式員肯定無法成為技術大牛，但隻把業務代碼寫好的程式員也還不能成為技術大牛。
上班太忙沒時間自己學習
很多人認為自己沒有成為技術大牛并不是自己不聰明，也不是自己不努力，而是中國的這個環境下，技術人員加班都太多了，導緻自己沒有額外的時間進行學習。
這個理由有一定的客觀性，畢竟和歐美相比，我們的加班确實要多一些，但這個因素隻是一個需要克服的問題，并不是不可逾越的鴻溝，畢竟我們身邊還是有那麼多的大牛也是在中國這個環境成長起來的。
我認為有幾個誤區導緻了這種看法的形成：
1）上班做的都是重複工作，要想提升必須自己額外去學習 形成這個誤區的主要原因還是在于認為“寫業務代碼是沒有技術含量的”，而我現在上班就是寫業務代碼，是以我在工作中不能提升。 2）學習需要大段的連續時間很多人以為要學習就要像學校上課一樣，給你一整天時間來上課才算學習，而我們平時加班又比較多，周末累的隻想睡懶覺，或者隻想去看看電影打打遊戲來放松，是以就沒有時間學習了。
do more
做的更多，做的比你主管安排給你的任務更多。
我在hw的時候，負責一個版本的開發，這個版本的工作量大約是2000行左右，但是我除了做完這個功能，還将關聯的功能全部掌握清楚了，代碼（大約10000行）也全部看了一遍，做完這個版本後，我對這個版本相關的整套業務全部很熟悉了。經過一兩次會議後，大家發現我對這塊掌握最熟了，接下來就有趣了：産品讨論需求找我、測試有問題也找我、老大對外支撐也找我；後來，不是我負責的功能他們也找我，即使我當時不知道，我也會看代碼或者找文檔幫他們回答。。。。。。最後我就成了我這個系統的“專家”了。雖然這個時候我還是做業務的，還是寫業務代碼，但是我已經對整個業務都很熟悉了。
以上隻是一個簡單的例子，其實就是想說：要想有機會，首先你得從人群中冒出來，要想冒出來，你就必須做到與衆不同，要做到與衆不同，你就要做得更多！
怎麼做得更多呢？可以從以下幾個方面着手：
1）熟悉更多業務，不管是不是你負責的；熟悉更多代碼，不管是不是你寫的 這樣做有很多好處，舉幾個簡單的例子： 需求分析的時候更加準确，能夠在需求階段就識别風險、影響、難點 問題處理的時候更加快速，因為相關的業務和代碼都熟悉，能夠快速的判斷問題可能的原因并進行排查處理 方案設計的時候考慮更加周全，由于有對全局業務的了解，能夠設計出更好的方案 2）熟悉端到端 比如說你負責web背景開發，但實際上使用者發起一個http請求，要經過很多中間步驟才到你的伺服器（例如浏覽器緩存、dns、nginx等），伺服器一般又會經過很多處理才到你寫的那部分代碼（路由、權限等）這整個流程中的很多系統或者步驟，絕大部分人是不可能去參與寫代碼的，但掌握了這些知識對你的綜合水準有很大作用，例如方案設計、線上故障處理這些更加有含金量的技術工作都需要綜合技術水準。 “系統性”、“全局性”、“綜合性”這些字眼看起來比較虛，但其實都是技術大牛的必備的素質，要達到這樣的境界，必須去熟悉更多系統、業務、代碼。 3）自學 一般在比較成熟的團隊，由于架構或者元件已經進行了大量的封裝，寫業務代碼所用到的技術确實也比較少，但我們要明白“唯一不變的隻有變化”，架構有可能要改進，元件可能要替換，或者你換了一家公司，新公司既沒有元件也沒有架構，要你從頭開始來做。這些都是機會，也是挑戰，而機會和挑戰隻會配置設定給有準備的人，是以這種情況下我們更加需要自學更多東西，因為真正等到要用的時候再來學已經沒有時間了。 以java為例，大部分業務代碼就是if-else加個資料庫操作，但我們完全可以自己學些更多java的知識，例如垃圾回收，調優，網絡程式設計等，這些可能暫時沒用，但真要用的時候，不是google一下就可以了，這個時候誰已經掌握了相關知識和技能，機會就是誰的。 以垃圾回收為例，我自己平時就抽時間學習了這些知識，學了1年都沒用上，但後來用上了幾次，每次都解決了卡死的大問題，而有的同學，寫了幾年的java代碼，對于stop-the-world是什麼概念都不知道，更不用說去優化了。
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，都需要花費時間和精力，這個過程中可能很苦逼，也可能很枯燥，這裡我想特别強調一下：前面我講的都是一些方法論的東西，但真正起決定作用的，其實還是我們對技術的熱情和興趣！
作者：阿裡雲雲栖社群 來源：知乎