如果您打开这篇文章，建议您读完，如果哪天迷茫了可以再回来读一下。

程序员打怪升级之路

程序员（programmer）是从事程序开发，程序维护的专业人员！

又名：程序猿

今天就程序员职级晋升之路和大家聊一下。

工程师

阶段描述

成为一个合格的工程师需要1-3年时间，典型特征是“在别人的指导下完成开发”，别人指的是你部门的高工或者技术专家，通常情况下，高级工程师和技术专家负责需求分析和讨论，方案设计，工程师负责编码实现，高级工程师和技术专家会知道工程师进行编码实现。

成长阶段

工程师阶段是最原始的“基础技能积累阶段”，主要积累基础知识，包括编程语言、编程工具、各类系统的基本使用，以java后端为例

• java的语法，基本数据机构的使用
• eclipse、idea、maven、Linux命令行等各种工具
• 数据库CRUD操作、缓存的基本使用
• 业务流程中的基本流程

最好学习方法是找经典书籍或者看官方的API，不要一遇到问题就去百度，在这给大家推荐《java编程思想》《java核心技术》等这类书籍，一定要完整看一遍，哪怕花一年时间，即使里面很多内容当前工作暂时用不上。

高级工程师

成长为高级工程师需要3-5年时间，其典型特征是“独立完成开发”，包括了需求分析、方案设计、编码实现，其中需求分析和方案设计已经包含了判断和选择，当然这个选择范围相对较小，更多是在已有架构下进行设计，以java后端工程师为例，高级工程师需要完成那些工作？

• 数据库表如何设计，主要是业务表
• 是否要用缓存，缓存的key和value如何设计，缓存更新策略是什么
• 产品提出的需求是否合理？是否有更好的方式来满足？

成长指导

从普通工程师成长为高级工程师，主要需要积累方案设计经验，简单来说就是业务当前用到的相关技术的设计经验。以java后端高级工程师为例，包括：表设计经验，缓存设计经验，业务流程设计经验，接口设计经验等。当接到一个新的业务需求的时候，高级工程师可以组合这些设计经验，最终完成业务需求。

高级工程师相比工程师，有两个典型的差异：

深度： 如果说工程师要求知道how，那么高级工程师就要求知道why了，例如java的各种数据结构的实现原理，只有掌握了这些实现原理，才能对其优缺点和使用场景有深刻理解，这样在做具体方案设计的时候才能选择合适的数据结构。

理论：理论就是前人总结出来的成熟设计经验，例如数据库表设计的三个范式，常用的设计模式、缓存设计理论（缓存穿透、缓存雪崩、缓存热点）等。

技术深度

建议还是要系统的学习，包括看书和研究源码，例如，研究java虚拟机可以看《深入理解java虚拟机》，研究mysql可以看《mysql技术内幕》，spring方面就看下spring官方API

技术专家

通过努力达到！具体多少年，抱歉不知道，这个层级的程序员需要有一定的活跃度，社区，群，公司；个人博客，简历一定影响力

阶段描述

技术专家的典型特征是“某个领域的专家”，通俗的讲，只要是这个领域的问题，技术专家都可以解决。例如：java开发专家，PHP开发专家，Android专家，前端开发专家，通常情况下，领域的范围不能太小，没有人说java多线程专家的。

技术专家与高级工程师一个典型区别是，高级工程师主要是在已有框架内完成设计，而技术专家会根据需要修改、扩展、优化架构。例如，同样是java开发，高级工程师关注的是如何优化mysql的查询性能，而技术专家就会考虑引入Elasticsearch来完成搜索。

成长指导

从高级工程师成长为技术专家，主要需要“拓展技术宽度”，因为一个“领域”必然会涉及众多的技术面。以 Java 后端开发为例，要成为一个 Java 开发专家，需要掌握 Java 多线程、JDBC、Java 虚拟机、面向对象、设计模式、Netty、Elasticsearch、Memcache、Redis、MySQL 等众多技术。常见的拓展技术宽度的方法有：

