程序员其实也和其他职业一样，时间越久技术越熟练，经验自然更丰富。如果你的年龄和你的薪资不相符，你就应该考虑是不是年龄上去了能力却没上去，你所求的薪资和你要求的岗位，要让企业觉得你值这个价，自然不会被淘汰。
对于程序员的工作出路，有以下几点建议：
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章中关于“开发人员应该多尝试设计”的相关内容)，并在进行过照猫西虎式的实践之后，系统地培训设计方法....
也是马士兵老师一直提倡的先轮廓再脉络。
最后
广而言之，方法之于个人，乃至软件业，都是至关重要的。对架构新手，方法是陌生之地的指路明灯，避免架构设计者不知所措(这很常见);对架构老手，方法是使经验得以充分发挥的思维框架，指导架构设计者摆脱“害怕下一个项目”的心理和“思维毫无章法"的状态:对软件业而言，方法是整个产业“上升一个层次”的“内功”，没有“内功”为基础，单靠“外力”促进软件产业升级是不现实的。
网友评论