漫談程序員(109)每天寫業務代碼，如何成為技術大牛？

??不論是開發、測試、運維，每一個技術人員心理多多少少都有1個成為技術大牛的夢，畢竟“夢想總是要有的，萬1實現了呢”！正是對技術夢的尋求，促使我們不斷地努力和提升自己。

??但是“夢想是美好的，現實卻是殘暴的”，很多同學在實際工作后就會發現，夢想是成為大牛，但做的事情看起來跟大牛都不沾邊，例如，程序員說“每天寫業務代碼還加班，如何才能成為技術大牛”，測試說“每天都有履行不完的測試用例”，運維說“扛機器接網線敲shell命令，這不是我想要的運維人生”…. 知乎上類似的問題“每天寫業務代碼的程序員，怎樣成為技術大牛，開始寫技術代碼？”關注人數有6K+，答案有120+，當時我也回答了并且點贊數最多，后來做職業等級提升面評和溝通的時候，又有了新的發現和想法，因而有了系統的整理1篇文章的想法，希望讓更多同學在技術大牛的路上能夠少走1些彎路。
由于我是程序員，所以以下的1些例子都是基于程序開發的，但大道理是相通的，測試、運維都可以鑒戒。

幾個典型的誤區

1、拜大牛為師

??知乎上有人認為想成為技術大牛最簡單直接、快速有效的方式是“拜團隊技術大牛為師”，讓他們平時給你開小灶，給你分配1些有難度的任務。
??我個人是反對這類方法的，主要的緣由有幾個：
??大牛很忙，不太可能單獨給你開小灶，更不可能每天都給你開1個小時的小灶；而且1個團隊里面，如果大牛平時常常給你開小灶，難免會引發其他團隊成員的疑惑，我個人認為如果團隊里的大牛真正有心的話，多給團隊培訓是最好的。但是做過培訓的都知道，準備1場培訓是很耗費時間的，課件和材料最少2個小時（還不能是碎片時間），講授1個小時，大牛們1個月做1次培訓已是很高頻了。
??由于第1個緣由，所以1般要找大牛，都是帶著問題去請教或探討。由于回答或探討問題無需太多的時間，更多的是靠經驗和積累，這類情況下大牛們都是很樂意的，畢竟影響力是大牛的1個重要指標嘛。但是也要特別注意：如果常常問那些書本或google能夠很容易查到的知識，大牛們也會很不耐煩的， 畢竟時間寶貴。常常有網友問我諸如“jvm的-Xmn參數如何配置”這類問題，我都是直接回答“請直接去google”，由于這樣的問題實在是太多了，如果自己不去系統學習，每一個都要問是非常浪費自己和他人的時間的。
??大牛不多，不太可能每一個團隊都有技術大牛，只能說團隊里面會有比你水平高的人，即便他每天給你開小灶，終究你也只能提升到他的水平；而如果是跨團隊的技術大牛，由于工作安排和分配的緣由，直接請教和輔導的機會是比較少的，單憑參加幾次大牛的培訓，是不太可能就成為技術大牛的。
??綜合上述的幾個緣由，我認為對大部份人來講，要想成為技術大牛，首先還是要明白“主要靠自己”這個道理，不要期望有個像武功師傅1樣的大牛手把手1步1步地教你。適當的時候可以通過請教大牛或和大牛探討來提升自己，但大部份時間還是自己系統性、有針對性地提升。

2、業務代碼1樣很牛逼