• 学习业界成熟的开源方案，例如，Java 开发可以去学习 Redis、Memcache、Netty 等，Android 开发可以去研究 Retrofit、Fresco、OkHttp 等。
• 研究业界的经验分享，例如 BAT、FANG 等大公司的经验，可以通过参加技术大会等方式去近距离了解。

需要注意的是，拓展技术宽度并不意味着仅仅只是知道一个技术名词，而是要深入去理解每个技术的原理、优缺点、应用场景，否则就会成为传说中的“PPT 技术专家”。例如，以 Java 开发为例，知道 Netty 是个高性能网络库是远远不够的，还需要学习 Netty 的原理，以及具体如何使用 Netty 来开发高性能系统。

初级架构师

阶段描述

成长为初级架构师需要 5~10 年时间，其典型特征就是能够“独立完成一个系统的架构设计”，可以是从 0 到 1 设计一个新系统，也可以是将架构从 1.0 重构到 2.0。初级架构师负责的系统复杂度相对来说不高，例如后台管理系统、某个业务下的子系统、100 万 PV 量级的网站等。

初级架构师和技术专家的典型区别是：架构师是基于完善的架构设计方法论的指导来进行架构设计，而技术专家更多的是基于经验进行架构设计。简单来说，即使是同样一个方案，初级架构师能够清晰地阐述架构设计的理由和原因，而技术专家可能就是因为自己曾经这样做过，或者看到别人这样做过而选择设计方案。

但在实践工作中，技术专家和初级架构师的区别并不很明显，事实上很多技术专家其实就承担了初级架构师的角色，因为在系统复杂度相对不高的情况下，架构设计的难度不高，用不同的备选方案最终都能够较好地完成系统设计。例如，设计一个日 PV 100 万的网站，MySQL + Memcache + Spring Boot 可以很好地完成，MongoDB + Redis + Nginx + php-fpm 也可以很好地完成，备选方案设计和选择并不太难，更多的是看团队熟悉哪个技术。

成长指导

从技术专家成长为初级架构师，最主要的是形成自己的“架构设计方法论”，我的架构设计专栏其实就是讲述完整的架构设计方法论，包括架构设计目的、架构设计原则、架构设计步骤、架构设计模式等，类似的架构设计方法论还有《恰如其分的软件架构：风险驱动的设计方法》和《领域驱动设计》等。

要形成自己的架构设计方法论，主要的手段有：

• 系统学习架构设计方法论，包括订阅专栏或者阅读书籍等。
• 深入研究成熟开源系统的架构设计，这个手段在技术专家阶段也会用到，但关注点不一样，同样是研究开源系统，技术专家阶段聚焦于如何更好地应用开源项目；初级架构师阶段聚焦于学习其架构设计原理和思想，例如 Kafka 的文档中就有关于消息队列架构设计的分析和取舍。
• 结合架构设计方法论，分析和总结自己团队甚至公司的各种系统的架构设计优缺点，尝试思考架构重构方案。如果在这个基础上真的能够推动架构重构，那就更好了，既能够实践自己的架构设计方法论，同时积累经验，又能够展现自己的技术实力，拿到结果。

中级架构师

阶段描述

成长为中级架构师需要 8 年以上时间，其典型特征是“能够完成复杂系统的架构设计”，包含高性能、高可用、可扩展、海量存储等复杂系统，例如设计一个和 Kafka 性能匹敌的消息队列系统、将业务改造为异地多活、设计一个总共 100 人参与开发的业务系统等。

中级架构师与初级架构师的典型区别在于系统复杂度的不同，中级架构师面对的系统复杂度要高于初级架构师。以开源项目为例，初级架构师可能引入某个开源项目就可以完成架构设计，而中级架构师可能发现其实没有哪个开源项目是合适的，而需要自己开发一个全新的项目，事实上很多开源项目就是这样诞生出来的。

成长指导

从初级架构师成长为中级架构师，最关键的是“技术深度和技术理论的积累”，例如：

• 技术理论：CAP、BASE 是异地多活的设计理论基础、Paxos 是分布式一致性的基础算法、2PC、3PC 是分布式事务的基础算法等。
• 技术深度：Kafka 用磁盘存储还能做到高效是因为磁盘顺序写；Disruptor 高性能是结合 CPU 预读取机制、缓存行、无锁设计等基础技术；Storm 的高效异或确认机制；Flink 的分布式快照算法等。

