你只面向工作学习吗？
如果说编程只是单纯的承接产品需求开发系统功能，那么基本可以把程序开发简单理解成按照需求PRD，定义属性、创建方法、调用展示，这三个步骤。
尤其是在一些大公司中，会有易用的、完善的、标准的架构体系和运维服务，例如：RPC、MQ、Redis集群、分布式任务、配置中心、分库分表组件、网关等搭配出来的系统架构。也因此让程序员做到只关心业务功能开发！
让程序员只关心业务开发，有成熟的系统架构、有标准的开发流程、有通用的功能设计，对于团队效能提升来说是非常好的事。但一部分程序员正因为有这样的好事，让日复一日的岁月做着同样的事，最后成为工具人。
如果是框架和中间件的存在，是了让程序员只关心业务开发。那为什么你面试的时候会被问到核心组件的设计和原理呢？ 在这个年代，别放弃学习是你几乎唯一的生存途径。
二、多线程和锁没用过？
面试必问的多线程、锁，甚至可能问的还挺深入，比如：AQS、CAS、CLH、MCS、锁升级、对象头等等。但在实际的业务开发中，你用到了吗？可能这也是大部分同学说，面试造火箭的地方！
互联网应用中有些业务场景开发，确实很少能用到多线程，也几乎不需要你去加锁。即使你能用到多线程的地方也可以用其他更好的方式处理，就像你需要多个线程把数据落库，那么就可以使用异步MQ的方式，把压力分散到各个应用实例上去。而这一开发方式的演变，是因为现在的应用开发和部署都是基于分布式的思想，所以也就很少会有非得用线程来压榨单实例CPU。
在基于RPC+MQ+数据库路由+网关，以及各类配合的组件下，构建出的分布式应用，在某些时候是改变了我们的开发模式的。可能原来我们需要大量使用多线程在单个实例下的开发思路，在使用分布式架构后，就需要转变这一思想，所以随时而来的使用多线程和锁的场景也会减少。
图 14-1 分布式简化的应用部署
但，也不是就没有多线程和锁的业务场景，就比如我们的核心组件中，数据库连接池、分布式任务中，都会涉及到多线程和锁的使用。也有一些类似商品秒杀的场景，同样需要使用到锁。
那么，使用多线程为了更大限度的利用资源提升效率，加锁是为了在同一个资源有竞争的情况保证业务流程的正确性。就像：数据库连接池为了合理分配数据库资源、商品秒杀是为了库存的竞争。
可是，在没有需要竞争和分配资源的情况下，一般并不会在分布式场景下使用到多线程。假如我们做一个用户资源单次计数的操作，那么原来的应用是单实例还是可以加锁累加计数的。但现在是分布式应用部署，也就是你可能这一时刻是A实例提供你的需求，当你再次刷新页面后可能访问到的就是B实例。这时候在想做一些实例上的累加，就没那么方便了。
这也就是在分布式应用框架的应用中，让你能用到多线程和锁的地方并不多的原因。但如果你有需要去了解一些中间件或者核心组件的设计时，就需要了解相关的核心知识。
很多纸上谈兵的技术，也就是你造轮子、造火箭、成为架构师的根基！ 如果你还想奔着这条路能走的更远，就需要继续学习。
三、你的成长阶段目标？
图 14-2 你的成长阶段
就编程开发这条道路而言，每一个成长阶段的目标都会有它随着带来的难以攻克的难。
- 上学阶段，对突如其来的奇怪知识，想把它在自己电脑运行起来，就很难。
- 工作1~3年，以前掌握的都是毛皮，接下来需要有深度的学习，而深入后都将与数学硬碰硬。
- 工作3~5年，看以前理论性的知识也没那么难，但怎么实际要解决一些复杂项目，还是抓心挠肝。
- 工作5~7年，薪资与职位都会成为这个阶段非常难以突破的瓶颈，积累不足、沉淀不够，现状不满！
- 工作7~10年，以前觉得什么都难学，现在可能让你有空闲时间都难。并不一定年龄到了，本事就到了。
随着年龄的增长，每一阶段都有难以跨越的难。而那些看上去突破了瓶颈，达到了你想要的高度的人。其实每一个阶段，他们都跑在前面。
但就单纯的技术成长而言，其实理论知识并不难，只要你学就还能会，只是付出的时间成本不同罢了。但过了理论知识这一关后，接下来要面对的是创造能力，也就是为什么你感觉自己会了那么多技术内容，但是实际开发时却总感觉写不出好代码的阶段。
会了核心技术但又写不出好代码，就很像是：会汉字但写不出诗词歌赋、懂色彩但绘不出山河大川、能蹦跳但舞不出摇曳生姿。
所以，多实战一些项目代码，多看一些设计模式，会让你更好的理解代码该怎么用，也就能提升突破当前的阶段屏障。推荐小傅哥的《重学Java设计模式》，公众号：bugstack虫洞栈，回复：设计模式，下载。
四、怎么成长为架构师？
图 14-3 架构师知识体系
讲到架构师，其实真的挺难因为报名一个课程学习完就能成为架构师。架构师的成长更多的取决你们的研发组是否需要一个架构师，也同时需要你在这个岗位起到应有的作用。
如果你还不是架构师，但想成为架构师。那么还取决于你的老板是否愿意把你培养成架构师，以及你自己的多方面能力是否具备。另外，并不一定高级开发就低于架构师。高级开发有时候比架构师做的事更专一、更核心。
那么除了图 14-3 对于架构师的能力概况，有哪些具体的事项呢？
- 定得了规范、设计了架构。
- 有一定的技术深入和广度，改的了bug、处理得了事故。
- 带了了小组推进项目落地，也能协同其他组配合。
- 了解运营和业务规划，提前介入产品开发阶段。
- 懂得了业务和运营，了解数据指标和各项ROI。
- 架构更多的是经验和经历的结合，而不是一个单项内容的单一渠道。
- 不是没有架构师就没有架构，有时候是一个公司或者小组承接的项目并没有那么大，使用成型架构模式即可。
- 但如果有非常复杂的场景设计，都是十几个系统的分组安排开发，提供服务，支持几万秒杀，几十万日活，在扩展到上百万DAU，就需要有架构师来把控。
- 再比如：从下单、到交易、到支付、到结算、到活动、到玩法、怎么支持。这个体量的复杂度才需要有架构权衡。
- 没有绝对的对和绝对的错，只是什么时候更适合罢了。多学一些，别给自己设定边界，才更好突围！
做好架构，远看是部门效率，近看是解决烂代码！很多时候的急，可能让整个工程烂掉。烂的越来越多，最终也会影响业务发展。那么这些烂代码都怎么来的呢？
- bug很多时候是接手了的烂代码或者别人的思路没有继续继承。
- 业务需求简单开始就写的没有扩展性，后面也不断的堆积。
- 没有很好的结构和命名、也从不格式化。
- 预期不到将来业务走向，设计不出合理的扩展性系统。
- 炫技大于整体规划和设计，一个新技能的引入，但缺少相应的匹配。
- 没有设计，功能都是流程式，需要啥就写ifelse。
- 总想一把梭，没关系的，心里有抱怨，部门有急功近利，不给你长时间的铺垫，没有有人带，写不出好东西。
- 组内缺少相应的流程规范和评审，设计评审、代码评审，也没与标杆项目可以参考。
- 懂几个jdk源码从不是写好代码的根本只是基本功。就像老木匠用斧子，新木匠用电锯，但做出来的东西，有的就好，有的就不好。
- 没有永远好的代码，如果像代码更好，就需要一直维护，一直改造。
- 没有业务对应的体量，不谈QPS、TPS、TP99、TP999，服务健康度，很多空谈都是耍流氓。
烂，来自于很多方面，而且这并不是你报名个课程就能学到的。业务、产品、研发，三方共同努力才能更好的减少烂的出现，而这些也是每一个研发都应该努力的方向，也几乎是你要成为架构师的必经之路。
五、总结
- 写了这么多主要是想帮助那些和我一样在这条路上持续拼搏的同好，可能大家都会在这些阶段迷茫过：上学时技术怎么学、求职时简历怎么写、工作时个人怎么成长等等。所以很多时候更多的仍然是自己的克制和自己的选择！
- 你用剑、我用刀、都有目标、都很风烧！继续加油！
