你是否有類似這樣的問題——“天天寫業(yè)務(wù)代碼的程序員，怎么成為技術(shù)大牛，開始寫技術(shù)代碼？”

[[224547]]

阿里資深無線開發(fā)專家李運華，系統(tǒng)梳理了自己的思考和理解，希望幫助更多同學(xué)少走一些彎路。

不管是開發(fā)、測試、運維，每個技術(shù)人員心里多多少少都有一個成為技術(shù)大牛的夢，畢竟“夢想總是要有的，萬一實現(xiàn)了呢”！正是對技術(shù)夢的追求，促使我們不斷地努力和提升自己。

然而“夢想是美好的，現(xiàn)實卻是殘酷的”，很多同學(xué)在實際工作后就會發(fā)現(xiàn)，夢想是成為大牛，但做的事情看起來跟大牛都不沾邊。

例如，程序員說“天天寫業(yè)務(wù)代碼還加班，如何才能成為技術(shù)大牛”，測試說“每天都有執(zhí)行不完的測試用例”，運維說“扛機器接網(wǎng)線敲 Shell 命令，這不是我想要的運維人生”。

我也是一位程序員，所以我希望通過以下基于程序開發(fā)的一些例子，幫助大家解決這些困惑。大道理是相通的，測試、運維都可以借鑒。 

幾個典型的誤區(qū)

拜大牛為師

有人認為想成為技術(shù)大牛最簡單直接、快速有效的方式是“拜團隊技術(shù)大牛為師”，讓他們平時給你開小灶，給你分配一些有難度的任務(wù)。 

我個人是反對這種方法的，主要的原因有幾個：

• 大牛很忙，不太可能單獨給你開小灶，更不可能每天都給你開 1 個小時的小灶。

而且一個團隊里面，如果大牛平時經(jīng)常給你開小灶，難免會引起其他團隊成員的疑惑，我個人認為如果團隊里的大牛真正有心的話，多給團隊培訓(xùn)是最好的。

然而做過培訓(xùn)的都知道，準(zhǔn)備一場培訓(xùn)是很耗費時間的，課件和材料至少 2 個小時（還不能是碎片時間），講解 1 個小時，大牛們一個月做一次培訓(xùn)已經(jīng)是很高頻了。

• 因為第一個原因，所以一般要找大牛，都是帶著問題去請教或者探討。因為回答或者探討問題無需太多的時間，更多的是靠經(jīng)驗和積累，這種情況下大牛們都是很樂意的，畢竟影響力是大牛的一個重要指標(biāo)嘛。

然而也要特別注意：如果經(jīng)常問那些書本或者 Google 能夠很容易查到的知識，大牛們也會很不耐煩的，畢竟時間寶貴。

經(jīng)常有網(wǎng)友問我諸如“jvm 的 -Xmn 參數(shù)如何配置”這類問題，我都是直接回答“請直接去 Google”，因為這樣的問題實在是太多了，如果自己不去系統(tǒng)學(xué)習(xí)，每個都要問是非常浪費自己和別人的時間的。

• 大牛不多，不太可能每個團隊都有技術(shù)大牛，只能說團隊里面會有比你水平高的人，即使他每天給你開小灶，最終你也只能提升到他的水平。

而如果是跨團隊的技術(shù)大牛，由于工作安排和分配的原因，直接請教和輔導(dǎo)的機會是比較少的，單憑參加幾次大牛的培訓(xùn)，是不太可能成為技術(shù)大牛的。 

綜合上述的幾個原因，我認為對于大部分人來說，要想成為技術(shù)大牛，首先還是要明白“主要靠自己”這個道理，不要期望有個像武功師傅一樣的大牛手把手一步一步地教你。

適當(dāng)?shù)臅r候可以通過請教大?；蛘吆痛笈Ｌ接憗硖嵘约海蟛糠謺r間還是自己系統(tǒng)性、有針對性的提升。

業(yè)務(wù)代碼一樣很牛逼

有人認為寫業(yè)務(wù)代碼一樣可以很牛逼，理由是業(yè)務(wù)代碼一樣可以有各種技巧。

例如可以使用封裝和抽象使得業(yè)務(wù)代碼更具可擴展性，可以通過和產(chǎn)品多交流以便更好的理解和實現(xiàn)業(yè)務(wù)，日志記錄好了問題定位效率可以提升10倍等等。 

業(yè)務(wù)代碼一樣有技術(shù)含量，這點是肯定的，業(yè)務(wù)代碼中的技術(shù)是每個程序員的基礎(chǔ)，但只是掌握了這些技巧，并不能成為技術(shù)大牛。

就像游戲中升級打怪一樣，開始打小怪，經(jīng)驗值很高，越到后面經(jīng)驗值越少，打小怪已經(jīng)不能提升經(jīng)驗值了，這個時候就需要打一些更高級的怪，刷一些有挑戰(zhàn)的副本了，沒看到哪個游戲只要一直打小怪就能升到頂級的。

