成为架构师，职业规划这么难么？
博主28岁了，海归研究生毕业，生活无忧。所以一直觉得什么架构师，项目经理，CTO，赢取白富美都是时间的问题。直到突然有一天被领导叫到办公室，给我倒了1杯水，认真地跟我说你现在需要去找自己喜欢的工作。。。
我突然就失业了，离职之后走在大街上，想着自己到40岁的时候应该是个什么样子，突然心底一沉，我貌似想不到什么好的结局。
后来我痛定思痛，决定用28岁的努力来弥补之前缺少的东西，那我之后的面试过程中，与朋友的交流过程中，基本上都会聊职业规划，这是我写的关于架构师的职业规划和技术栈，也是一个28岁的程序员的自我救赎之路！
都说程序员35岁之后就找不到工作了，那么35岁的程序员找不到工作了，总得找个地方埋了吧？那他们埋在哪里呢？
博主一段时间坐在HR对面，经常听到她们说的一句话："35岁的程序员，不用来面试了"。
那么程序员到35岁到底转行了多少？
程序员年龄分布图：
图中可以看到25岁的程序员是最多的，而35的程序员是25岁程序员的十分之一不到。如果程序员不是在10年前招生比现在少10倍的话，那么恐怕一半的程序在工作到35岁之前已经转行或者死掉了。
这是一个国内的调查
也是类似的结果，程序员在达到35之前就转行了。
如果在28岁的程序员，天天都很忙，不知道忙什么，到了他们35岁会在哪里？
这是程序员的转行报告
架构师故名思义，处于一个牛逼的状态，可以说在技术界一人之下，万人之下。位置如下图所示
那我们已经知道了程序员只知道加班和努力的话，那还是要在35岁给自己找个地方给埋了。所以仅仅努力是不够的，我们来看看应该怎么努力
程序员是个高强度职业，都说自己工作太多，根本没有时间学习。这里我贴一个 左耳朵耗子 的文章。
09 | 答疑解惑：渴望、热情和选择
这是一个我认同的架构师技术栈
后台开发工程师与Web架构师，基础平台架构师有啥区别？
其实没啥区别，技术栈基本都一致。目前大部分的系统都是前后端分离独立开发和部署。后端开发工程师指的就是负责后端的开发。Web架构师，这个是对Web工程的架构，即整个Web工程的系统设计，这要求很高，需要考虑的因素很多，而且要根据实际情况进行不同策略的架构，如是否需要分布式，服务的治理监控等等，对能力和经验要求很高。基础平台架构师，指的是底层平台的架构设计师，目前很多大公司都是喜欢平台化战略、以减少应用层面重复的开发，比如spring就可以算做一个基础平台，对于基础平台，你需要首先了解应用层面需要啥，然后再去机构，切勿闭门造车
前阿里P9:架构师是如何炼成的？
大家好，我是程序员菜菜。[太阳]
相信每个程序员心中都有一个成为架构师的梦想，但梦想是美好的，道路是曲折的。
可能很多人觉得 学习架构设计就像学习一门编程语言一样，先学习一下基本的语法，再研究一下细节和原理，然后实践一下就能够快速掌握。不过，真正实践之后，你会发现——架构设计的难度和复杂度要高很多。
前阿里架构师李运华（P9）在他的专栏里 总结了几个架构设计相关的特性：
1. 架构设计的思维和程序设计的思维差异很大。
架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。很多程序员在转换为架构师后，很难一开始就意识到这个差异，还是按照写代码的方式去思考架构，会导致很多困惑。
2. 架构设计没有体系化的培训和训练机制。
3. 程序员对架构设计的理解存在很多误区。
例如：要成为架构师必须要有很强的技术天分；架构师必须有很强的创造力；架构设计必须要高大上才能体现架构师的能力；架构一定要具备高可用、高性能……这些似是而非的误区让很多技术人员望而生畏，还没尝试就已经放弃了。
在他的专栏《从0开始学架构》中，李运华还提到了架构设计的目的。 从架构设计的 历史 背景，可以看到，整个软件技术发展的 历史 ，其实就是一部与“复杂度”斗争的 历史 ，架构的出现也不例外。
简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的 历史 背景和原因，我们可以基本推导出答案： 架构设计的主要目的是为了解决软件系统复杂度带来的问题。
这个结论虽然很简洁，但却是架构设计过程中需要时刻铭记在心的一条准则，为什么这样说呢？
首先，遵循这条准则能够让“新手”架构师心中有数，而不是一头雾水。
“这么多需求，从哪里开始下手进行架构设计呢？”。“架构设计要考虑高性能、高可用、高扩展……
这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间”。
“业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？”。
以上类似问题，如果明确了“架构设计是为了解决软件复杂度”原则后，就很好回答。
“这么多需求，从哪里开始下手进行架构设计呢？”—— 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
“架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间”—— 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
“业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？”——理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
其次，遵循这条准则能够让“老鸟”架构师有的放矢，而不是贪大求全。技术人员往往都希望自己能够做出最牛的东西，架构师也不例外，尤其是一些“老鸟”架构师，为了证明自己的技术牛，可能会陷入贪大求全的焦油坑而无法自拔。例如：“我们的系统一定要做到每秒 TPS 10 万”。“淘宝的架构是这么做的，我们也要这么做”。“Docker 现在很流行，我们的架构应该将 Docker 应用进来”。
以上这些想法，如果拿“架构设计是为了解决软件复杂度”这个原则来衡量，就很容易判断。
得益于移动互联网技术的快速发展，李运华有很多的机会直接参与架构设计，这些架构背后的业务形形色色，包括社交、电商、 游戏 、中间件、内部运营系统；用到的技术栈差异也比较大，包括 PHP，Java、C++ 等。
虽然每次架构设计对他来说都是一个新的挑战，但正好也提供了非常好的机会，让他亲身体验不同的架构设计。在这个过程中，他不断学习、思考、实践、总结、改进、交流，逐步形成了自己的一套架构设计方法论。有了这套方法论后，不管什么样的业务，不管什么样的技术，按照这套方法论都能够设计出优秀的架构。
从普通程序员到大厂架构师，它指明了方向，非常不错的学习资料啦！