很多同学对这点可能有疑问，这些技术理论和技术深度的事情不应该是高级工程师阶段或者技术专家阶段就应该积累的么？为何到了中级架构师阶段反而是成长的关键了呢？主要原因在于高级工程师或者技术专家阶段即使去学习这些技术，实际上也比较难理解透彻，更加难以有机会去应用，更多的时候只是了解有这个技术点而已；而到了中级架构师阶段，面对高复杂度的系统，很多时候就是几个关键技术细节决定整个架构设计的成败，或者某个设计方案理论上就是不可行的，如果不深刻理解理论和相关的关键技术点，很难设计优秀的架构。

以我做过的异地多活设计方案为例，之前很早我就知道 CAP 理论了，但也仅仅只是知道几个概念而已。真正做异地多活的时候，开始的时候还是走了不少弯路，试图做一个完美的异地多活系统，最终发现这其实是不可能的，某天突然顿悟：其实 CAP 理论已经明确指出来了这点，但最初学习 CAP 理论的时候，很难有这样深刻的理解。

高级架构师

阶段描述

成长为高级架构师需要 10 年以上时间，其典型特征是“创造新的架构模式”，例如：

• 谷歌大数据论文，创造了分布式存储架构、分布式计算 MapReduce 架构、列式存储架构，开创了大数据时代。
• 在有 MapReduce 分布式计算架构的背景下，Storm 又创造了流式计算架构。
• 在虚拟机很成熟的背景下，Docker 创造了容器化的技术潮流。

高级架构师与中级架构师相比，典型区别在于“创造性”，高级架构师能够创造新的架构模式，开创新的技术潮流。

成长指导

坦白的说，对于从中级架构师如何才能成长为高级架构师，另外一个原因是一旦涉及“创造性”，其实和艺术就比较类似了，创造性实际上是很难学会的，也很难由人教会，更多是天分，或者某种场景下灵感爆发。

参考技术界几个创造性的架构案例，我总结出几个可能诞生创造性架构的背景条件：

• 足够复杂的业务场景：例如谷歌的大数据、阿里的双十一、Facebook 的海量用户等，业务场景越复杂，给技术带来的挑战更大，更有可能产生创造性的技术突破。
• 足够强大的技术团队：绝大部分创造性的架构都来源于大公司，或者知名的研究机构；没有技术实力支撑，想突破也是心有余而力不足。
• 不满足于现状的态度：例如虚拟机很成熟但是资源占用太多，所以发明 Docker；MapReduce 难以做到实时运算，所以创造 Storm 流式运算。
• 尊重技术价值的文化：创造性的东西往往需要投入大量的人力和时间，而且刚开始一般都不会很成熟，如果完全结果导向、KPI 导向，创新技术很可能在萌芽阶段就被否定。

以上内容我反复看了多遍，我也一直想成为一名架构师，并也会在2020年不断去完善自己架构能力，因此有了这个动力去完善我的领域。

那么怎样才能登上技术的巅峰呢？

首先看邓宁-克鲁格效应

那么说了这么多我处于什么阶段呢，绝望之谷，很庆幸我认识的几个朋友将我从愚昧山峰推到了绝望之谷，现在我在努力的攀登开悟之坡。绝地青蛙，一只想跳出绝望之谷的青蛙。

