成长为软件架构师不是一件容易的事，这篇文章列举了架构师需要学习的技术储备，给出了成为软件架构师的路线图，帮助有志于在架构领域成长的同学可以明确学习的方向。原文：Master Plan for becoming a Software Architect[1]
软件架构师在软件开发团队中扮演着高级的角色，这一角色需要时间和经验的积累，需要跨职能的技能和知识。除了技术方面的挑战，还要求架构师具备良好的社交能力。在开始考虑成为软件架构师的计划之前，我们先来看看典型的软件架构师类型：
- 解决方案架构师/软件架构师（Solution Architect/Software Architect） —— 低级架构师，通常由之前或现在的高级软件工程师担任，负责与业务人员沟通产品的技术设计和架构，开发人员通常都可胜任。
- 企业级架构师（Enterprise Architect） —— 高级架构师，把控产品“大局”，但很少关注细节。这个职位大多出现在非常复杂的大型软件产品中，有时甚至直接汇报给CTO。
- 领域架构师（Domain Architect） —— 这是比较流行的软件架构师类型，在很多公司都可以看到。这个职位的目的是成为特定用例或技术栈的架构师。例如:云架构师负责特定的云供应商，数据架构师负责数据库的操作、设计、协调，移动架构师负责软件产品的移动版本，等等等等……
- 业务架构师（Functional Architect） —— 这类架构师主要负责业务方面，对技术世界了解较少，大多是经验丰富的业务分析师，设计并领导软件产品的业务逻辑。
我们可以进一步扩展这个列表，每个公司可能对某个特定职位有不同的名称。上述给定的软件架构职位的角色和职责可能因公司而异，但本质是相同的。请看下面的图表，以便更好的理解不同架构师角色在技术/业务技能和知识方面的关系。
业务与技术关系图
总体规划
到目前为止，有一件事应该非常清楚: 除了那些真正来自业务背景的人，软件架构师通常是超级高级开发人员。下面是软件架构师应该熟悉的不同主题领域:
- 数据结构和算法 —— 基本的编程原理对软件架构师来说应该不成问题，包括数组、队列、栈、链表、不同类型的树、图等数据结构，软件架构师不仅应该熟悉，而且应该能够识别出在什么时候应该使用哪个数据结构。优秀的软件架构师应该知道不同的算法，如搜索、排序、递归、动态规划等。在日常生活中，没有架构师会从头开始编写“合并排序”算法，或者发明新的数据结构。《算法导论》是一本全方位介绍算法和数据结构的经典作品。
- 技术栈 —— 无论是后端还是前端，软件架构师必须非常了解当前使用的技术栈。学习特定编程语言的语法是最简单的方法，但需要时间积累经验。不同的库和框架也是值得了解的宝贵资产。
- 简洁的编码 —— 让软件系统工作并不是软件架构师的最终目标。每次评审代码时，他/她首先想到的问题是: 我能使这段代码更高效吗? 我能让代码占用更少内存吗? 简洁的代码标准是否被正确应用? 我可以使用不同的OOP技术吗? 《代码整洁之道》无疑可以帮助我们提高重构技能。
- OOP —— 面向对象编程帮助我们可以构建更灵活、高效、可读性高的软件系统。有经验的软件架构师会经常使用这些技术(如果技术堆栈合适……)。
- 软件设计模式 —— 说到面向对象，不应该忘记不同的设计模式的重要性，它们首先是由GoF[2]收集和引入的。了解这些设计模式肯定会帮助我们更好的利用软件系统的面向对象设计。
-
S.O.L.I.D.原则 —— 这一组件原则是软件组件设计中需要考虑的基本技术。有经验的软件架构师如果掌握了这些原则，可以很快识别出代码中的违规行为。
-
高内聚/低耦合原则 —— REP、CRP、ADP等原则对于软件架构师来说非常重要，尤其是在构建、整合/解耦插件时，这些技术可以处理更高级的设计。
-
系统设计 —— 有很多软件体系架构模式，如:主从、客户端-服务器、微服务、MVC、单向体系架构等，需要根据不同的前后端项目做出选择。当然不太可能有人能够掌握所有这些模式，但是根据项目的不同，软件架构师应该精通底层设计，领域驱动设计可以作为最基本的出发点。
-
文档 —— 这是软件架构师日常工作中的重要环节。绘制不同的UML图，ARC42文档是这个职位不可避免的工作。这方面有很多工具，如:draw.io[3] —— 简单易用的免费工具
- PlantUML[4] —— 提供Eclipse、Intellij等IDE插件，可以通过脚本绘图，非常有用，也是我最喜欢的工具。yEd[5] —— 很方便的工具，可作为桌面应用程序运行。
- 证书 —— 对于软件架构师来说，没有太多的认证选择，但国际软件架构资格认证委员会(iSAQB®)提供了Certified Professional for Software Architecture(CPSA®)认证计划，该认证得到全球认可。