成為技術(shù)大牛的路也是類似的，你要不斷的提升自己的水平，然后面臨更大的挑戰(zhàn)，通過應(yīng)對這些挑戰(zhàn)從而使自己水平更上一級，然后如此往復(fù)，最終達到技術(shù)大牛甚至業(yè)界大牛的境界。

寫業(yè)務(wù)代碼只是這個打怪升級路上的一個挑戰(zhàn)而已，而且我認為是比較初級的一個挑戰(zhàn)。 

所以我認為：業(yè)務(wù)代碼都寫不好的程序員肯定無法成為技術(shù)大牛，但只把業(yè)務(wù)代碼寫好的程序員也還不能成為技術(shù)大牛。

上班太忙沒時間自己學(xué)習(xí)

很多人認為自己沒有成為技術(shù)大牛并不是自己不聰明，也不是自己不努力，而是在中國的這個環(huán)境下，技術(shù)人員加班都太多了，導(dǎo)致自己沒有額外的時間進行學(xué)習(xí)。 

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

我認為有幾個誤區(qū)導(dǎo)致了這種看法的形成：

• 上班做的都是重復(fù)工作，要想提升必須自己額外去學(xué)習(xí)。形成這個誤區(qū)的主要原因還是在于認為“寫業(yè)務(wù)代碼是沒有技術(shù)含量的”，而我現(xiàn)在上班就是寫業(yè)務(wù)代碼，所以我在工作中不能提升。
• 學(xué)習(xí)需要大段的連續(xù)時間。很多人以為要學(xué)習(xí)就要像學(xué)校上課一樣，給你一整天時間來上課才算學(xué)習(xí)，而我們平時加班又比較多，周末累的只想睡懶覺，或者只想去看看電影打打游戲來放松，所以就沒有時間學(xué)習(xí)了。 

實際上的做法正好相反：首先我們應(yīng)該在工作中學(xué)習(xí)和提升，因為學(xué)以致用或者有實例參考，學(xué)習(xí)的效果是最好的；其次工作后學(xué)習(xí)不需要大段時間，而是要擠出時間，利用時間碎片來學(xué)習(xí)。

[[224548]]

正確的做法

Do more

做的更多，做的比你主管安排給你的任務(wù)更多。 

我在 HW 的時候，負責(zé)一個版本的開發(fā)，這個版本的工作量大約是 2000 行左右。

但是我除了做完這個功能，還將關(guān)聯(lián)的功能全部掌握清楚了，代碼（大約 10000 行）也全部看了一遍，做完這個版本后，我對這個版本相關(guān)的整套業(yè)務(wù)全部很熟悉了。

經(jīng)過一兩次會議后，大家發(fā)現(xiàn)我對這塊掌握最熟了，接下來就有趣了：產(chǎn)品討論需求找我、測試有問題也找我、老大對外支撐也找我。

后來，不是我負責(zé)的功能他們也找我，即使我當(dāng)時不知道，我也會看代碼或者找文檔幫他們回答。

最后我就成了我這個系統(tǒng)的“專家”了。雖然這個時候我還是做業(yè)務(wù)的，還是寫業(yè)務(wù)代碼，但是我已經(jīng)對整個業(yè)務(wù)都很熟悉了。 

以上只是一個簡單的例子，其實就是想說：要想有機會，首先你得從人群中冒出來，要想冒出來，你就必須做到與眾不同，要做到與眾不同，你就要做得更多！ 

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

熟悉更多業(yè)務(wù)

不管是不是你負責(zé)的，熟悉更多代碼，不管是不是你寫的，這樣做有很多好處。

舉幾個簡單的例子：

• 需求分析的時候更加準(zhǔn)確，能夠在需求階段就識別風(fēng)險、影響、難點。
• 問題處理的時候更加快速，因為相關(guān)的業(yè)務(wù)和代碼都熟悉，能夠快速的判斷問題可能的原因并進行排查處理。
• 方案設(shè)計的時候考慮更加周全，由于有對全局業(yè)務(wù)的理解，能夠設(shè)計出更好的方案。

熟悉端到端

比如說你負責(zé) Web 后臺開發(fā)，但實際上用戶發(fā)起一個 HTTP 請求，要經(jīng)過很多中間步驟才到你的服務(wù)器（例如瀏覽器緩存、DNS、Nginx 等）。

服務(wù)器一般又會經(jīng)過很多處理才到你寫的那部分代碼（路由、權(quán)限等），這整個流程中的很多系統(tǒng)或者步驟，絕大部分人是不可能去參與寫代碼的。

但掌握了這些知識對你的綜合水平有很大作用，例如方案設(shè)計、線上故障處理這些更加有含金量的技術(shù)工作都需要綜合技術(shù)水平。 