邓宁-克鲁格效应是指的是能力欠缺的人在自己欠考虑的决定的基础上得出错误结论，但是无法正确 认识到自身的不足，辨别错误行为，是一种认知偏差现象。这些能力欠缺者们沉浸在自我营造的虚 幻的优势之中，常常高估自己的能力水平，却无法客观评价他人的能力。 邓宁-克鲁格效应有几种现象： 能力越差的人越容易高估自己。 能力越差的人发现不了自己和别人的差距。 人类有虚幻的优越感，总觉得自己比别人棒。 邓宁和克鲁格做了很多研究之后指出： 在很多复杂工作上，越是能力一般的普通人越觉得自己和高手差不多。 在很多复杂情绪上，越是情绪控制能力差的人越觉得自己做得特别好。 所以有些考试后，成绩好的学生有时候会感觉考砸了；而成绩一般般的竟然觉得不错。 有些行业优秀者轻松而完美地完成一些高难度的技术操作后，往往会认为这些事情是很容易的事， 有时候也理所当然地以为别人也必须这样完成才是正常的，完成不了就是别人很笨、很差劲。 有时候某人完成一件事，明明做得很好，不容易了。有些人却偏偏要鸡蛋里挑骨头，说还有某方面 做得不好，不这样就不显示出自己的能耐。其实鸡蛋里挑骨头的人往往会做得比别人差很多。 邓宁将这种效应归纳为：「如果你没有能力，你就不会知道自己没有能力。」 简言之即庸人容易因欠缺自知之明而自我膨胀。

如何登顶是我们需要考虑的问题？

技术实力：一个架构师一定是一个NB的程序员

书上得来终觉浅，绝知此事要躬行

这一点毋庸置疑，如果不是写过N年代码的优秀程序员，一定不是好的架构师，架构师是一个很虚的职位，它的价值在于落地的过程中，而不是指点江山。

eBay的架构师总结了架构师在项目中的职责：

1：解决方案：产品团队要做一个产品，架构师要帮助团队把技术可行性，技术方案权衡利弊，剖析清除。

2：架构设计和技术实现步骤：技术方案权衡取舍出来了，架构师就要设计整体的技术实现步骤，这个过程一定是和团队其他成员一起完成的，通过几个核心成员出一个初稿，然后大家讨论完善。

3：编写核心模块：技术实现步骤出来了，架构师要和开发团队一起，进行编码，架构师可能不一定细究到任何细节，最常见的实践是，系统最困难最核心最关键的部分往往由架构师亲自操刀。

4：部署上线和完善流程：系统初版实现后，架构师就要和开发团队、测试团队、运维团队一起，完成各类测试，协助解决最困难的BUG，和团队一同完成线上部署，并一同排除上线初期系统的故障；

项目过程中，架构师至少一半以上的时间是和开发团队在一起的，好的架构师不能将实施细节抛之脑后，协助解决最困难的BUG，和团队一同完成线上部署，并一同排除上线初期系统的故障；

反面例子：项目失败后，架构师反馈“团队的技术能力不够”，这孙子是一个一行代码都不会写的大忽悠。

业务理解和抽象能力：驾驭概念的技能是最高潜力

抽象能力是善于将实物概念化并归类。

业务理解：

架构师需要理解业务，并转换为可被研发理解的实现方案，因此业务理解能力是架构师的必备技能。

通常来说一个资深的业务架构师，对业务有足够的敏感度和深入的认知和积累，能够清楚的知道自己的设计给公司带来多大的业务影响，应该能大概预判业务未来的发展趋势，以便在系统的可扩展性上留有一定的空间。

抽象能力：

通过对业务的理解转换成系统实现的模型，这显然也是重要的能力，抽象很多时候也承担了分解清楚多个团队的职责，分工清晰化。

逻辑思维，抽象思维比编码的时间对架构师而言更为重要，如果你不能让一个非IT人员明白某个概念在说什么，这个架构师注定是失败的。

逻辑思维不用扩展来说，程序员的代码就是逻辑，缺乏良好的逻辑思维能力不可能成为一个好的架构师，甚至好的程序员。

抽象思维分为两点，一个是将实在的事物概念化，一个是将模糊的感觉数量化，一个苹果，抽象成质量、大小、颜色、形状、味道、这就是概念化，是架构师的必备思维，至于质量、大小、颜色形状如何转变成数字描述，就是架构师必备的思维。

比如面对一个B2C网站能够迅速抽象为采购>运营>前台搜索>下单>履单这几块，对系统分而治之，庖丁解牛，早已目无全牛。

设计能力：前瞻性的设计眼光，站在技术山顶向前眺望

1：掌握最新技术，铁打的程序员，流水的技术，程序员的开发生涯可能长达几十年，但是一门技术的平均寿命却补偿，因此作为程序员的技术领袖，架构师必须具备很好的技术前瞻性，要先于大家了解最新的技术

