程序員的30歲現象
在官場上，曾經有一個59歲現象，就是官員們會在59歲時，會使勁撈上一把。很明顯嘛，權力過期作廢，再不撈就要退休了，沒有機會了。
在程序員的圈子裡，也有一個30歲現象。程序員幹到30歲，好不容易從碼奴混到了白領，卻再也幹不動了，還時時面臨失業的危險。30歲，是一個程序員傷不起的年齡。明天，何去何從？當然，如果你有鐵飯碗，比如在國企或政府機關，那你是無法理解底層勞動人民的感受的。同時也要恭喜你成為體制內的一員，可以一直幹到退休無憂。
30歲現象人人都明白，但要給出一個定義並不容易。列舉幾個表現，也許你會覺得心有慼慼焉。
面臨職業瓶頸，程序寫不動，上升又困難。
薪水較高，加班變少，後浪追前浪，面臨失業壓力；生活壓力劇增，不敢跳槽；
招聘程序員年齡限制在30歲以下成為行業潛規則，跳槽困難。
30 歲現象和59歲現象貌似不搭邊，其實都出於同樣的原因：價值貶值。官員老爺在任就像皇帝，一旦退休，就成為了平民百姓，貶值那是自然的。而程序員也一樣， 所謂三十而立，一旦到了30歲左右，由於面臨結婚生子，一方面需要高薪撫養家庭，另一方面卻無法像以前那樣全身心投入到工作，性價比急劇下降；與此同時， 大批廉價的新手湧入，他們往往還使用最新的技術，老一輩程序員只能慢慢的靠邊站了。
是否有不可替代性
30歲現象產生，只能程序員自身身上找原因。
當然我們也可以產業、從社會、從政府、從制度等多方面進行分析，發現不足，這些分析未必沒有道理，但是肯定沒有用，因為我們無法改變。所謂“命苦不能怪政府，命背不能怪社會”，從外部找原因，只會讓我們滿腹牢騷，整天覺得自己生不逢時，苦悶不堪。
從自身找原因，試著問自己幾個問題：“為什麼我的性價比以下降？老闆為什麼要請我，給我高工資呢？一個人有價值是由什麼決定的呢？”
你也許可以列出很長很長的答案，但我想應該都可以濃縮為一句話：“一個的價值是由他的不可替代性決定的”。不可替代性可以理解為，為了替代你老闆需要付出的代價。
因為你的可替代性高，所以性價比下降。反之，因為你不可替代性高，所以老闆會給你開高工資。不是這樣的嗎？
有一則小故事：
技師退休時告誡自己的徒弟：“少說話，多做事。”
十年後徒弟也成了技師，他找到師傅，苦著臉說：“師傅，我一直都按您的教導做，只知埋頭苦幹，可那些比我技術差的都升職了、加薪了，我還是拿著過去的工資。”
師傅想了想，說：“你請一次假吧。如果一盞燈一直亮著，那就沒人會注意到它……”
徒弟恍然大悟，真的請了一星期假，等他回去上班時，廠長找到他說要給他加薪。原來，在他請假時，廠長發現，工廠已經離不開他了。
徒弟很高興，以後他時不時就請幾天假，每次請假後廠長都會給他加薪。一天徒弟請假後準備去上班，廠長卻告訴他：“你不用來上班了。”
徒弟苦惱地去找師傅，師傅說：“那天我的話還沒說完呢。一盞燈偶爾可以熄滅一次，可如果它總是熄滅，性質就不一樣了，因為沒人會需要一盞時亮時熄的燈。”
故事中，因為徒弟的不可替代，所以廠長給他加薪；後來因為有其它的燈亮了，他被替代了，廠長不需要他了，所以被炒了魷魚。
所以我們歸根到底還是要提高自己的不可替代性。否則，一旦老闆覺得用較低的代價就可以替代你，那麼你就面臨可能失業的危險了。
出路在哪裡
那程序員到了30歲，怎樣提高自己的不可替代性呢？我們打算做一輩子程序員嗎？敢問路在何方？
作為一個過來人、一個資深程序員，我覺得有幾個方向可以選擇：
（1）成為技術大拿
其實，做一輩子程序員並沒有什麼問題，重要的是，你必須成為一個不可替代的程序員，也就是說，你要成為技術大拿，能夠解決普通程序員所不能解決的問題。技術大拿有兩個版本：
一 是程序員加強版。你仍然是一個程序員，但你是一個很牛的程序員，憑藉多年的積累，你在知識廣度和深度方面均已不是等閒之輩。從彙編到java，你樣樣精 通。你在意數據結構和算法，對系統的優化有獨到見解，對設計模式如 數家珍，你還有完備的工具箱和自己的專用類庫。其實，加強版程序員有非常獨特的價值，可惜的是，在現實中卻很少見，因為對任何一個公司而言，人才總是很稀缺的。老闆的眼睛是雪亮的，他怎麼會對你這種技術大牛視而不見呢，在你還沒有成為真正的 大拿之前，早已經被任命為系統架構師、項目經理或者更高的職位了。因此，你想守住自己的一畝三分地，悠閒的做自己的大拿，往往是不可能的。
二 是程序員升級版。雖然你的內在仍然是一個程序員，但你的職位已經升級了，你成為了系統分析師或系統架構師。這是非常自然和現實的選擇。程序員與系統分析師或架構師之間並有鴻溝，只需一步而已，你就可以從崎嶇山路駛向寬闊的大馬路。但這一步卻並不容易，需要幾年時間不斷思考、學習、實踐，才能化蛹成蝶。
（2）成為行業專家
行業專家也是一個公司不可缺少的角色，他們對公司的行業知識、業務流程和細節瞭如指掌。行業專家一般並不是從外部招聘的一個只懂業務、不懂技術的超人，而往 往是從程序員經過多年的摸爬滾打成長起來的。作為從程序員成長起來的行業專家，你往往還肩負系統分析師之職。在公司裡，對業務有一般瞭解的人很多， 但專 家級別的往往很少，為了後30年的職業生涯，你必須成為專家。
（3）朝管理方向發展
向管理方向發展的第一步，一般是被任命為項目經理。在大部分IT公司裡， 項目經理是最小的管理崗位了，可能你不會覺得有太多驚喜，工資也沒有大的提升，但這個轉變，可以說會成為你一生中最重要的轉變之一。
不 要小看了項目經理。有人說，項目經理是一個古老的職業。也人有人說，21世紀是項目管理的世紀。事實上，從人類有組織以來，就一直有項目管理，以前的項目 經理可能是部落首領，一次集體打獵、一次攻城拔寨，都可以視為一個項目。項目管理的知識可以應用到我們生活的方方面面，大至登月計劃的實施，小至家庭聚會 的組織，都離不開項目管理。
一個優秀的項目經理，不僅需要高智商，還需要高情商。可以不誇張的說，如果你能勝任項目管理，你就可以勝任戰術層的所有管理崗位，甚至你有家庭生活質量，也會提高到新層次。
然而，要成為一名優秀的項目經理，並不是一件容易的事情。可以說，需要一定的天分，有些人無師自通，有些人卻永遠也學不會。程序員屬於高智商人群，情商卻往往存在不足，這注定了只有少數程序員能夠成長為項目經理，成為優秀的項目經理，則非常稀少了。
如何讓自己成為大牛
那麼知道了即將面臨的危機，也知道了出路，如何去完成呢？怎麼樣成為技術大牛？
這裡有幾個認知上的誤區：
拜大牛為師
知乎上有人認為想成為技術大牛最簡單直接、快速有效的方式是“拜團隊技術大牛為師”，讓他們平時給你開小灶，給你分配一些有難度的任務。我個人是反對這種方法的，主要的原因有幾個：
大牛很忙，不太可能單獨給你開小灶，更不可能每天都給你開1個小時的小灶；而且一個團隊裡面，如果大牛平時經常給你開小灶，難免會引起其他團隊成員的疑惑，我個人認為如果團隊裡的大牛如果真正有心的話，多給團隊培訓是最好的。然而做過培訓的都知道，準備一場培訓是很耗費時間的，課件和材料至少2個小時（還不能是碎片時間），講解1個小時，大牛們一個月做一次培訓已經是很高頻了。
因為第一個原因，所以一般要找大牛，都是帶著問題去請教或者探討。因為回答或者探討問題無需太多的時間，更多的是靠經驗和積累，這種情況下大牛們都是很樂意的，畢竟影響力是大牛的一個重要指標嘛。然而也要特別注意：如果經常問那些書本或者google能夠很容易查到的知識，大牛們也會很不耐煩的，畢竟時間寶貴。經常有網友問我諸如“jvm的-Xmn參數如何配置”這類問題，我都是直接回答“請直接去google”，因為這樣的問題實在是太多了，如果自己不去系統學習，每個都要問是非常浪費自己和別人的時間的。而且大牛不多，不太可能每個團隊都有技術大牛，只能說團隊裡面會有比你水平高的人，即使他每天給你開小灶，最終你也只能提升到他的水平。
業務代碼一樣很牛逼
知乎上有的回答認為寫業務代碼一樣可以很牛逼，理由是業務代碼一樣可以有各種技巧，例如可以使用封裝和抽象使得業務代碼更具可擴展性，可以通過和產品多交流以便更好的理解和實現業務，日誌記錄好了問題定位效率可以提升10倍……等等。
業務代碼一樣有技術含量，這點是肯定的，業務代碼中的技術是每個程序員的基礎，但只是掌握了這些技巧，並不能成為技術大牛，就像遊戲中升級打怪一樣，開始打小怪，經驗值很高，越到後面經驗值越少，打小怪已經不能提升經驗值了，這個時候就需要打一些更高級的怪，刷一些有挑戰的副本了，沒看到哪個遊戲只要一直打小怪就能升到頂級的。
成為技術大牛的路也是類似的，你要不斷的提升自己的水平，然後面臨更大的挑戰，通過應對這些挑戰從而使自己水平更上一級，然後如此往復，最終達到技術大牛甚至業界大牛的境界，寫業務代碼只是這個打怪升級路上的一個挑戰而已，而且我認為是比較初級的一個挑戰。
所以我認為：業務代碼都寫不好的程序員肯定無法成為技術大牛，但只把業務代碼寫好的程序員也還不能成為技術大牛。
上班太忙沒時間自己學習
很多人認為自己沒有成為技術大牛並不是自己不聰明，也不是自己不努力，而是中國的這個環境下，技術人員加班都太多了，導致自己沒有額外的時間進行學習。
這個理由有一定的客觀性，畢竟和歐美相比，我們的加班確實要多一些，但這個因素只是一個需要克服的問題，並不是不可逾越的鴻溝，畢竟我們身邊還是有那麼多的大牛也是在中國這個環境成長起來的。
對於這種回答也是真的不知道該如何回答了，那些比你厲害的人難道不用上班？每天就很閒？
項目怎麼又延期，你說“沒有時間”；
怎麼不學習英語，你說“沒有時間”；
一起去操場跑步，你說“沒有時間”那你的時間都花在哪裡去了？你的收穫是什麼？
我只能說不要用你身體的勤奮，掩蓋你精神的懶惰，剛看完一本書，名字叫作：“《哪有沒時間這回事》”
你總是很忙，但是你忙來忙去的一點收穫也沒有，或者說忙的沒有效率，為什麼不想想自己的時間都忙去哪了？知道自己有很多的地方做的不好，但是總是不能抓住一個去改正？這本書，給了一個很重要的提示，也是時間管理過程中我們容易忽略的一個重要的點，那就是——早睡早起。
分享我的經驗
作為一名java程序員如何成為大牛、架構師呢？
一、源碼分析
源碼分析是一種臨界知識，掌握了這種臨界知識，能不變應萬變，源碼分析對於很多人來說很枯燥，生澀難懂。
源碼閱讀，我覺得最核心有三點：技術基礎+強烈的求知慾+耐心。
我認為是閱讀源碼的最核心驅動力。我見到絕大多數程序員，對學習的態度，基本上就是這幾個層次(很偏激哦)：
- 1、只關注項目本身，不懂就baidu一下。
- 2、除了做好項目，還會閱讀和項目有關的技術書籍，看wikipedia。
- 3、除了閱讀和項目相關的書外，還會閱讀IT行業的書，比如學Java時，還會去了解函數語言，如LISP。
- 4、找一些開源項目看看，大量試用第三方框架，還會寫寫demo。
- 5、閱讀基礎框架、J2EE規範、Debug服務器內核。
大多數程序都是第1種，到第5種不光需要濃厚的興趣，還需要勇氣：我能讀懂嗎？其實，你能夠讀懂的
耐心，真的很重要。因為你極少看到閱讀源碼的指導性文章或書籍，也沒有人要求或建議你讀。你讀的過程中經常會卡住，而一卡主可能就陷進了迷宮。這時，你需要做的，可能是暫時中斷一下，再從外圍看看它：如API結構、框架的設計圖。
下圖是我總結出目前最應該學習的源碼知識點：
二、分佈式架構
分佈式系統是一個古老而寬泛的話題，而近幾年因為 “大數據” 概念的興起，又煥發出了新的青春與活力。除此之外，分佈式系統也是一門理論模型與工程技法並重的學科內容。相比於機器學習這樣的研究方向，學習分佈式系統的同學往往會感覺：“入門容易，深入難”。的確，學習分佈式系統幾乎不需要太多數學知識。
分佈式系統是一個複雜且寬泛的研究領域，學習一兩門在線課程，看一兩本書可能都是不能完全覆蓋其所有內容的。
總的來說，分佈式系統要做的任務就是把多臺機器有機的組合、連接起來，讓其協同完成一件任務，可以是計算任務，也可以是存儲任務。如果一定要給近些年的分佈式系統研究做一個分類的話，我個人認為大概可以包括三大部分：
- 分佈式存儲系統
- 分佈式計算系統
- 分佈式管理系統
下圖是我總結近幾年目前分佈式最主流的技術：
三、微服務
當前微服務很熱，大家都號稱在使用微服務架構，但究竟什麼是微服務架構？微服務架構是不是發展趨勢？對於這些問題，我們都缺乏清楚的認識。
為解決單體架構下的各種問題，微服務架構應運而生。與其構建一個臃腫龐大、難以馴服的怪獸，還不如及早將服務拆分。微服務的核心思想便是服務拆分與解耦，降低複雜性。微服務強調將功能合理拆解，儘可能保證每個服務的功能單一，按照單一責任原則（Single Responsibility Principle）明確角色。 將各個服務做輕，從而做到靈活、可複用，亦可根據各個服務自身資源需求，單獨佈署，單獨作橫向擴展。
下圖是我總結出微服務需要學習的知識點：
四、性能優化
不管是應付前端面試還是改進產品體驗，性能優化都是躲不開的話題。
優化的目的是讓用戶有“快”的感受，那如何讓用戶感受到快呢？
加載速度真的很快，用戶打開輸入網址按下回車立即看到了頁面
加載速度並沒有變快，但用戶感覺你的網站很快
性能優化取決於多個因素，包括垃圾收集、虛擬機和底層操作系統（OS）設置。有多個工具可供開發人員進行分析和優化時使用，你可以通過閱讀 Java Tools for Source Code Optimization and Analysis 來學習和使用它們。
必須要明白的是，沒有兩個應用程序可以使用相同的優化方式，也沒有完美的優化 java 應用程序的參考路徑。使用最佳實踐並且堅持採用適當的方式處理性能優化。想要達到真正最高的性能優化，你作為一個 Java 開發人員，需要對 Java 虛擬機（JVM）和底層操作系統有正確的理解。
下圖是我總結性能優化應該學習理解的幾大知識體系：
五、Java工程化
工欲善其事，必先利其器，不管是小白，還是資深開發，都需要先選擇好的工具。提升開發效率何團隊協作效率。讓自己有更多時間來思考。
“大話架構”阿里架構師分享的Java程序員需要突破的技術要點
閱讀更多 java高級面試 的文章