??知乎上有的回答認為寫業務代碼1樣可以很牛逼，理由是業務代碼1樣可以有各種技能，例如可使用封裝和抽象使得業務代碼更具可擴大性，可以通過和產品多交換以便更好地理解和實現業務，日志記錄好了問題定位效力可以提升10倍…..等等。
??業務代碼1樣有技術含量，這點是肯定的，業務代碼中的技術是每一個程序員的基礎，但只是掌握了這些技能，其實不能成為技術大牛，就像游戲中升級打怪1樣，開始打小怪，經驗值很高，越到后面經驗值越少，打小怪已不能提升經驗值了，這個時候就需要打1些更高級的怪，刷1些有挑戰的副本了，沒看到哪一個游戲 只要1直打小怪就可以升到頂級的。成為技術大牛的路也是類似的，你要不斷地提升自己的水平，然后面臨更大的挑戰，通過應對這些挑戰從而使自己水平更上1級， 然后如此往復，終究到達技術大牛乃至業界大牛的境地，寫業務代碼只是這個打怪升級路上的1個挑戰而已，而且我認為是比較低級的1個挑戰。
??所以我認為：業務代碼都寫不好的程序員肯定沒法成為技術大牛，但只把業務代碼寫好的程序員也還不能成為技術大牛。

3、上班太忙沒時間自己學習

??很多人認為自己沒有成為技術大牛其實不是自己不聰明，也不是自己不努力，而是中國的這個環境下，技術人員加班都太多了，致使自己沒有額外的時間進行學習。
??這個理由有1定的客觀性，畢竟和歐美相比，我們的加班確切要多1些，但這個因素只是1個需要克服的問題，其實不是不可逾越的鴻溝，畢竟我們身旁還是有那末多的大牛也是在中國這個環境成長起來的。
??我認為有幾個誤區致使了這類看法的構成：

• 1）上班做的都是重復工作，要想提升必須自己額外去學習構成這個誤區的主要緣由還是在于認為“寫業務代碼是沒有技術含量的”，而我現在上班就是寫業務代碼，所以我在工作中不能提升。
• 2）學習需要大段的連續時間很多人以為要學習就要像學校上課1樣，給你1整天時間來上課才算學習，而我們平時加班又比較多，周末累的只想睡懶覺，或只想去看看電影打打游戲來放松，所以就沒有時間學習了。

??實際上的做法正好相反：首先我們應當在工作中學習和提升，由于學以致用或有實例參考，學習的效果是最好的；其次工作后學習不需要大段時間，而是要擠出時間，利用時間碎片來學習。

正確的做法

1、Do more

??做的更多，做的比你主管安排給你的任務更多。
??我在HW的時候，負責1個版本的開發，這個版本的工作量大約是2000行左右，但是我除做完這個功能，還將關聯的功能全部掌握清楚了，代碼（大約 10000行）也全部看了1遍，做完這個版本后，我對這個版本相干的整套業務全部很熟習了。經過1兩次會議后，大家發現我對這塊掌握最熟了，接下來就有趣了：產品討論需求找我、測試有問題也找我、老大對外支持也找我；后來，不是我負責的功能他們也找我，即便我當時不知道，我也會看代碼或找文檔幫他們回答…..最后我就成了我這個系統的“專家”了。雖然這個時候我還是做業務的，還是寫業務代碼，但是我已對全部業務都很熟習了。
??以上只是1個簡單的例子，其實就是想說：要想有機會，首先你得從人群中冒出來，要想冒出來，你就必須做到與眾不同，要做到與眾不同，你就要做得更多！
??怎樣做得更多呢？可以從以下幾個方面著手：

• 1）熟習更多業務，不論是不是你負責的；熟習更多代碼，不論是不是你寫的。

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

• 需求分析的時候更加準確，能夠在需求階段就辨認風險、影響、難點；
• 問題處理的時候更加快速，由于相干的業務和代碼都熟習，能夠快速地判斷問題可能的緣由并進行排查處理；
• 方案設計的時候斟酌更加周全，由于有對全局業務的理解，能夠設計出更好的方案。

2）熟習端到端