2：分析整合能力，架构师过程，并非结果，架构师架构师洞察呢在结构，原则、规律与逻辑的过程，架构师要清晰理解系统，以及简洁描述，这是分析整合的能力。

一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析产品定位以及产品业务，再整合现有的技术领域，找出最佳方案，实现产品概念。

3：前瞻性的设计，架构师与技术高手的区别在于，架构师不仅局限在如何调用，如何并发等架构细节，还跳出三界，考虑未来的问题和潜在风险的应对之道。

一名合格的架构师设计出来的架构要有前瞻性，要为将来的组织能力更上一个台阶而设计，满足当下的需求并能适当扩展，是遵循架构设计的系统实现要关注的，系统是多样的，架构不是，系统是演化出来的，架构不是。

学好英语，逼着自己去学习英语，要培养技术前瞻性，首先要学好英语，看懂外国文章能与业界专家进行交流，学习别人的实践方案。

反面例子，成天技术的前沿名词挂在嘴边，云计算，微服务，SAAS，PAAS这些东西天天吹，就是不落地，

技术的前瞻性还体现在技术选型上，哪些技术适合自己团队，哪些不适合，学习成本，维护成本，硬件成本，潜在风险等都是架构师要考虑的。

架构师在自己所处的领域肯定了解颇深，未来这个领域技术如何发展，应该有自己的见解，也会对未来技术的发展有所期盼，有自己的见解

技术深度：透过问题看本质，解决问题和绕开问题

透过问题看本质，则是由虚到实，往深层次挖掘

看到问题本质是架构师必须具备的素质

比如看到一段java代码，要知道在JVM中如何执行，一段跨域调用，要知道数据是如何通过各种介质到达目标，透过问题看本质使架构师能够敏锐的发现底层之真实，系统性端到端的思考问题，识别木桶的短板并解决。

什么是本质？

将互联网理解成0和1，的确是非常本质了，不过不能解答任何问题，从问题看本质，实质上是一个表层逐渐深入的过程，在架构师面对一个用户需求时，用户的需求描述就是一个表层，比如，自动远程备份数据库的功能，架构师就是将业务需求翻译成技术需求，这个过程一方面需要通过抽象思维将用户需求提炼为，启动，读取，存储，终端处理等模块，另一方面也要看到网络，操作系统，硬件，以及可靠性，稳定性，适用性，安全性等问题。

在《技术的本质》中，经济学家布莱恩阐明了技术的本质极其进化机制，主要表达了以下核心观点。

1：几乎所有的技术都来自于已经存在的技术，就比如java调动多个功能最终实现一个功能。

2：技术都是由技术形成的，比如 火车的发明其中包含了多种技术，比如蒸汽技术，但蒸汽技术又可以分为燃料技术和动力技术。

3：技术和生物一样都会金华，但是生物的进化来自变异，而技术的进化则是来自不同技术组合所发生的变化

关于计算机技术，无论是前端还是后端，无论是过时的还是被炒的很热的，无论是云计算还是saas，技术本质都是来自之前已经存在的技术，都要求具备良好的算法和数据结构，在此基础上不断衍生新的技术。

程序员=算法+数据结构 一生二，二生三，三生万物，大道至简

挖掘本质

架构师要有将业务需求转化为技术需求的能力，这是一个本质的挖掘，例如业务层面看到的是一个电子商务网站系统，架构师看到的是一个多人在线，并发交易，需要保证数据一致性的站点，服务，数据系统，功能，性能，扩展性，维护性，安全性，可用性，可用性，这些字眼会跳到架构师的脑子里

架构师之所以为架构师，他在庞大的系统面前，仍然能够敏锐的发现其底层之真实，这需要架构师有多年领域知识和经验的沉淀。

技术广度：要成为百科全书

要全面了解各个层面的知识，了解主流公司的技术框架，碰到实际问题要有很快的评估出解决办法。

全面了解各个层面的知识

作为一各卓越的程序员，架构师肯定不缺开发方面的知识。从架构到方法论，从数据处理到安全监控，可以说IT层面上，架构师可以做到炉火纯青的地步，但是这仅仅是一个卓越程序员的能力级别，离架构师还有很大的距离。

