程序员职业发展路径图：从菜鸟⼯程师到⾼级架构师（转）
踽踽独⾏上下求索总是痛苦，如果有良师益友陪伴点拨必能事半功倍。从新⼿码农到⾼级架构师，要经过⼏步？要多努⼒，才能成为为⼈倚重的技术专家？本⽂将为你带来⼀张程序员发展路径图，但你需要知道的是，天下没有普适的道理，具体问题还需具体分析，实践才能出真知。
架构师的“内功”
以架构设计原则的“合适原则”为例，专栏讲述了架构设计要遵循“合适原则”，不要过度设计，这个点⾮常关键，能够避免架构设计的时候盲⽬超前设计。但是我们在具体架构设计的时候，到底什么是“合适”，专栏也⽆法给出⼀个明确的标准可以放之四海⽽皆准去套⽤，因为“合适”和很多因素有关：业务发展、团队规模、技术实⼒、领导的喜好等。此时到底什么是“合适”就依赖架构师的“内功”了，很有可能同⼀个团队，A 架构师认为 X ⽅案是合适的，B 架构师认为 Y ⽅案是合适的，原因就在于不同的架构师“内功”不⼀样。
我认为，架构师的内功主要包含三部分：判断⼒、执⾏⼒、创新⼒，简单解释如下：
判断⼒： 能够准确判断系统的复杂度在哪⾥，就像武侠⾼⼿⼀样，能准确地看出对⼿的破绽和弱点。
执⾏⼒： 能够使⽤合适的⽅案解决复杂度问题，就像武侠⾼⼿⼀样，能选择合适的招式或者⽅法打败对
⼿。
创新⼒： 能够创造新的解决⽅案解决复杂度问题，就像武侠世界⾥，⼩⼀些的创新是创新招式，⽽武学宗师能够创⽴新的武学或者⼼法，例如张三丰创⽴太极拳⼀样。
因此，要成为⼀个优秀的架构师，就需要不断地提升⾃⼰这⼏⽅⾯的内功，⽽这三⽅⾯的能⼒主要来源于 经验、视野、思考。
1. 经验： 设计过的系统越多、系统越复杂，架构师的内功也就越强，不管是成功的架构，还是失败的架构，不管是踩坑的经验，还是填坑的经验，
都将成为架构师内功的⼀部分。
2. 视野： 掌握的知识和技能越多、越深，架构师的内功也就越强，他⼭之⽯可以攻⽟，站在巨⼈的肩膀上会看的更⾼更远。
3. 思考： 经验和视野都是外部输⼊，类似于我们吃的⾷物，但光吃还不⾏，还要消化，将其变为我们⾃⼰的营养，这就是思考的作⽤。思考能够将
经验和视野中的模式、判断、选择、技巧等提炼出来为我所⽤，思考也能促使我们产⽣新的创意和灵感。
结合上⾯的分析，从程序员到架构师的成长之路，总的指导原则是：积累经验，拓宽视野，深度思考。按照这个总的原则为指导，接下来我们看看从程序员到架构师的成长过程中，具体如何实践。
我把程序员到架构师的技术成长之路分为⼏个典型的阶段：⼯程师 - ⾼级⼯程师 - 技术专家 - 初级架构师 - 中级架构师 - ⾼级架构师。
虽然总的指导原则是⼀样的，但具体的实践⽅法有很⼤差别，如果在正确的阶段采取了错误的⽅法，可能会出现事倍功半的问题。
⼯程师
阶段描述
成为⼀个合格的⼯程师需要 1~3 年时间，其典型特征是“在别⼈的指导下完成开发”，这⾥的“别⼈”主要是“⾼级⼯程师”或者“技术专家”，通常情况下，⾼级⼯程师或者技术专家负责需求分析和讨论、⽅案设计，⼯程师负责编码实现，⾼级⼯程师或者技术专家会指导⼯程师进⾏编码实现。
⼯程师阶段是最原始的“基础技能积累阶段”，主要积累基础知识，包括编程语⾔、编程⼯具、各类系统的基本使⽤。以 Java 后端⼯程师为例，⼯程师阶段需要积累的经验和技能有：
1. Java 的语法、基本数据结构的使⽤。
2. Eclipse、IDEA、Maven、Linux 命令⾏等各种⼯具。
3. 数据库 CRUD 操作、缓存的基本使⽤等。
4. 业务系统的基本流程。
⼯程师阶段最好的学习⽅法就是 经典的书籍系统地学习，⽽不要遇到⼀个问题到⽹上搜搜然后就解决了事。以 Java 为例，《Java 编程思想》《Java 核⼼技术》《TCP/IP 协议》这类⼤部头，⼀定要完整地看⼀遍，即使⾥⾯很多内容当前⼯作暂时⽤不上。
⾼级⼯程师
阶段描述
成长为⾼级⼯程师需要 2~5 年时间，其典型特征是“独⽴完成开发”，包括需求分析、⽅案设计、编码实现，其中需求分析和⽅案设计已经包含了“判断”和“选择”，只是范围相对来说⼩⼀些，更多是在已有架构下进⾏设计。以 Java 后端⼯程师为例，⾼级⼯程师需要完成的⼯作包括：
1. MySQL 数据库表如何设计，是设计成两个表还是三个表？
2. 是否要⽤缓存，缓存的 Key 和 Value 如何设计，缓存的更新策略是什么？
3. 产品提出的需求是否合理？是否有更好的⽅式来满⾜？
成长指导
从普通⼯程师成长为⾼级⼯程师，主要需要“积累⽅案设计经验”，简单来说就是业务当前⽤到的相关技术的设计经验。以 Java 后端⾼级⼯程师为例，包括：表设计经验、缓存设计经验、业务流程设计经验、接⼝设计经验等。当接到⼀个业务需求的时候，⾼级⼯程师能够组合这些设计经验，最终完成业务需求。
⾼级⼯程师阶段相⽐⼯程师阶段，有两个典型的差异：
1. 深度：如果说⼯程师是要求知道 How，那⾼级⼯程师就要求知道 Why 了。例如 Java 的各种数据结构的实现原理，因为只有深⼊掌握了这些实
现原理，才能对其优缺点和使⽤场景有深刻理解，这样在做具体⽅案设计的时候才能选择合适的数据结构。
2. 理论：理论就是前⼈总结出来的成熟的设计经验，例如数据库表设计的 3 个范式、⾯向对象的设计模式、SOLID 设计原则、缓存设计理论（缓存
穿透、缓存雪崩、缓存热点）等。
3. 针对技术深度，我的建议还是系统地学习，包括看书和研究源码。例如，研究 Java 虚拟机可以看《深⼊理解 Java 虚拟机》、研究 MySQL 可以
看《MySQL 技术内幕：InnoDB 存储引擎》、研究 Memcache 可以去看其源码。
4. 针对设计理论，由于涉及的点很多，没有⼀本书能够涵盖这么多的设计点，因此更多的是依靠⾃⼰去⽹上搜索资料学习。那我们怎么知道哪些地⽅
会有设计理论呢？简单来说，就是假设每个设计环节都有设计理论，然后带着这种假设去搜索验证看看是否真的有很熟的设计理念。
技术专家
阶段描述
成长为技术专家需要 4~8 年时间，其典型的特征是“某个领域的专家”，通俗地讲，只要是这个领域的问题，技术专家都可以解决。
例如：Java 开发专家、PHP 开发专家、Android 开发专家、iOS 开发专家、前端开发专家等。通常情况下，“领域”的范围不能太⼩，例如我们可以说“Java 开发专家”，但不会说“Java 多线程专家”或“Java JDBC 专家”。
技术专家与⾼级⼯程师的⼀个典型区别就是，⾼级⼯程师主要是在已有的架构框架下完成设计，⽽技术专家会根据需要修改、扩展、优化架构。例如，同样是 Java 开发，⾼级⼯程师关注的是如何优化 MySQL 的查询性能，⽽技术专家可能就会考虑引⼊
Elasticsearch 来完成搜索。
从⾼级⼯程师成长为技术专家，主要需要“拓展技术宽度”，因为⼀个“领域”必然会涉及众多的技术⾯。以 Java 后端开发为例，要成为⼀个 Java 开发专家，需要掌握 Java 多线程、JDBC、Java 虚拟机、⾯向对象、设计模式、Netty、Elasticsearch、Memcache、Redis、MySQL 等众多技术。常见的拓展技术宽度的⽅法有：
1. 学习业界成熟的开源⽅案，例如，Java 开发可以去学习 Redis、Memcache、Netty 等，Android 开发可以去研究 Retrofit、Fresco、
OkHttp 等。
2. 研究业界的经验分享，例如 BAT、FANG 等⼤公司的经验，可以通过参加技术⼤会等⽅式去近距离了解。
3. 需要注意的是，拓展技术宽度并不意味着仅仅只是知道⼀个技术名词，⽽是要深⼊去理解每个技术
的原理、优缺点、应⽤场景，否则就会成为传说
中的“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 也可以很好地完成，备选⽅案设计和选择并不太难，更多的是看团队熟悉哪个技术。
成长指导
从技术专家成长为初级架构师，最主要的是形成⾃⼰的“架构设计⽅法论”，我的架构设计专栏其实就是讲述完整的架构设计⽅法论，包括架构设计⽬的、架构设计原则、架构设计步骤、架构设计模式等，类似的架构设计⽅法论还有《恰如其分的软件架构：风险驱动的设计⽅法》和《领域驱动设计》等。
1. 要形成⾃⼰的架构设计⽅法论，主要的⼿段有：
2. 系统学习架构设计⽅法论，包括订阅专栏或者阅读书籍等。
3. 深⼊研究成熟开源系统的架构设计，这个⼿段在技术专家阶段也会⽤到，但关注点不⼀样，同样是研究开源系统，技术专家阶段聚焦于如何更好地
应⽤开源项⽬；初级架构师阶段聚焦于学习其架构设计原理和思想，例如 Kafka 的⽂档中就有关于消息队列架构设计的分析和取舍。
4. 结合架构设计⽅法论，分析和总结⾃⼰团队甚⾄公司的各种系统的架构设计优缺点，尝试思考架构重构⽅案。如果在这个基础上真的能够推动架构
重构，那就更好了，既能够实践⾃⼰的架构设计⽅法论，同时积累经验，⼜能够展现⾃⼰的技术实⼒，拿到结果。
中级架构师
阶段描述
成长为中级架构师需要 8 年以上时间，其典型特征是“能够完成复杂系统的架构设计”，包含⾼性能、⾼可⽤、可扩展、海量存储等复杂系统，例如设计⼀个和 Kafka 性能匹敌的消息队列系统、将业务改造为异地多活、设计⼀个总共 100 ⼈参与开发的业务系统等。
中级架构师与初级架构师的典型区别在于系统复杂度的不同，中级架构师⾯对的系统复杂度要⾼于初级架构师。以开源项⽬为例，初级架构师可能引⼊某个开源项⽬就可以完成架构设计，⽽中级架构师可能发现其实没有哪个开源项⽬是合适的，⽽需要⾃⼰开发⼀个全新的项⽬，事实上很多开源项⽬就是这样诞⽣出来的。
成长指导
从初级架构师成长为中级架构师，最关键的是“技术深度和技术理论的积累”，例如：
1. 技术理论：CAP、BASE 是异地多活的设计理论基础、Paxos 是分布式⼀致性的基础算法、2PC、3PC 是分布式事务的基础算法等。
2. 技术深度：Kafka ⽤磁盘存储还能做到⾼效是因为磁盘顺序写；Disruptor ⾼性能是结合 CPU 预读取机制、缓存⾏、⽆锁设计等基础技术；
Storm 的⾼效异或确认机制；Flink 的分布式快照算法等。
3. 很多同学对这点可能有疑问，这些技术理论和技术深度的事情不应该是⾼级⼯程师阶段或者技术专家阶段就应该积累的么？为何到了中级架构师阶
段反⽽是成长的关键了呢？主要原因在于⾼级⼯程师或者技术专家阶段即使去学习这些技术，实际上也⽐较难理解透彻，更加难以有机会去应⽤，更多的时候只是了解有这个技术点⽽已；⽽到了中级架构师阶段，⾯对⾼复杂度的系统，很多时候就是⼏个关键技术细节决定整个架构设计的成败，或者某个设计⽅案理论上就是不可⾏的，如果不深刻理解理论和相关的关键技术点，很难设计优秀的架构。
4. 以我做过的异地多活设计⽅案为例，之前很早我就知道 CAP 理论了，但也仅仅只是知道⼏个概念⽽已。真正做异地多活的时候，开始的时候还是
⾛了不少弯路，试图做⼀个完美的异地多活系统，最终发现这其实是不可能的，某天突然顿悟：其实 CAP 理论已经明确指出来了这点，但最初学习 CAP 理论的时候，很难有这样深刻的理解。
⾼级架构师
阶段描述
成长为⾼级架构师需要 10 年以上时间，其典型特征是“创造新的架构模式”，例如：
1. ⾕歌⼤数据论⽂，创造了分布式存储架构、分布式计算 MapReduce 架构、列式存储架构，开创了⼤数据时代。
2. 在有 MapReduce 分布式计算架构的背景下，Storm ⼜创造了流式计算架构。
3. 在虚拟机很成熟的背景下，Docker 创造了容器化的技术潮流。
4. ⾼级架构师与中级架构师相⽐，典型区别在于“创造性”，⾼级架构师能够创造新的架构模式，开创新的技术潮流。
成长指导
坦⽩的说，对于从中级架构师如何才能成长为⾼级架构师，我并没有太好的指导，⼀个原因是我⾃我评价⽬前顶多算个中级架构师；
另外⼀个原因是⼀旦涉及“创造性”，其实和艺术就⽐较类似了，创造性实际上是很难学会的，也很难由⽼师教会，更多是天分，或者某种场景下灵感爆发。
参考技术界⼏个创造性的架构案例，我总结出⼏个可能诞⽣创造性架构的背景条件：
1. ⾜够复杂的业务场景：例如⾕歌的⼤数据、阿⾥的双⼗⼀、Facebook 的海量⽤户等，业务场景越复杂，给技术带来的挑战更⼤，更有可能产⽣创
造性的技术突破。
高级java程序员掌握技能
2. ⾜够强⼤的技术团队：绝⼤部分创造性的架构都来源于⼤公司，或者知名的研究机构；没有技术实⼒⽀撑，想突破也是⼼有余⽽⼒不⾜。
3. 不满⾜于现状的态度：例如虚拟机很成熟但是资源占⽤太多，所以发明 Docker；MapReduce 难以做到实时运算，所以创造 Storm 流式运算。
4. 尊重技术价值的⽂化：创造性的东西往往需要投⼊⼤量的⼈⼒和时间，⽽且刚开始⼀般都不会很成熟，如果完全结果导向、KPI 导向，创新技术很
可能在萌芽阶段就被否定。
总结
关于如何在专业领域内提升，有条著名的“10000 ⼩时定律”，简单来说要成为某个领域顶尖的专业⼈才，需要持续不断 10000 ⼩时的练习，例如⼩提琴、⾜球、国际象棋、围棋等领域，⽆⼀例外都遵循这个定律。我认为技术⼈员成长也基本遵循这个定律，我在⽂章中试图提炼⼀条通⽤的成长路径供你参考，但其实最关键的还是技术⼈员对技术的热情以及持续不断地投⼊，包括学习、实践、思考、总结等。最后，你可以统计⼀下⾃⼰从头到尾认真读过的技术书籍数量、系统研究过的开源项⽬的数量，然后⾃我评估⼀下⾃⼰⽬前处于哪个层级，看看是否有什么发现？

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。