程序猿-技術成長-理論方法-實踐指導

 

寫在前面

 

無論是開發、測試、運維，每一個技術人員內心多多少少都有一個成爲技術大牛的夢，畢竟「夢想老是要有的，萬一實現了呢」！正是對技術夢的追求，促使咱們不斷地努力和提高本身。

然而「夢想是美好的，現實倒是殘酷的」，不少同窗在實際工做後就會發現，夢想是成爲大牛，但作的事情看起來跟大牛都不沾邊，例如，程序員說「每天寫業務代碼還加班，如何才能成爲技術大牛」，測試說「天天都有執行不完的測試用例」，運維說「扛機器接網線敲shell命令，這不是我想要的運維人生」。

我也是一位程序員，因此我但願經過如下基於程序開發的一些例子，幫助你們解決這些困惑。大道理是相通的，測試、運維均可以借鑑。 

 

幾個典型的誤區

 

拜大牛爲師

 

有人認爲想成爲技術大牛最簡單直接、快速有效的方式是「拜團隊技術大牛爲師」，讓他們平時給你開小竈，給你分配一些有難度的任務。 

 

我我的是反對這種方法的，主要的緣由有幾個：

 

• 大牛很忙，不太可能單獨給你開小竈，更不可能天天都給你開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個系統？

阿里中間件有一些系統感受咱們也能夠用，是否能夠引入 ？

 

只要你去想，其實總能發現能夠改進的地方的；若是你以爲系統哪裏都沒有改進的地方，那就說明你的水平還不夠，能夠多學習相關技術，多看看業界其它優秀公司怎麼作。

 

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