架构师作为一名技术领袖，需要通过散发知识的光芒来温暖开发团队，如果只一个领域内的知识烂熟于心，那也仅仅是一名技术高手，要想更进一步，需要对APP层面，服务层面，数据层面均要了解，要对研发，测试，运维，安全也要有所涉及，上要对接口，下要对原理都有所了解，甚至多个业务领域也要有所涉猎。

如果多学习跨领域、跨学科的东西，会不会成为什么都懂，但什么都不精的人？其实在这里的跨领域，并不是要求大家成为每个领域的专家，最终的是有一门敲门砖，学习的引子。如果我们要开发金融系统，作为技术leader对财务结算及处理方法都不了解，是无法胜任架构师的任务的，甚至可能连普通程序员的工作都不可能做好，假设大家工作一段时间后，对某个领域很了解，但由于工作变动的缘故，到其他公司后开发的领域完全不会，这里就要用到跨领域知识学习的能力了，需要大家都要知晓。

对技术要有执着

谈到跨领域学习，知识面似乎是最好的实现目标，只要博览群书，加上高中之前的扎实的基础，相信大多数程序员是具备跨领域学习的能力。但是要想成为真正的百科全书的智者，恐怕不是简单的眼熟就OK的，在条件允许的情况下，程序员可以去参加一些领域的专业考试。通过压力让自己能钻进去学习。

了解主流公司的系统设计

碰到实际问题可以有很多种方案供评估

初级架构师所害怕的是跳出了自己的独门绝技，在一定程度上，在一定深度之内成为一个杂家，也没有什么不好的。

善于沟通的技术leader

沟通能力是确保各方对架构达成共识，愿意采取行动！

开发过程沟通

架构师必须参与项目开发过程，包括确认需求、系统分解、架构设计、技术选型、指定技术规格说明，系统实现，集成测试和部署各个阶段，在这一系列过程中，架构师会和各个部门进行沟通交流。

一个产品会有多个部门合作，架构师在其中的沟通极为重要，直接影响了产品的进度和质量。架构师不仅仅是要与开发人员沟通还要与项目经理，分析人员甚至用户进行沟通，来实现产品的各种可能性。

架构师和项目经理对沟通能力的要求都很高，很多互联网公司甚至有架构师担任项目经理的角色，这两个角色本质上是有所偏重的，项目经理更加侧重与客户进行交流，跨团队的协作和交流，架构师更多的偏向技术团队内部的沟通和交流，春技术上的沟通。

如何善于沟通

1：首先是平和，不能将自己锁在象牙塔上，颐指气使的发号施令，这样的态度必然遭受记恨，大家都是技术人员，只是分工不同，为什么要受你的气呢？

2：架构师要有一定的绘图能力，人对图形的理解远大于对文字的理解，一个层次图，一块小白板，一只笔，需要我们在平时就进行培养，写出大部分的架构树，有时候或许没有用VISIO画出的简单架构图好理解。人对图形的理解远远大于文字的理解。

召开小范围的技术人员会议，大家一起讨论

可以召开小范围的技术会议，大家一起讨论，一起理解架构师的真正意图，把问题摆清楚，讲明白，统一意见后团队必然干劲十足，再也不会出现相互推诿的事情。

架构师相当于一支球队的主教练，如何将自己的战术交给执行的球员，也就是开发人员的脑袋里，是关于胜利的关键。

系统性的思考：权衡利弊，只有合适没有喜欢

平衡取舍的能力是确保架构在现有资源约束下最合理，最理想最终照进现实。

全方位考虑问题

合格的技术leader都是一个好的战略家，前瞻性的眼光是起码要求，而系统性的思考则是将这些前瞻性眼光落地的必备素质。

架构既看重前瞻，又要看重落地，落不了地的架构只是空中楼阁，所以，如何让架构落地，考量的就是一个架构师的综合素质和系统思考能力。

架构的规划和落地依附了很多现有的环境因素在里面，所以好的技术leader要能够尽可能多的将对架构有过多权重影响的因素考量进来，然后做权衡，抓住重点因素，集中兵力重点突破。

