程式設計師平時的日常編碼工作中，大多數人都只是編寫業務程式碼，各種if else以及資料庫操作等。針對於不同的產品去實現功能時，也只是重複性的搬磚工作。此時會有很多人認為天天寫業務程式碼，感覺沒有什麼長進，也沒有實際的需求可以讓自己深入的研究技術程式碼。那麼這種情況下如何成為技術大牛呢？

    首先說明一點，不管是多簡單的產品，實現過程中都會遇到大大小小的問題，例如崩潰、死鎖、效能低，系統延遲、伺服器不穩定、資料丟失等等。一個產品的成功，勢必要解決這些技術性的問題，那麼由誰解決呢？可能有人會說基本上都是團隊中的大牛負責解決，其他人依然埋沒在自己的業務程式碼中。那麼團隊中的技術大牛又是如何成長起來的呢？任何人不可能剛開始就處理這種棘手問題吧，那麼他們又是如何成長的呢？針對這種情況，從以下幾點說明一下在每天的業務程式碼搬運過程中，如何使自己成長為技術大牛（個人意見，僅供參考）：

1、問題就是機會

    不管任何系統都會遇到各種技術問題。這些問題，都是自己成長的機遇，而真正抓住機遇的人，都會有所收穫。所以不管在日常的開放中遇到上面樣的難題，都要有直面它的勇氣，迎難而上，主動去解決。當你解決了一個難題後，就會有下一個，當你解決的多的時候，團隊中遇到難題都會自然的找到你。你也就自然成為了團隊中的技術大牛。

    其實解決的問題多了，就會越來越有感覺，你也會發現很多問題只要認真研究，都沒有那麼難，只是很多人都不願主動去解決，不願主動去承擔。所以，不管什麼時候，做一個積極主動的人，把問題當做機會，讓自己經歷更多成長更多。

2、靠自己，不斷努力提升自己

    實際工作中，不管你從事的崗位所負責的工作多麼的簡單，同樣都會遇到各種問題。當遇到這種問題時，首先要想到的是自己，即便是水平不高，能夠自己解決的就儘量自己解決。實在需要問別人的時候，也不要去問那些網上或者書中能查到的東西。首先別人不一定有時間，即便是有時間，也不一定能夠給你說的很明白，日常工作大多以解決問題為目的，這個問題已經解決了，但你仍然不懂得其中的道理，所以考自己的學習和研究去解決問題，對自己的影響才是最深遠的。

    另外也不要指望領導專門給你安排去解決各種技術難題，這種問題都是有大拿去解決的，要想成為大拿，還是要靠自己腳踏實地的走過來。

    日常平庸的工作中，要自己主動去探索，去爭取機會，去擠時間提高自己。不要等到哪一天技術難題突然降臨到你身上，你卻說不可能。

3、Do more       

    要想有機會，首先你得從人群中冒出來，要想冒出來，你就必須做到與眾不同，要做到與眾不同，你就要做得更多！

    怎麼做得更多呢？可以從以下幾個方面著手：

    1）熟悉更多業務，不管是不是你負責的；熟悉更多程式碼，不管是不是你寫的

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

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

• 問題處理的時候更加快速，因為相關的業務和程式碼都熟悉，能夠快速的判斷問題可能的原因並進行排查處理

• 方案設計的時候考慮更加周全，由於有對全域性業務的理解，能夠設計出更好的方案

    2）熟悉端到端

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

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

    3）自學

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

        以java為例，大部分業務程式碼就是if-else加個資料庫操作，但我們完全可以自己學些更多java的知識，例如垃圾回收，調優，網路程式設計等，這些可能暫時沒用，但真要用的時候，不是google一下就可以了，這個時候誰已經掌握了相關知識和技能，機會就是誰的。

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

        特別是很多開源軟體，更加需要自己平時去自學，例如Nginx、Redis、Mongodb、ElasticSearch等，在合適的時機引入這些技術，能夠帶來很大的價值。

4、Do better

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

    例如：

• 重複程式碼太多，是否可以引入設計模式？

• 系統性能一般，可否進行優化？

• 目前是單機，如果做成雙機是否更好？

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

• 目前的系統太龐大，是否可以通過重構和解耦改為3個系統？

• 阿里中介軟體有一些系統感覺我們也可以用，是否可以引入 ？

• 。。。。。。。。。。。。。。。。。。。

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

5、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，都需要花費時間和精力，這個過程中可能很苦逼，也可能很枯燥，這裡我想特別強調一下：前面我講的都是一些方法論的東西，但真正起決定作用的，其實還是我們對技術的熱情和興趣！

——《部分內容摘自網路》