“系統(tǒng)性”、“全局性”、“綜合性”這些字眼看起來比較虛，但都是技術(shù)大牛必備的素質(zhì)，要達到這樣的境界，必須去熟悉更多系統(tǒng)、業(yè)務(wù)、代碼。 

自學(xué)

一般在比較成熟的團隊，由于框架或者組件已經(jīng)進行了大量的封裝，寫業(yè)務(wù)代碼所用到的技術(shù)確實也比較少。

但我們要明白“唯一不變的只有變化”，框架有可能要改進，組件可能要替換，或者你換了一家公司，新公司既沒有組件也沒有框架，要你從頭開始來做。

這些都是機會，也是挑戰(zhàn)，而機會和挑戰(zhàn)只會分配給有準(zhǔn)備的人，所以這種情況下我們更加需要自學(xué)更多東西，因為真正等到要用的時候再來學(xué)已經(jīng)沒有時間了。 

以 Java 為例，大部分業(yè)務(wù)代碼就是 if-else 加個數(shù)據(jù)庫操作，但我們完全可以自己學(xué)些更多 Java 的知識。

例如垃圾回收，調(diào)優(yōu)，網(wǎng)絡(luò)編程等，這些可能暫時沒用，但真要用的時候，不是 Google 一下就可以了，這個時候誰已經(jīng)掌握了相關(guān)知識和技能，機會就是誰的。

以垃圾回收為例，我自己平時就抽時間學(xué)習(xí)了這些知識，學(xué)了 1 年都沒用上，但后來用上了幾次，每次都解決了卡死的大問題。

而有的同學(xué)，寫了幾年的 Java 代碼，對于 stop-the-world 是什么概念都不知道，更不用說去優(yōu)化了。

Do better

要知道這個世界上沒有完美的東西，你負責(zé)的系統(tǒng)和業(yè)務(wù)，總有不合理和可以改進的地方，這些“不合理”和“可改進”的地方，都是更高級別的怪物，打完后能夠增加更多的經(jīng)驗值。

識別出這些地方，并且給出解決方案，然后向主管提出，一次不行兩次，多提幾次，只要有一次落地了，這就是你的機會。

例如：

• 重復(fù)代碼太多，是否可以引入設(shè)計模式？
• 系統(tǒng)性能一般，可否進行優(yōu)化？
• 目前是單機，如果做成雙機是否更好？
• 版本開發(fā)質(zhì)量不高，是否引入高效的單元測試和集成測試方案？
• 目前的系統(tǒng)太龐大，是否可以通過重構(gòu)和解耦改為 3 個系統(tǒng)？
• 阿里中間件有一些系統(tǒng)感覺我們也可以用，是否可以引入 ？

只要你去想，總能發(fā)現(xiàn)可以改進的地方的；如果你覺得系統(tǒng)哪里都沒有改進的地方，那就說明你的水平還不夠，可以多學(xué)習(xí)相關(guān)技術(shù)，多看看業(yè)界其他優(yōu)秀公司怎么做。

我 2013 年調(diào)配到九游，剛開始接手了一個簡單的后臺系統(tǒng)，每天就是配合前臺做數(shù)據(jù)增刪改查，看起來完全沒意思，是吧？

如果只做這些確實沒意思，但我們接手后做了很多事情：

• 解耦，將一個后臺拆分為 2 個后臺，提升可擴展性和穩(wěn)定性。
• 雙機，將單機改為雙機系統(tǒng)，提高可靠性。
• 優(yōu)化，將原來一個耗時 5 小時的接口優(yōu)化為耗時 5 分鐘。

還有其他很多優(yōu)化，后來我們這個組承擔(dān)了更多的系統(tǒng)，也就是這個小組 5 個人，負責(zé)了 6 個系統(tǒng)。

Do exercise

在做職業(yè)等級溝通的時候，發(fā)現(xiàn)有很多同學(xué)確實也在嘗試 Do more、Do better，但在執(zhí)行的過程中，幾乎每個人都遇到同一個問題：光看不用效果很差，怎么辦？ 

例如：

• 學(xué)習(xí)了 Jvm 的垃圾回收，但是線上比較少出現(xiàn) FGC 導(dǎo)致的卡頓問題，就算出現(xiàn)了，恢復(fù)業(yè)務(wù)也是第一位的，不太可能線上出現(xiàn)問題然后讓每位同學(xué)都去練一下手，那怎么去實踐這些 Jvm 的知識和技能呢？
• Netty 我也看了，也了解了 Reactor 的原理，但是我不可能參與 Netty 開發(fā)，怎么去讓自己真正掌握 Reactor 異步模式呢？
• 看了《高性能MySQL》，但是線上的數(shù)據(jù)庫都是 DBA 管理的，測試環(huán)境的數(shù)據(jù)庫感覺又是隨便配置的，我怎么去驗證這些技術(shù)呢？
• 框架封裝了 DAL 層，數(shù)據(jù)庫的訪問我們都不需要操心，我們怎么去了解分庫分表實現(xiàn)？