比如，是采用传统的单体架构体系，还是时下风靡的微服务架构体系，要能够从团队人员层次和能力，组织和公司的发展现状，时机等重点因素中做出权衡，没法通过数据建模的手段去完成这个工作，能依靠的，只有综合素质和系统思考能力。

• 从时机上来说，如果单个应用结点就可以满足业务发展需求，那么，就没有必要上微服务，否则反而凭空整个交付链路负担。
• 如果团队的成员能力还不足以支撑起微服务体系相关的所用工具化，服务化和平台化建设，那么微服务架构也不是最合适的方向。
• 如果公司业务还处在四处拼杀，生死未卜的时候，公司的现状也不会允许去搞各种完善的基础性建设，活下来才是第一位的。

怎么办？说了那么多，应该怎么办？

高效的学习

如果想成为一个架构师或技术leader，就必须要走正确的路，否则只会离目标越来越远，正在辛苦的程序员们，有没有如下感觉？

一、我的工作就是按时完成领导交给我的任务，至于代码怎么样，知道有改进的空间，但是没有时间去改进，关键是领导也不给时间。

二、水平总是跟不上技术的进步，有太多的东西想要学，VUE用的最近比较多，听说了opendevs,

三、虽然工作几年了，除了不停的coding，ctrl+c和ctrl+v更加熟练，编码水平并没有提高，还是一个普通程序员，但身边已经有朋友做到架构师了。

四、工作好几年了，想跳槽，结果面试的考官问的都是数据结构，垃圾回收，设计模式这类的问题，虽然看过但是平时用不到，看了也忘记了，回答不上，所以面试官说我基础太差。

如果你有上面这几点，恭喜你，你已经进入学习误区，如果想在技术上不断前进，就不能一直的coding，为了完成需求而工作，必须在coding的同时，让我们的思维和水平也在不停的提升。

如果你想改变，可以看下我下面的建议，如果感觉是鸡汤请离开就是了，毕竟有鸡汤的基础是有鸡！

一，你必须学习面向对象的基础知识，如果连这个都忘记了，那你编程之路注定是做原始初级的重复

​ 为什么要面向对象，有哪些好处，要解决什么问题？语言的是不断发展的，从面向过程，面向对象，面向服务等，虽然在不断发展但是目标一致没变。

​ 1、降低软件开发复杂度

​ 2、提高软件开发效率

​ 3、提高软件质量：可维护性，可扩展性，可重用性。

二、要学好面向对象，就必须学习设计模式，给自己定个目标业余时间学习设计模式，并完成相应的博客和文章。

​ 面向对象和设计模式很多时候我们明白道理，但是一直排不上用场，不要着急设计模式的学习建议大家，将设计模式的案例代码思维先掌握，在应用中不断思考应用，切记为了学设计模式而过度设计。

三、学习重构

​ 精彩的代码怎么来的，这些大师也不是不用工作，需求来了没有领导规定完成时间，只以设计精彩的代码为标准来开展工作？这是老板不愿意的，就算这老板很理想，就一开始就是完美代码么？也不可能

​ 这里给大家推荐两本书《极限编程研究》《重构-改善既有代码设计》，我们在设计前期就使用设计模式往往会导致过度设计，因此要在开发过程中，这个需求变更过程中不断重构现有代码，才能让程序一直保持良好的设计，开发过程中需要一直重构，否则无论当初设计的多好，随着需求的改变，都会变成一堆烂代码，难以维护，难以扩展，重构就是这么一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构的目标就是设计模式。从本质上就是使程序的架构更趋合理，从而提高软件的可维护性，可扩展性，可重用性。

四：没有终点，只有坚持不懈的专研和努力

​ 经过几年的努力，终于可以灵活的使用各种设计模式，而不是刻意去想用什么模式，怎么重构，将一切成为习惯，一种思维观念。正确的路上，只要坚持，就离目标越来越近。

接下来小编会对十五次架构演变进行解读，另外经过长达半年多的准备已对从java基础到单体应用到微服务到ci\cd企业级技术栈已整理完毕，按照原计划五一之后会进行连载，请扫描下图关注个人公众号

本文使用 mdnice 排版