编辑 | 小智
踽踽独行高下求索总是痛楚，如果有良师良朋陪伴点拨必能事半功倍。重新手码农到高等架构师，要经由几步？要多努力，才能成为为人倚重的技能专家？本文将为你带来一张程序员发展路径图，但你须要知道的是，天下没有普适的道理，详细问题还需详细剖析，实践才能出真知。
架构师的“内功”
《从 0 开始学架构》专栏已经全部更新完毕，我在专栏里给你讲述了我的完全架构设计方法论，包括架构设计的观点、原则、步骤、技巧、模式等，这些内容是我领悟多年来的学习、实践、思考总结得出来的精华。“王婆自夸”一下，专栏就相称于一部《九阳真经》，你按照武功秘籍的方法去修炼，自然能够比站在村落口大树下打木人桩效率要高得多。然而要成为高手，光知道招式还远远不足，更主要的是内功和判断，能够一眼看出对手的弱点或者马脚，知道“什么时候用什么招式”“碰着什么对手用什么招式”更主要。
以架构设计原则的“得当原则”为例，专栏讲述了架构设计要遵照“得当原则”，不要过度设计，这个点非常关键，能够避免架构设计的时候盲目超前设计。但是我们在详细架构设计的时候，到底什么是“得当”，专栏也无法给出一个明确的标准可以放之四海而皆准去套用，由于“得当”和很多成分有关：业务发展、团队规模、技能实力、领导的喜好等。此时到底什么是“得当”就依赖架构师的“内功”了，很有可能同一个团队，A 架构师认为 X 方案是得当的，B 架构师认为 Y 方案是得当的，缘故原由就在于不同的架构师“内功”不一样。
我认为，架构师的内功紧张包含三部分：判断力、实行力、创新力，大略阐明如下：
判断力：能够准确判断系统的繁芜度在哪里，就像武侠高手一样，能准确地看出对手的马脚和弱点。
实行力：能够利用得当的方案办理繁芜度问题，就像武侠高手一样，能选择得当的招式或者方法打败对手。
创新力：能够创造新的办理方案办理繁芜度问题，就像武侠天下里，小一些的创新是创新招式，而武学宗师能够创立新的武学或者心法，例如张三丰创立太极拳一样。
因此，要成为一个精良的架构师，就须要不断地提升自己这几方面的内功，而这三方面的能力紧张来源于 履历、视野、思考。
履历：设计过的系统越多、系统越繁芜，架构师的内功也就越强，不管是成功的架构，还是失落败的架构，不管是踩坑的履历，还是填坑的履历，都将成为架构师内功的一部分。
视野：节制的知识和技能越多、越深，架构师的内功也就越强，他山之石可以攻玉，站在巨人的肩膀上会看的更高更远。
思考：履历和视野都是外部输入，类似于我们吃的食品，但光吃还弗成，还要消化，将其变为我们自己的营养，这便是思考的浸染。思考能够将履历和视野中的模式、判断、选择、技巧等提炼出来为我所用，思考也能匆匆使我们产生新的创意和灵感。
结合上面的剖析，从程序员到架构师的发展之路，总的辅导原则是：积累履历，拓宽视野，深度思考。按照这个总的原则为辅导，接下来我们看看从程序员到架构师的发展过程中，详细如何实践。
我把程序员到架构师的技能发展之路分为几个范例的阶段：工程师 - 高等工程师 - 技能专家 - 低级架构师 - 中级架构师 - 高等架构师。虽然总的辅导原则是一样的，但详细的实践方法有很大差别，如果在精确的阶段采纳了缺点的方法，可能会涌现事倍功半的问题。
工程师
阶段描述
成为一个合格的工程师须要 1~3 年韶光，其范例特色是“在别人的辅导下完成开拓”，这里的“别人”紧张是“高等工程师”或者“技能专家”，常日情形下，高等工程师或者技能专家卖力需求剖析和谈论、方案设计，工程师卖力编码实现，高等工程师或者技能专家会辅导工程师进行编码实现。
发展辅导
工程师阶段是最原始的“根本技能积累阶段”，紧张积累根本知识，包括编程措辞、编程工具、各种系统的基本利用。以 Java 后端工程师为例，工程师阶段须要积累的履历和技能有：
Java 的语法、基本数据构造的利用。
Eclipse、IDEA、Maven、Linux 命令行等各种工具。
数据库 CRUD 操作、缓存的基本利用等。
业务系统的基本流程。
工程师阶段最好的学习方法便是 找经典的书本系统地学习，而不要碰着一个问题到网上搜搜然后就办理了事。以 Java 为例，《Java 编程思想》《Java 核心技能》《TCP/IP 协议》这类大部头，一定要完全地看一遍，纵然里面很多内容当前事情暂时用不上。
高等工程师
阶段描述
发展为高等工程师须要 2~5 年韶光，其范例特色是“独立完成开拓”，包括需求剖析、方案设计、编码实现，个中需求剖析和方案设计已经包含了“判断”和“选择”，只是范围相对来说小一些，更多是在已有架构下进行设计。以 Java 后端工程师为例，高等工程师须要完成的事情包括：
MySQL 数据库表如何设计，是设计成两个表还是三个表？
是否要用缓存，缓存的 Key 和 Value 如何设计，缓存的更新策略是什么？
产品提出的需求是否合理？是否有更好的办法来知足？
发展辅导
从普通工程师发展为高等工程师，紧张须要“积累方案设计履历”，大略来说便是业务当前用到的干系技能的设计履历。以 Java 后端高等工程师为例，包括：表设计履历、缓存设计履历、业务流程设计履历、接口设计履历等。当接到一个业务需求的时候，高等工程师能够组合这些设计履历，终极完成业务需求。
高等工程师阶段比较工程师阶段，有两个范例的差异：
深度：如果说工程师是哀求知道 How，那高等工程师就哀求知道 Why 了。例如 Java 的各种数据构造的实现事理，由于只有深入节制了这些实现事理，才能对其优缺陷和利用场景有深刻理解，这样在做详细方案设计的时候才能选择得当的数据构造。
理论：理论便是古人总结出来的成熟的设计履历，例如数据库表设计的 3 个范式、面向工具的设计模式、SOLID 设计原则、缓存设计理论（缓存穿透、缓存雪崩、缓存热点）等。
针对技能深度，我的建议还是系统地学习，包括看书和研究源码。例如，研究 Java 虚拟机可以看《深入理解 Java 虚拟机》、研究 MySQL 可以看《MySQL 技能底细：InnoDB 存储引擎》、研究 Memcache 可以去看其源码。
针对设计理论，由于涉及的点很多，没有一本书能够涵盖这么多的设计点，因此更多的是依赖自己去网上搜索资料学习。那我们怎么知道哪些地方会有设计理论呢？大略来说，便是假设每个设计环节都有设计理论，然后带着这种假设去搜索验证看看是否真的有很熟的设计理念。
技能专家
阶段描述
发展为技能专家须要 4~8 年韶光，其范例的特色是“某个领域的专家”，普通地讲，只假如这个领域的问题，技能专家都可以办理。例如：Java 开拓专家、PHP 开拓专家、Android 开拓专家、iOS 开拓专家、前端开拓专家等。常日情形下，“领域”的范围不能太小，例如我们可以说“Java 开拓专家”，但不会说“Java 多线程专家”或“Java JDBC 专家”。
技能专家与高等工程师的一个范例差异便是，高等工程师紧张是在已有的架构框架下完成设计，而技能专家会根据须要修正、扩展、优化架构。例如，同样是 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 导向，创新技能很可能在抽芽阶段就被否定。
总 结
关于如何在专业领域内提升，有条著名的“10000 小时定律”，大略来说要成为某个领域顶尖的专业人才，须要持续不断 10000 小时的练习，例如小提琴、足球、国际象棋、围棋等领域，无一例外都遵照这个定律。我认为技能职员发展也基本遵照这个定律，我在文章中试图提炼一条通用的发展路径供你参考，但实在最关键的还是技能职员对技能的激情亲切以及持续不断地投入，包括学习、实践、思考、总结等。
末了，你可以统计一下自己从头到尾负责读过的技能书本数量、系统研究过的开源项目的数量，然后自我评估一下自己目前处于哪个层级，看看是否有什么创造？
特殊福利
订阅专栏，一次性得到专栏全集，附赠《架构师发展技能图谱》一份
老用户每约请一位好友购买，可以得到 24 元现金返现，上不封顶，立即提现。
用户沟通群已经开通，新老订阅用户皆可申请入群，申请办法请扫码查看专栏简介。
今日荐文
点击下方图片即可阅读
Netflix 的系统高可用履历