諸如此類問題還有很多，我這里分享一下個人的經(jīng)驗，其實就是 3 個詞：learning、trying、teaching！

Learning

這個是第一階段，看書、Google、看視頻、看別人的博客都可以，但要注意一點是“系統(tǒng)化”，特別是一些基礎(chǔ)性的東西，例如 Jvm 原理、Java 編程、網(wǎng)絡(luò)編程，HTTP 協(xié)議等等。

這些基礎(chǔ)技術(shù)不能只通過 Google 或者博客學(xué)習(xí)，我的做法一般是先完整的看完一本書全面的了解，然后再通過 Google、視頻、博客去有針對性的查找一些有疑問的地方，或者一些技巧。

Trying

這個步驟就是解答前面提到的很多同學(xué)的疑惑的關(guān)鍵點，形象來說就是“自己動手豐衣足食”，也就是自己去嘗試搭建一些模擬環(huán)境，自己寫一些測試程序。

例如：

• Jvm 垃圾回收：可以自己寫一個簡單的測試程序，分配內(nèi)存不釋放，然后調(diào)整各種 jvm 啟動參數(shù)，再運行的過程中使用 jstack、jstat 等命令查看 jvm 的堆內(nèi)存分布和垃圾回收情況。這樣的程序?qū)懫饋砗芎唵危唵我稽c的就幾行，復(fù)雜一點的也就幾十行。
• Reactor 原理：自己真正去嘗試寫一個 Reactor 模式的 Demo，不要以為這個很難，最簡單的 Reactor 模式代碼量（包括注釋）不超過 200 行（可以參考 Doug Lee 的 PPT）。自己寫完后，再去看看 Netty 怎么做，一對比理解就更加深刻了。
• MySQL：既然有線上的配置可以參考，那可以直接讓 DBA 將線上配置發(fā)給我們（注意去掉敏感信息），直接學(xué)習(xí)。

然后自己搭建一個 MySQL 環(huán)境，用線上的配置啟動；要知道很多同學(xué)用了很多年 MySQL，但是連個簡單的 MySQL 環(huán)境都搭不起來。

• 框架封裝了 DAL 層：可以自己用 JDBC 嘗試去寫一個分庫分表的簡單實現(xiàn)，然后與框架的實現(xiàn)進行對比，看看差異在哪里。
• 用瀏覽器的工具查看 HTTP 緩存實現(xiàn)，看看不同種類的網(wǎng)站，不同類型的資源，具體是如何控制緩存的。

也可以自己用 Python 寫一個簡單的 HTTP 服務(wù)器，模擬返回各種 HTTP Headers 來觀察瀏覽器的反應(yīng)。

還有很多方法，這里就不一一列舉，簡單來說，就是要將學(xué)到的東西真正試試，才能理解更加深刻。

印第安人有一句諺語：I hear and I forget. I see and I remember. I do and I understand ，而且“試試”可以比較簡單，很多時候我們都可以自己動手做。 

當(dāng)然，如果能夠在實際工作中使用，效果會更好，畢竟實際的線上環(huán)境和業(yè)務(wù)復(fù)雜度不是我們寫個模擬程序就能夠模擬的。

但這樣的機會可遇不可求，大部分情況我們還真的只能靠自己模擬，然后等到真正業(yè)務(wù)要用的時候，能夠信手拈來。

Teaching

一般來說，經(jīng)過 Learning 和 Trying，能掌握 70% 左右，但要真正掌握，我覺得一定要做到能夠跟別人講清楚。

因為在講的時候，我們既需要將一個知識點系統(tǒng)化，也需要考慮各種細節(jié)，這會促使我們進一步思考和學(xué)習(xí)。

同時，講出來后看或者聽的人可以有不同的理解，或者有新的補充，這相當(dāng)于繼續(xù)完善了整個知識技能體系。 

這樣的例子很多，包括我自己寫博客的時候經(jīng)常遇到，本來我覺得自己已經(jīng)掌握很全面了，但一寫就發(fā)現(xiàn)很多點沒考慮到。

組內(nèi)培訓(xùn)的時候也經(jīng)?？吹?，有的同學(xué)寫了 PPT，但是講的時候，大家一問，或者一討論，就會發(fā)現(xiàn)很多點還沒有講清楚，或者有的點其實是理解錯了。

寫 PPT、講 PPT、討論 PPT，這個流程全部走一遍，基本上對一個知識點掌握就比較全面了。 

后記

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

這里我想特別強調(diào)一下：前面我講的都是一些方法論的東西，但真正起決定作用的，其實還是我們對技術(shù)的熱情和興趣！