本文转载自微信公众号“bugstack虫洞栈”，作者小傅。转载本文请联系bugstack公众号。目录1.前言2.你用过多线程和锁吗？3.你的成长期目标？4.如何成长为架构师？5.总结1.前言你是否只注重工作和学习？产品需求开发系统功能，那么程序开发基本上可以简单理解为PRD根据需求，定义属性，创建方法，调用展示三个步骤。特别是在一些大公司，会有简单易用、完整、标准的架构体系和运维服务，比如：RPC、MQ、Redis集群、分布式任务、配置中心、分库分表等组件、网关等。匹配的系统架构。因此，让程序员只关心业务功能开发！让程序员只关心业务开发，有成熟的系统架构、标准的开发流程、通用的功能设计，对团队效率提升很有好处。但是有些程序员就是因为这样的好事日复一日的做着同样的事情，最后变成了工具人。如果是框架和中间件的存在，那是程序员只关心业务开发。那为什么面试的时候被问到核心部件的设计和原理呢？在这个时代，不放弃学习几乎是你唯一的生存之道。2.没用过多线程和锁？面试必问的多线程和锁，甚至可能还挺深入，比如：AQS、CAS、CLH、MCS、锁升级、对象头等。但是在实际业务开发中，你用过吗它？也许这就是大多数学生所说的面试造就火箭的地方！在互联网应用的一些业务场景的开发中，确实很少用到多线程，几乎不需要。锁。即使在可以使用多线程的地方，也可以使用其他更好的方式来处理。就像你需要多个线程来存储数据库中的数据，那么你可以使用异步MQ把压力分散到各个应用实例上。这种开发方式的演进是因为现在的应用开发和部署都是基于分布式的思想，所以很少用线程来压榨单实例的CPU。基于RPC+MQ+数据库路由+网关，各种协同组件构建的分布式应用，在某些时候改变了我们的开发模式。可能是我们需要在单实例下用到很多多线程的开发思路。使用分布式架构后，我们需要改变这种思维，那么随时使用多线程和锁的场景也会减少。图14-1分布式简化应用部署图14-1分布式简化应用部署但是不代表没有多线程和锁的业务场景，比如我们的核心组件，数据库连接池，分布式任务，会涉及到多线程和锁的使用。还有一些类似商品闪购的场景，同样需要用到锁具。然后通过多线程最大限度地利用资源提高效率，在竞争相同资源的情况下使用锁来保证业务流程的正确性。就像：数据库连接池是为了数据库资源的合理配置，商品闪购是为了库存竞争。但是多线程一般不会用在不需要竞争和分配资源的分布式场景。如果我们对用户资源做单次统计操作，那么原来的应用是单实例还是可以加锁累加。但是现在是分布式应用部署，也就是你此时可能正在使用A实例提供你的需求，当你再次刷新页面时，你可能会访问到B实例。这个时候在实例上做一些积累就不那么方便了。这就是为什么在分布式应用框架的应用中，可以使用多线程和锁的地方并不多。但是如果需要了解一些中间件或者核心组件的设计，就需要了解相关的核心知识。纸上的大量技术是你造轮子、造火箭、成为建筑师的基础！想要在这条路上走得更远，还需要不断学习。3.你的成长期目标？图14-2你的成长阶段就编程发展的路径而言，每个成长阶段的目标都会有自己难以克服的困难。上学的时候，突然冒出来的奇葩知识在电脑上运行起来非常吃力。工作1到3年，之前掌握的都是皮毛，接下来要深入学习，深入学习之后，再和数学硬碰硬。工作3到5年，光看以前的理论知识没那么难，但如何真正解决一些复杂的项目，还是要集中脑干。工作5到7年后，薪水和职位会成为现阶段很难突破的瓶颈。积累不足，沉淀不足，不满现状！工作7到10年，以前觉得什么都很难学，现在可能很难有空闲时间了。.不一定是到了年龄就能力到了。随着年龄的增长，每个阶段都有难以克服的困难。而那些看似突破瓶颈，达到你想要的高度的人。事实上，在每个阶段，他们都在跑在前面。但就纯技术成长而言，理论知识其实并不难，只要学过，还是可以学的，只是时间成本不同而已。但是过了理论知识这一关之后，接下来要面对的就是创造力，这也是为什么你觉得自己懂了那么多技术含量，但在实际开发中总觉得自己写不出好的代码。知道核心技术却写不出好代码，好比会汉字却不会诗词作曲，会色彩却不会画山水，会跳跃却不会跳舞。因此，多练习项目代码，多阅读设计模式，会让你更好地理解代码的使用方法，也能提升和突破现阶段的壁垒。??推荐付哥的?，公众号：bugstack虫洞栈，回复：设计模式，下载。4.如何成长为架构师？图14-3架构师知识体系说到架构师，真的很难，因为报了课程就可以成为架构师。架构师的成长，更多的取决于你的研发团队是否需要架构师，同时你需要在这个岗位上发挥应有的作用。如果您还不是建筑师，但想成为一名建筑师。然后还要看你的老板愿不愿意把你培养成架构师，你有没有各种能力。另外，高级开发不一定比架构师低。高级开发有时比架构师的工作更专注、更核心。那么除了图14-3对架构师能力的概述之外，具体还有哪些呢？规范已经建立，架构已经设计。有了一定的技术深度和广度，就可以改正错误，处理事故。带领团队推动项目落地，也可与其他团队合作。了解运营和业务规划，并尽早参与产品开发阶段。了解业务和运营，了解数据指标和投资回报率。架构更多的是体验和经验的结合，而不是单一内容的单一渠道。并不是说没有建筑师就没有建筑。有时一个公司或一个团体承担的项目不是那么大，那么你可以使用成型架构模型。但是，如果有一个非常复杂的场景设计，就是一组十几套系统，安排开发，提供服务，支持几万速杀，几十万日活，扩展到百万级DAU，你需要一个架构师来控制它。再比如：从下单，到交易，到支付，到结算，到活动，到玩法，怎么支持。此卷的复杂性需要架构权衡。没有绝对的对与绝对的错，只是什么时候更合适。多学习，不给自己设界限，才能更好的突破！好的结构，远看是部门效率，近看是解决烂代码！很多时候，仓促行事可能会让整个项目烂掉。坏的越来越多，最终会影响业务的发展。那么这些坏代码是从哪里来的呢？bug往往是接手的坏代码或者没有继承别人的想法。业务需求是一开始写的，没有可扩展性，后面不断积累。结构和命名不佳，从未格式化。无法预测未来的业务趋势，无法设计合理的可扩展性系统。炫耀大于整体规划设计，推出新技能，却缺乏相应的搭配。没有设计，功能都是基于流程的。为任何你需要的写ifelse。总想想还好，因为心里有怨言，部门急功近利，不会给你做长期的准备，没人会拿，写不出好东西.小组缺乏相应的流程规范和审查、设计审查、代码审查和基准项目以供参考。懂几句jdk源码从来都不是写出好代码的基础，而是基本功。就像老木匠用斧头，新木匠用电锯，只是有些东西好，有些不好。永远没有好的代码。代码再好，也需要一直维护和改造。没有业务对应的量，更不用说QPS，TPS，TP99，TP999，服务健康，很多空谈都是耍流氓。不好，从很多方面来说，这不是你报个班就能学会的。业务、产品、研发，三者的共同努力，才能更好的减少烂的发生，这是每一个研发都应该努力的方向，也几乎是你成为架构师的必由之路。5.总结写了这么多，主要是为了帮助和我一样在这条路上继续奋斗的人。可能大家在这几个阶段都会迷茫：上学怎么学技术，求职怎么写简历，工作中个人如何成长等等。所以很多时候，更多的还是看自己克制自己的选择！2020年已是12月，是疫情的开始，也是戴口罩的一年。有些人学到了很多知识。反正时间很快！你用剑，我用刀，都有目的，而且很火热！继续前进！