??比如說你負責web后臺開發，但實際上用戶發起1個http要求，要經過很多中間步驟才到你的服務器（例如閱讀器緩存、DNS、nginx等），服務器1般又會經過很多處理才到你寫的那部份代碼（路由、權限等）這全部流程中的很多系統或步驟，絕大部份人是不可能去參與寫代碼的，但掌握了這些知識對你的綜合水平有很大作用，例如方案設計、線上故障處理這些更加有含金量的技術工作都需要綜合技術水平。
“系統性”、“全局性”、“綜合性”這些字眼看起來比較虛，但其實都是技術大牛的必備的素質，要到達這樣的境地，必須去熟習更多系統、業務、代碼。

3）自學

??1般在比較成熟的團隊，由于框架或組件已進行了大量的封裝，寫業務代碼所用到的技術確切也比較少，但我們要明白“唯1不變的只有變化”，框架有可能要改進，組件可能要替換，或你換了1家公司，新公司既沒有組件也沒有框架，要你從頭開始來做。這些都是機會，也是挑戰，而機會和挑戰只會分配給有準備的人，所以這類情況下我們更加需要自學更多東西，由于真正等到要用的時候再來學已沒有時間了。
??以java為例，大部份業務代碼就是if-else加個數據庫操作，但我們完全可以自己學些更多java的知識，例如垃圾回收，調優，網絡編程等，這些可能暫時沒用，但真要用的時候，不是google1下就能夠了，這個時候誰已掌握了相干知識和技能，機會就是誰的。
以垃圾回收為例，我自己平時就抽時間學習了這些知識，學了1年都沒用上，但后來用上了幾次，每次都解決了卡死的大問題，而有的同學，寫了幾年的java代碼，對stop-the-world是甚么概念都不知道，更不用說去優化了。

2、Do better

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

• 重復代碼太多，是不是可以引入設計模式？
• 系統性能1般，可否進行優化？
• 目前是單機，如果做成雙機是不是更好？
• 版本開發質量不高，是不是引入高效的單元測試和集成測試方案？
• 目前的系統太龐大，是不是可以通太重構和解耦改成3個系統？
• 阿里中間件有1些系統感覺我們也能夠用，是不是可以引入？

??……………………..
??只要你去想，其實總能發現可以改進的地方的。如果你覺得系統哪里都沒有改進的地方，那就說明你的水平還不夠，可以多學習相干技術，多看看業界其它公司怎樣做，BAT都怎樣做。
??我2013年調配到9游，剛開始接手了1個簡單的后臺系統，每天就是配合前臺做數據增刪改查，看起來完全沒意思，是吧？如果只做這些確切沒意思，但我們接手后做了很多事情：

• 解耦，將1個后臺拆分為2個后臺，提升可擴大性和穩定性；
• 雙機，將單機改成雙機系統，提高可靠性；
• 優化，將原來1個耗時5小時的接口優化為耗時5分鐘；

??還有其它很多優化，后來我們這個組承當了更多的系統，后來這個小組5個人，負責了6個系統。

3、Do exercise

??在做職業等級溝通的時候，發現有很多同學確切也在嘗試Do more、Do better，但在履行的進程中，幾近每一個人都遇到同1個問題：光看不用效果很差，怎樣辦？
??例如：
??學習了jvm的垃圾回收，但是線上比較少出現FGC致使的卡頓問題，就算出現了，恢復業務也是第1位的，不太可能線上出現問題然后讓每一個同學都去練1下手，那怎樣去實踐這些jvm的知識和技能呢？
??Netty我也看了，也了解了Reactor的原理，但是我不可能參與Netty開發，怎樣去讓自己真正掌握Reactor異步模式呢？
??看了《高性能MySQL》，但是線上的數據庫都是DBA管理的，測試環境的數據庫感覺又是隨意配置的，我怎樣去驗證這些技術呢？
框架封裝了DAL層，數據庫的訪問我們都不需要操心，我們怎樣去了解分庫分表實現？
……………………….
??諸如此類問題還有很多，我這里分享1下個人的經驗，其實就是3個詞：learning、trying、teaching！

