转载

BAT资深架构师告诉你从程序员到架构师，你需要掌握什么能力？

![image.png](https://static.studygolang.com/181229/483d6bef49555019e8ff91234a5e2ceb.png) 1、开发者和架构师之间最大的区别是什么？架构师和开发者一样，也经常写代码，简单的说，开发者和架构师之间最大的区别就是技术领导力。软件架构师的角色需要理解最重要的架构驱动力是什么，他提供的设计需要考虑这些因素。架构师还要控制技术风险，在需要的时候积极演化架构，并且负责技术质量保证。从根本上讲，架构师是一个技术领导者的角色，这就是最大的区别。 2、一位开发者如何才能成为一位架构师？他/她需要掌握哪些领域之外的能力？两个字：经验。我认识的大部分优秀软件架构师同时也是出色的软件开发者，他们都是经过时间逐渐发展成为架构师的。你需要有退后一步看代码的能力，从而理解特定软件系统背后的设计决策。退后一步才能看到“大局”，这是架构师必须掌握的核心技能。 3、你对软件架构的理解是否因为你的经历和实践而改变过？是的。我对软件架构的理解是根据我在咨询公司工作时在各个项目中负责软件架构的经验形成的。咨询是一件好事，尤其从最近我开始从事独立咨询师这个工作之后，我可以看到很多不同的团队，不同的架构，不同的技术，以及人们不同的工作方式。世界各地的文化多样性又为工作的复杂度增加了一个维度。无论是寻找特定问题解决方案的过程，还是为各种想法去芜存菁的过程，这些经验和与我共事的人的反馈一起最终形成了我今天对软件架构的认识，这些思维也反应在了我的书中。 4、有没有什么事是架构师永远都不应该做的？有，软件架构师永远都不应该停止编程和停止学习！程序员从初级走向资深的过程中，会面临两个支路，一个叫技术主管，另一个则是架构师。总结程序员到架构师之路的忠告： 1、程序就是一切。文档是紧接其后的事情。因此，把你们的代码写成本身就是文档，而且要好用。 2、测试测试测试。重要的事情说三遍。 3、单元测试要严格。任何一个单元测试中发现的bug都负担了开发人员成本外的双重代价。你们要知道，我宁愿给你们更多的薪水也不愿找别的QA公司来测试、让你们修改bug。但如果你的程序写的很差，那我只好把这些钱由这些人平摊，你们只能得到其中很小的一块蛋糕。 4、写出好代码要能给人类阅读，给CPU使用。绝对不能向烂代码低头。 5、阅读更多的知识，不要局限于目前的工作所需。如果你只掌握今天需要的知识而不知明天需要的，你不会有发展进步。 6、回家不时的做做饭。是的，真的饭。这会让你知按照菜谱做饭和自己创造一顿饭之间的区别。前者是在做饭前已经知道了需要什么，而后者是根据你目前有的来做 … 就这一点点不同。 7、抽象的能力，抽象思考的能力怎么强调都不为过。现实的需求纷繁复杂，如果架构师不能够把这些乱无头绪的需求抽象成一些“概念”，在概念的层次进行思考，系统根本就无法设计。 8、技术领导力，要用技术的影响力来领导人，而不是威权和职位。换句大白话来说，就是要能让技术人员服你。有了技术影响力，你在团队发出的声音才会被倾听，被尊重。为什么大多数人不是架构师？架构师，程序员，产品经理的区别，大概就是建筑行业里建筑师，建筑工人，甲方业主的区别。产品经理说我要建这么这么一栋楼，架构师说好吧，我来帮你看看是做成砖木结构还是框架结构，房型怎么设计，水电气怎么布局，预算多少，然后程序员上阵，按照图纸把楼建起来。运营是大楼的物业管理，负责营运大楼。软件开发越来越成为传统行业（即便在互联网企业），一个成熟的软件团队内部自然会分化出这些角色，各展所长。但非常不同的是，建筑工人很少能自发成长为建筑师，后者都是科班出身，因为建筑学科已经高度发达，需要掌握结构力学，美学等技术，现在软件行业还没有这么高的成熟度，程序员和架构师接受的都是一样的计算机教育，所以程序员可以自学升级到架构师，走一条不同的升级打怪路线。那么，架构师是什么人呢？按所工作的不同软件层分，有网络架构，系统架构，数据架构，业务架构，应用架构，平台架构。按所解决的问题领域分，有电商架构，支付架构，搜索架构，安全架构，性能架构，游戏架构，多媒体架构，等等等。按其工作的深度来分，有集成架构，业务架构，模块架构，框架架构，中间件架构，软件架构，引擎架构，服务器架构，甚至编程语言架构。是不是太乱了？好比在设计师的世界观里一切东西都需要设计。软件也需要精心设计，在优秀的程序员眼里，每一行代码都需要架构！都体现了架构。为了解决问题，程序员自然需要架构，他们中的佼佼者被冠以架构师的名号，获得了一定的话语权，逐步成为一个职业分工，我想，这就是架构师的本来面目。那么从一名程序员到架构师有需要掌握哪些技术呢。一、开源框架解析程序员每天都和代码打交道。经过数年的基础教育和职业培训，大部分程序员都会「写」代码，或者至少会抄代码和改代码。但是，会读代码的并不在多数，会读代码又真正读懂一些大项目的源码的，少之又少。这也造成了很多错误看源码的方式。那要如何正确的分析源码呢？我们的目标应该放在最常用的框架上面： ![image.png](https://static.studygolang.com/181229/843f228054aa516824fbf783b7d2799d.png) 二、架构师筑基从架构设计，到应用层调优，再深入了解底层原理，扎实的Java基本功才能让自己变为扫地神僧：内存模型，并发模式，线程模型，锁细节等等 ![image.png](https://static.studygolang.com/181229/f760bdddc0a14933232a9689f7e3d094.png) 三、高性能架构我们不仅仅对项目要运筹帷幄，还要能解决一切性能问题。只有深入学习JVM底层原理，Mysql底层优化以及Tomcat调优，才能达到知其然，知其所以然的效果。除了性能优化之外，也能提供通用的常见思路以及方案选型的考虑点，帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。 ![image.png](https://static.studygolang.com/181229/f760bdddc0a14933232a9689f7e3d094.png) ![image.png](https://static.studygolang.com/181229/202398e7126ac06919b476ec1aa72f5e.png) ![image.png](https://static.studygolang.com/181229/e8960bd57f1fa8fcaff081e6ea30ce18.png) 四、微服务架构关于微服务架构的取舍 ![image.png](https://static.studygolang.com/181229/1a5b37cd03edf853bd125ca176930d63.png) 在合适的项目，合适的团队，采用微服务架构收益会大于成本。微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。五、团队协作开发工具工程化通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。程序员的战斗，往往不是一个人的战斗，我们如何在一个平台下高效的去重，进行代码review，对功能进行调整，debug，做到在统一的规划下步步为营，混乱的堆代码的过程中找到自己的记录。这一切都依赖于有效的工具。 ![image.png](https://static.studygolang.com/181229/1a5b37cd03edf853bd125ca176930d63.png) 六、B2C项目实战项目实战要想立足于互联网公司，且能在互联网浪潮中不被淹没，对于项目的开发实战演练是不必可少的技能，也是对自身能力的一个衡量，有多少的量对等于获得多少的回报。看似简单的一个项目需求图谱，其中的底层原理，实现原理又能知道多少？你搭建一个完整的B2C项目平台到底需要多少知识？这一切都是需要我们考量的。 ![image.png](https://static.studygolang.com/181229/c944c912080051c436ad23ff2b5b21b1.png) 对于才学基础的朋友可能用处不大，我相信对于开发多年的朋友这六大模式帮助会很大，对于这六大模式我也总结了一套学习资料，在技术上面想提升自己的朋友可以加群828545509获取资料（免费资料Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系）点击链接加入群聊【Java高级架构师学习群】：https://jq.qq.com/?_wv=1027&k=5T2kMGl ![image.png](https://static.studygolang.com/181229/0a65feec89d43b39d60165abc779eea0.png)

原文 https://studygolang.com/articles/17319

正文到此结束