Java程序員成長之路（二）

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，這個流程所有走一遍，基本上對一個知識點掌握就比較全面了。

-------------------------------------------------------------------------------------------------

我一直認爲比較抽象的問題（像這個問題），沒有完美的解法，其餘任何人的經驗你都有參考價值，但落到實處又必然因人而異。對待這類建議型回答，我以爲若是你迷茫，能夠採起一個問題下高票回答的建議；若是你只是有點困惑，那就多看看別人怎麼建議的，挑選你認爲有用的部分；最重要得，是你本身的思考。

來聊聊對於java初級程序員，提高自我價值的幾個我認爲的最佳實踐。

1 多深刻了解一點

面試應屆生，新人程序員時我喜歡問這麼一個問題：你怎麼理解HashMap？一個看似簡單的問題能夠看出衆生百態。第一類人回答道，這是個鍵值對的結構。下面的補充頗有意思，懂數據結構會繼續補充hash這個數據結構，說一說Hash衝突，懂Java HashMap實現的人，會聊一聊hashCode，equals方法對於其的意義。再往下，能夠聊一聊HashMap在1.8中的優化，橫向對比TreeMap，ConcurrentHashMap，縱向對比LinkedHashMap，這樣能夠從全局把握對HashMap的理解。

爲何說這個例子，就是想表達這樣的觀點：一樣一個問題，不一樣經驗的人理解的深度不同。項目中遇到問題，嘗試剖析問題，深刻理解問題，不只僅是解決了這一次的問題，也杜絕了之後問題的出現。一個簡單的需求，誰均可以完成，那可替代性就很強；一個比較複雜的需求，只有交給你領導才放心，那麼這就是你的價值。靠什麼來支撐，就是你須要比其餘人瞭解的更多。

 

2 保持持續的熱情

我見過的比較厲害的程序員，他們老是保持持續的熱情。在J2EE早期學習Spring，大數據時代又開始學習Hadoop,Storm，微服務時代熱衷於dubbo,springcloud，雲時代開始搞Docker,k8s。

興趣驅動的程序員老是比普通的程序員成長的更快，多看書，多關注一些大牛的博客，多關注開源，遇到問題多搜索。但願你即便是暫時的一腔熱血，也能多燒一下子。

3 多交流

程序員的眼界很重要，在學生時代，我還只知道百度、CSDN，覺得那就是世界，直到後來知道了谷歌、Github、StackOverflow，世界的邊界開始變大，知道再後來，接觸到了不少其餘有意思的程序員，公衆號，參加一些交流會，一些線下沙龍，遇到一批一樣熱衷於技術的人，才知道，原來程序員的圈子能夠這麼廣。多交流，這方便你知道本身的定位。

 

4 程序員的價值不是技術框架的堆砌

不少腦殼瓜比較聰明的新人程序員常常着迷於各類框架，開源技術的探索，一般表現爲，經理要求開發一個全文搜索需求，他能夠提出es，luncene，solr多種解決方案；說到微服務就能夠和別人大談特談dubbo，springcloud；說到分佈式事務也能夠聊一聊2pc...這本是一件好事，可是大多數此類人，只是對框架和技術有了基礎的認識，可能他們所「瞭解」的技術，有經驗的程序員看一兩篇博客就能掌握如何使用了，但新人程序員卻陷入了一個怪圈，他們鄙視寫業務代碼，不重視軟件思想，只看重技術框架，而後自我感受良好，這可怕又惋惜。