程序員其實也和其他職業一樣，時間越久技術越熟練，經驗自然更豐富。如果你的年齡和你的薪資不相符，你就應該考慮是不是年齡上去了能力卻沒上去，你所求的薪資和你要求的崗位，要讓企業覺得你值這個價，自然不會被淘汰。
對於程序員的工作出路，有以下幾點建議：
20-27歲：技術積累階段
假設本科22歲畢業，那麼工作的前5年對你來說是打基礎的階段。在這5年時間裏面，你要積累足夠的代碼量，打磨自己的技術實力，成爲某一個技術細分領域的牛人。
28-35歲：形成思維方法論和知識體系的階段。
當你積累足夠的代碼量，例如超過10萬行代碼以後，你應該形成了自己的思維方法論和自己獨立的學習技巧，任何新的技術在你眼中都能迅速的看到技術的本質，快速吸收成爲你的知識體系的一部分。
到了這個階段，你會發現你所完全不瞭解的新技術新知識是非常少的，新技術對你來說也不過是幾天時間就把玩的很好的玩具，學習越來越輕鬆，掌握的知識儲備越來越多。
你開始逐漸的不再滿足於純技術領域的探索，而是思考更多的問題：如何將技術轉化爲生產力;什麼技術在什麼樣的場合能夠發揮最大的價值;技術團隊應該怎樣構建;在一家公司裏面，我怎樣才能將自己的技術能力最大化的發揮出來?
在這個階段，積累技術對你來說簡直是小菜一碟，你更需要磨練的是思考能力，形成自己的思維方法和知識體系，這將是你幫助你一生的武器。
35歲以後：瞭解自己，把自己變現的階段。
毋須諱言的是，35歲以後你的一線coding能力一定是下降的，你寫代碼絕對不如25歲的程序員快，效率高。但是這不重要，因爲編程只是你整個武器庫當中相對最不重要的了，你的經驗，你的視野，你的架構能力，你的管理能力，你分析和解決問題的能力已經遠遠不侷限於技術這個領域。
結論程序員最終最好的出路就是架構師
下面給大家安利一下CSAI首席顧問溫昱編寫的《程序員向架構師轉型必備》下面給大家簡單介紹一下；需要的朋友點贊+關注後私信小編“架構”可免費領取完整PDF版
架構是很玄的東西，成爲優秀的架構師也是大部分程序員的理想。溫昱先生這本書的特點就是從程序員角度，深入淺出地講述了架構師的修煉之道。程序員與架構師區別的最重要一點是看待事物的角度和處理方法，優秀的程序員按照本書的方法，在日常工作中一一步步實踐，有助於培養出架構師的能力，從而逐步成長成爲架構師。架構的目標是爲了溝通和交流，溫先生也深刻地領悟到這一架構設計的根本目標，並將這一目標轉化爲方法論。架構設計不是給自己看的，而是爲了與客戶、領導和團隊溝通，本書的重點在於架構設計實踐，從用例、需求分析、概念模型、細化模型等一步步地指導如何完成架構設計，並且對於架構設計過程中可能出現的各種問題給予瞭解答。
第1章從程序員到架構師
有人說，軟件業當前的人才結構是橄欖型(中間大兩頭小)，需求量最大的“軟件藍領”短缺問題最爲凸顯，這極大地制約着軟件業的發展，因此要花大力氣培養大量的初級軟件程序員等“藍領工人”。但業內更多人認爲，軟件業當前的人才結構是金字塔型，高手和專家型人才的總量不足纔是“制約發展”的要害，因此一方面軟件工程師應爭取提升技能、升級轉型，另一方面企業和產業應加強高級技能培訓、高級人才培養。
軟件業的人才結構，到底是金字塔型，還是橄欖型?
本書認爲，一旦區分開“學歷結構”和“能力結構”，問題就不言自明瞭
- 學歷結構=橄欖型。“中級學歷”最多。有資料稱，軟件從業者中研究生、本科與專科的比例大致是1:7:2.
- 能力結構=金字塔型。“初級人才”最多。工作3年以上的軟件工程師，就-躍成爲“有經驗的中級人才”了嗎?顯然不一定。
- 有學歷≠有能力。每個開發者真正追求的是，成爲軟件業“人才能力結構”的頂級人才或中級人才。
借用《華爲研發》一書中的說法，“機會、人才技術和產品是公司成長的主要牽動力。機會牽引人才，人才牽引技術，技術牽引產品，產品牽引更大的機會。在這四種牽動力中，人才所掌握的知識處於最核心的地位."
第1部分基本概念篇
第2章解析軟件架構概念
不積跬步，無以至千里。
程序員在向架構師轉型時，都希望儘早弄清楚“什麼是架構”。但是，架構的定義又多又亂，已造成“什麼是架構”成了程序員向架構師轉型的“大門檻”。
本章，我們討論軟件架構的概念。
值得說的是，人們對“Architecture"有着不同的中文叫法，比如架構、構架和體系結構等。本書將一貫地採用“架構”的叫法；當然，當引用原文或提及書名時將保留原來的叫法。
第3章理解架構設計視圖
架構設計是一門解決複雜問題的藝術。
設計任何複雜系統時，架構視圖都是不可或缺的(無一例外)。 但由於在8常開發工作中較少接觸，大部分程序員對“設計視圖”的思想還比較陌生。
本章圍繞“架構視圖”這一主題，將逐次討論:
- 設計架構時， 架構視圖爲什麼必不可少? 【本章問題 1】
- 什麼是架構視圖? 【本章問題 2】
- 如何運用 “邏輯視圖+物理視圖”設計-一個系統的架構? 【本章問題3】
第2部分實踐過程篇
第4章架構設計過程
程序員向架構師轉型，難在何處?難在必須要能開始“試着做起來”，並慢慢積累感覺，進而積累經驗。
“需求決定架構”之所以是一-句廢話，就是因爲它沒告訴開發人員“架構設計怎麼做”。
甚至，在沒有積累任何經驗和“感覺”的情況下，忽然被老闆“委以重任”負責架構設計，都未必是一件好事。因爲這次失敗了，下次機會就沒了。
本章通過下述方式，講清楚架構設計過程的大局，希望幫助程序員能將架構設計“試着做起來”:
- 架構設計過程包含哪些步驟?
- 步驟之間什麼關係?下游步驟的“輸入”依賴的是上游步驟的哪個“輸出”?
第5章需求分析
一個程序員，在向架構師轉型的道路上，一定“繞"不過軟件需求的問題。
本章立足軟件開發人員的視角，逐次討論:
- 需求怎麼來的? (需求開發- 願景分析+需求分析)
- 如何判斷掌握的需求全不全? (功能、 質量、約束三類需求都不能漏)
- 從需求向設計轉化的關鍵思維是什麼? (功能、 質量、約束影響架構的不同原理是核心)
第6章用例與需求
幾年來，筆者接觸了大量開發人員，發現只要是關心設計的開發人員，都關心用例技術，認爲用例技術很流行、很有用，希望更好地掌握這種技術。
本章立足軟件開發人員的視角，抽取-些實際問題， 並在最後的“實際應用”一節解決“用例建模夠不夠?流程建模要不要?”的常見困惑，希望對更清晰地運用用例技術有所幫助:
- 用例圖、用例規約、用戶故事，這些技術有什麼關係?
- 如何應用?
- 需求分析的三套實戰論中，用例建模和流程建模的關係是什麼?
第7章領域建模
很多希望向架構師轉型的程序員，對“具體開發技術”都比較有信心。那麼，轉型路上他們最擔心什麼呢?
領域知識不足，是他們最大的擔心。
本章以領域模型和領城建模爲主題，逐次討論:
- 什麼是領域模型?需求人員如何利用領域模型，避免溝通不足和分析癱瘓?
- 開發人員如何利用領域模型，破解“領域知識不足”死結?
- 如何通過領域模型，提高系統的可擴展性?
第8章確定關鍵需求
每向錯誤目標邁進一-步，就離正確目標遠了一步。軟件設計也不例外。
面對或厚或薄、或穩定或易變、或嚴謹或錯誤連篇的《需求文檔》，設計者應當如何確定真正影響、真正左右架構設計的關鍵需求呢?
圍繞“設計目標如何確定”的話題，本章的討論分3個層遞進展開:
- 衆說紛紜——什麼 決定了架構。
- 真知灼見——關鍵需求決定架構。
- 付諸行動——如何確 定關鍵需求。
第9章概念架構設計
概念架構是直指系統目標的設計思想、重大選擇，因而非常重要。《方案建議書》《技術白皮書》和市場彩頁中，都有它的身影，以說明產品/項目/方案的技術優勢。也因此，有人稱它爲“市場架構"。
大量軟件企業，招聘系統架構師(SA)、系統工程師(SE)、 技術經理、售前技術顧問、方案經理時，職位能力中其實都包含了對“概念架構設計能力”的要求。例如:
- 系統架構師 (SA)。 (1)軟件總體設計、開發及相關設計文檔編寫: (2) 關鍵技術和算法設計研究; (3)系統及技術解決方案設計，軟件總體架構的搭建: (4)通信協議設計制定、跟蹤研究; ....
- 系統工程師(SE)。產品需求分析:產品系統設計:技術問題攻關:解決方案的輸出和重點客戶引導:指導開發工程師對產品需求進行開發....
- 技術經理。負責公司系統的架構設計，承擔從業務向技術轉換的橋樑作用:協助項目經理制定項目計劃和項目進度控制:輔助需求分析師開展需求分析、需求文檔編寫工作.....
- 售前技術顧問。1) 負責支持大客戶解決方案和能力售前諮詢工作: 2) 完成項目售前階段的客戶調研、需求分析和方案制定、協調交付部門完成POC或Demo: 3)參與達標，負責標書澄清; 4) 參與項目項目前期或高層架構設計，根據需要完成項目的系統設計相關工作.....
- 解決方案經理。 解決方案提煉與推廣:現場售前技術支持，如市場策劃、方案編寫售前交流等；爲前端市場人員提供投標支持、投標方案(技術、配置)編制或審覈 ......
既然概念架構這麼重要，本章就專門講述:
- 概念架構“是什麼”?
- 概念架構“長什麼樣”?
- (案例分析)概念架構 “怎麼設計”?
第10章細化架構設計
從程序員到架構師的轉型，必然要經歷的一個突破是“思維方式的突破"。
第11章架構驗證
不值得驗證的架構，就不值得設計。本章的主題是架構驗證:
- 原型技術的分類、用途。
- 如何進行架構驗證。
第3 部分模塊劃分專題
第12章粗粒度“功能模塊”劃分
模塊劃分是架構師的“看家本領"，也是架構師這一崗位的“基本職責",其重要性無需多說。程序員要向架構師轉型，必須重點學習和掌握模塊劃分技能。
第13章如何分層
王太太燒魚時總是將魚切成三段，丈夫不解其意，問原因。答日:我媽媽就是這樣做的。問王太太的媽媽，回答又是:我媽媽就是這樣做的。最後媽媽的媽媽揭曉了答案:原來那時家裏窮買不起大鍋，偶爾喫頓魚就只好把魚切成三段才能放進鍋裏!
這個故事還有另一個版本。王太太烙餅時總是把餅的外面一圈切掉，丈夫不解其意，問原因。答日:我媽媽就是這樣做的。問王太太的媽媽，回答又是:我媽媽就是這樣做的。...最後，媽媽的媽媽揭曉了答案:原來那時家裏窮買不起大鍋，只有把攤得太大的餅的外圈切掉才能放進鍋裏!
上述故事說明，“學樣兒”未必適合，“知其所以然”纔是王道。
程序員向架構師轉型，對分層架構當然得從“學樣兒”開始，但應該力求儘早“悟道”——精通分層架構設計對架構師崗位太有必要了，因此程序員能夠知“分層架構設計”之所以然，起碼是向架構師崗位邁進了一大步。
本章講解如何合理分層。
第14章用例驅動的模塊劃分過程
用例技術，是功能需求實際上的標準。應用用例技術的企業和個人都非常多。既然如此，深刻領會如何從作爲需求的用例過渡到模塊劃分設計，就大有現實意義了。
這就是本章的主題一用例驅動的模塊劃分 過程。
第15章模塊劃分的4步驟方法一運用層、 模塊、功能模塊、用例驅動
要成爲架構師，是先學方法，還是先實踐?
本書建議，儘早接觸並嘗試着設計(請參考第3章中關於“開發人員應該多嘗試設計”的相關內容)，並在進行過照貓西虎式的實踐之後，系統地培訓設計方法....
也是馬士兵老師一直提倡的先輪廓再脈絡。
最後
廣而言之，方法之於個人，乃至軟件業，都是至關重要的。對架構新手，方法是陌生之地的指路明燈，避免架構設計者不知所措(這很常見);對架構老手，方法是使經驗得以充分發揮的思維框架，指導架構設計者擺脫“害怕下一個項目”的心理和“思維毫無章法"的狀態:對軟件業而言，方法是整個產業“上升一個層次”的“內功”，沒有“內功”爲基礎，單靠“外力”促進軟件產業升級是不現實的。