1）Learning

??這個是第1階段，看書、google、看視頻、看他人的博客都可以，但要注意1點是“系統化”，特別是1些基礎性的東西，例如JVM原理、Java 編程、網絡編程，HTTP協議…..等等，這些基礎技術不能只通過google或博客學習，我的做法1般是先完全地看完1本書，有了全面的了解，然后再通過google、視頻、博客去有針對性地查找1些有疑問的地方，或1些技能。

2）Trying

??這個步驟就是解答前面提到的很多同學的疑惑的關鍵點，形象來講就是“自己動手豐衣足食”，也就是自己去嘗試搭建1些摹擬環境，自己寫1些測試程序。例如：
??Jvm垃圾回收：可以自己寫1個簡單的測試程序，分配內存不釋放，然后調劑各種jvm啟動參數，再運行的進程中使用jstack、jstat等命令查看jvm的堆內存散布和垃圾回收情況。這樣的程序寫起來很簡單，簡單1點的就幾行，復雜1點的也就幾10行。
??Reactor原理：自己真正去嘗試寫1個Reactor模式的Demo，不要以為這個很難，最簡單的Reactor模式代碼量（包括注釋）不超過200行（可以參考Doug Lee的PPT）。自己寫完后，再去看看netty怎樣做，1對照理解就更加深入了。
??MySQL：既然有線上的配置可以參考，那可以直接讓DBA將線上配置發給我們（注意去掉敏感信息），直接學習；然后自己搭建1個MySQL環境，用線上的配置啟動；要知道很多同學用了很多年MySQL，但是連個簡單的MySQL環境都搭不起來。
??框架封裝了DAL層：可以自己用JDBC嘗試去寫1個分庫分表的簡單實現，然后與框架的實現進行對照，看看差異在哪里。
用閱讀器的工具查看HTTP緩存實現，看看不同種類的網站，不同類型的資源，具體是如何控制緩存的；也能夠自己用Python寫1個簡單的HTTP服務器，摹擬返回各種HTTP Headers來視察閱讀器的反應。
………………………………
??還有很多方法，這里就不逐一羅列，簡單來講，就是要將學到的東西真正試試，才能理解更加深入，印第安人有1句諺語：I hear and I forget. I see and I remember. I do and I understand，而且“試試”其實可以比較簡單，很多時候我們都可以自己動手做。
??固然，如果能夠在實際工作中使用，效果會更好，畢竟實際的線上環境和業務復雜度不是我們寫個摹擬程序就可以夠摹擬的，但這樣的機會可遇不可求，大部份情況我們還真的只能靠自己摹擬，然后等到真正業務要用的時候，能夠信手拈來。

3）Teaching

??1般來講，經過Learning和Trying，能掌握70%左右，但要真正掌握，我覺得1定要做到能夠跟他人講清楚。由于在講的時候，我們既需要將1個知識點系統化，也需要斟酌各種細節，這會促使我們進1步思考和學習。同時，講出來后看或聽的人可以有不同的理解，或有新的補充，這相當于繼續完善了全部知識技能體系。
??這樣的例子很多，包括我自己寫博客的時候常常遇到，本來我覺得自己已掌握很全面了，但1寫就發現很多點沒斟酌到；組內培訓的時候也常常看到，有的同學寫了PPT，但是講的時候，大家1問，或1討論，就會發現很多點還沒有講清楚，或有的點實際上是理解錯了。寫PPT、講PPT、討論PPT，這個流程全部走1遍，基本上對1個知識點掌握就比較全面了。

后記

??成為技術大牛夢想雖然很美好，但是要付出很多，不論是Do more還是Do better還是Do exercise，都需要花費時間和精力，這個進程中可能很苦逼，也可能很枯燥，這里我想特別強調1下：前面我講的都是1些方法論的東西，但真正起決定作用的，其實還是我們對技術的熱忱和興趣！