“
我怎么才能成为一个软件架构师
？”
这是很多小伙伴问我的一个问题，最近看到Kai Niklas讲架构师的一篇文章，其中的真知灼见引起了我的强烈共鸣，尤其是后面的非技术部分。翻译过来（略有删减），分享给大家。
我事先给一位同学看了一下，他说：当个架构师太难了吧，又要精通技术，还得会沟通，平衡，营销..... 我还是争取做个技术专家吧！
扪心自问，我这个架构师在很多方面也做得远远不够，继续学习吧！如果你的未来职业目标是架构师，强烈建议仔细阅读并收藏。
在我们一头扎入细节之前，我们先得知道软件架构和架构师到底是什么：
软件架构师
是一个软件专家，他可以做出高层的设计决定，规定技术标准，包括编码标准，工具和平台 -- Wikipedia
软件架构
是一个系统最基本的组织方式，由其组件，组件之间的关系，组件和环境的关系表达出来。也包括决定设计和系统演化的原则。--Handbook of Software Architecture
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
-
视频教程：https://doc.iocoder.cn/video/
架构可以在不同的抽象级别上完成， 不同的级别要求不同技能，有很多分类标准，我最喜欢的是这三个级别：
Application Level （应用级别）
：架构的最低级别，专注于单个应用，有非常具体的设计，沟通通常局限在开发团队
Solution Level （解决方案级别）
：架构的中间层，需要关注几个应用来实现一个商业的需求，有部分高层的设计，但大多数还是具体的设计，沟通需要跨越多个开发团队。
Enterprise Level (企业级别)
：架构的最高级， 关注多个解决方案，这一层的设计比较抽象，需要解决方案架构师和应用架构师去细化。沟通跨越整个企业组织。
有时候，架构师被看作不同利益相关者之间的粘合剂，比如：
水平方向：在业务人员和开发人员建立沟通的桥梁
垂直方向：在开发人员和经理之间建立沟通桥梁
技术领域：集成不同的技术和应用。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
-
视频教程：https://doc.iocoder.cn/video/
为了理解软件架构师需要哪些技能，我们得先来看看架构师的日常活动
-
-
确定开发标准和规范：编码标准，工具，评审流程，测试方法等
-
-
-
-
检查、评审架构设计和代码，比如看看确定的模式和代码标准是否正确施行
-
-
注: 架构设计是一个持续的活动，所以这些活动会一遍一遍地完成。
软件架构师所需的重要技能
根据我的经验，阅读的书籍，以及参与的讨论，我可以列出这10个技能，每个架构师都必须具备：
设计, 决策，简化, 编码, 文档, 沟通, 估算, 平衡, 咨询, 营销
我们一个个来说，对每个技能我都会列出一些我的见解，你应该采取的行动，以便在这个技能领域持续提高。
是什么造就了好的设计？这可能是最重要，并且最具挑战性的问题，让我们先从理论开始。
理解基本的设计模式
：为了开发一个可维护的系统，模式绝对是架构师最重要的工具之一，使用模式，你可以复用设计来决定那些通用的问题。“四人帮”的《设计模式：可复用的面向对象软件基础》是每个开发人员的必读书籍。尽管过去20多年了，模式依然是软件架构的基本单元。
比如书中描述的MVC模式被应用在很多领域，也是很多新模式如MVVM的基础。
深入挖掘模式和反模式：
理解了基本的“四人帮”模式以后，你需要把你知识扩展到更多的软件设计模式中，或者根据自己的兴趣，深入研究，例如Java并发模式。
在应用程序的集成领域， 我最喜欢的是《企业集成模式》，这本书适用于各种领域，只要两个应用需要交换数据，不管是很古老的基于文件的交换还是现代的微服务架构，都可以参考本书。
了解软件质量的度量方式
：我们希望我们的系统是可以维护的、可靠的、安全的、可以测试的、可以扩展的、可用的...... 为了达成这些目标，必须要把系统架构设计好。你可以参考这个：
理论很重要，实践更加重要，否则你就会变成一个象牙塔架构师。
不断尝试和理解不同的技术栈
：我认为这是成为架构师非常重要的事情， 你很难从抽象的PPT中学到真东西，你得尝试不同的、新的技术栈，亲自感受一下它带来的好处和引发的“疼痛”。另外也可以尝试不属于你所在领域的技术，例如你对SAP R/3 非常擅长，那你应该也试试JavaScript。
分析、理解那些应用良好的模式
：看看你当前使用的框架，例如Angular， 你可以研究很多以及付诸实践的模式，如观察者。看看它是怎么在框架中使用的，为什么要这么使用。如果你愿意投入更多的精力，那就深入源代码看看它是如何实现的。
保持好奇心，参加一些公司之外的社团活动
：比如Java User Group会讨论很多主题，从最底层的编码到高层的架构，我很喜欢这样的活动，因为它会让我跳出工作来思考，并且加强个人社交网络。
架构师需要能够做出架构决定，引导项目和组织走在正确的方向。
确定优先级
：有些决策非常关键，如果没有在早期确定下来，就会出现一些变通的临时措施，导致后续难以移除，变成维护的噩梦。更差的情况是，程序员需要停止工作，等你做出决策。
为了避免这种情况，必须要把这些决策按优先级排序，我建议看一看敏捷软件开发中非常流行的Weighted Shortest Job First (WSJF) 模型。
了解你的能力
：不要在你的能力之外做决定，这非常关键，如果你不遵循的话可能会毁掉你架构师的岗位。
所以一定要和你的同伴明确你承担的职责和你的角色。作为低级别的架构师，你可以提出对高层架构的建议，但是不要擅自做主。我建议要经常和同伴审视那些关键的架构决定。
评估多个选项
：涉及到决策时，要列出多个选项。在我参与的大多数决策中，都有不止一个可能（好的）选择。仅仅提供一个选项说明你没有完成自己的工作，没法完成决策。各种选项要通过可以度量的事实（如许可证费用，成熟度）而不是个人感情来比较，这样才能真正完成决策。
要谨记解决问题的奥卡姆剃刀原则：
如无必要，勿增实体。
对于一个问题，如果你有太多的假设，很可能会走向一个错误的方向，导致不必要的、复杂的解决方案。一定要精简假设来生成好的解决方案。（可见架构工作也是一门艺术）
“摇动”你的架构设计
：为了让架构设计更加简单，可以从多个角度去审视解决方案，不但要以自顶向下的方式思考，还要自底向上的方式再来一遍， 如果你有数据流或者业务流程，先从左向右看，然后再从右往左看。
经常问自己：“在一个理想的环境中，架构设计会是怎么样呢？” “如果是那些大公司，它们会怎么做呢？” 这些问题会促使你减少假设。
退后一步
：经常长时间的密集讨论，通常会得到一个高度复杂的设计，你绝对不能把它们当作最终结果，退后一步，从抽象的级别看看全局的图景，这设计还是有意义的吗？
有时候停止讨论，第二天再继续会有帮助，至少我的大脑需要时间来处理这些信息，然后提出更好的，更优雅的，更简单的方案。
分而治之
：将大问题分成小块儿，逐个解决，然后看看小块儿解决方案能不能匹配起来。
重构并不邪恶
：如果找不到更好的设计，从一个复杂的解决方案开始也是可以的。如果后面遇到了问题，你需要回过头来再想一想，重构并不是邪恶的，但是再开始重构之前要确保 ：
(1）足够的自动化的测试用例，保证系统的功能不被破坏
(2) 获取利益相关者的认可。
即使是贵为企业级架构师，也就是抽象级别最高的架构师，你也得知道程序员日常工作在做些什么。否则你会遇到两个问题：
(1) 开发人员不会接受你的想法、说辞
(2) 你不会理解开发人员面临的真正挑战和真正的需要。
做一个副业项目
：目的是尝试新的技术和工具，以了解当前和将来的开发方式。阅读一些教程确实不错，但仅仅是“书本”知识。只有自己亲自尝试一遍，体验一遍，你才能获得真正的经验：它为什么好？为什么差？你和一门技术呆的时间越长，你的体验就会越多，就越能帮助你做出好的决策。
找到正确的技术来尝试
：你不可能尝试所有的东西，我最近发现了ThoughtWorks的技术雷达，它们把技术，工具，平台，语言和框架分为四类：采用，尝试、评估和保留。
采用
的意思是“适合企业采用”。
实验
指的是“企业可以在一个风险可控的项目中尝试”
评估
的意思是“研究下如果对企业产生影响”
暂缓
意思是“谨慎推行”
通过这种分类，你就可以找到你想尝试的新技术了。
Clean Code
：简洁优雅的代码是最好的文档，架构师一定得能区分开什么是好代码，什么是坏代码。有一本很好的书来介绍好代码和坏代码：
在可能的时候尽量自动生成文档：
对于一些较为详细的文档，由于系统变化迅速，很难及时更新，所以尽可能自动生成文档：如果你是Model Driven的话可以从定义文件中自动生成文档，SWagger 和RAML都是很好的起点。
该多就多，该少就少：
无论是什么文档，在同一时刻只应该把注意力放在一件事情上，只包含这件事情的必要信息，额外的信息应该保留在附录中，因为大量的文字是很难阅读和理解的。仔细看看你的文档，问问自己：“为了理解整个东西，是不是所有的信息都在其中了？” ,“哪些信息是必须的，哪些是可以忽略的？”
根据我的观察，这是最被低估技能，如果你在设计方面特别出色，但是却无法和别人沟通，你的想法就没啥影响力，很可能失败。
演讲
：向一个小组或大组做演讲是一个架构师常见的工作，如果你刚开始觉得不舒服，可以从你的最好的朋友开始，慢慢扩大的更多的人，这件事只能通过不断地实践来学习， 是个需要花费时间的过程，还需要离开舒适区，所以要保持耐心。
找到正确的沟通级别
：不同的人看待事物的角度是不同的，所以你需要在他们的级别和他们交流。比如开发人员对技术细节感兴趣，经理更倾向于知道哪个选项更加省钱。
所以在沟通之前，你要看看你想交流的东西是不是在合适的级别，包括抽象度，内容，目标，动机等
经常沟通：
如果无人知晓，一个出色的架构毫无意义，要经常沟通你的架构设计以及背后的想法，定期在每个组织级别（小组，部门，公司）进行沟通，安排和开发人员，架构师，管理人员的会议，展示你的架构思路。
保持透明
：定期沟通只能部分缓解缺少的透明度，你还得确保决策背后的原因透明化，特别是对那些不参加决策的过程的人，他们很难理解为什么要这么做，有什么理由。
随时准备好做一个演讲
：总会有人问架构师问题，你也想快速地给出正确答案，这该怎么办呢？你可以把最重要的PPT挑出来，放在一起，随时展示并且给他们做展示，避免在一堆资料中找来找去，那样会浪费太多时间。
理解基本的项目管理原则：
作为架构师或者首席开发，你经常会被要求对你的设计进行估算：多长时间能完成？需要多少人？需要什么技能？
刚开始，你可以提供粗略的估算：几天，几个月。请记住估算的时间可不仅仅是编码实现，要有需求分析，测试，改正Bug。因此你需要知道软件开发过程中的各个步骤。获得更好估算的一个方法是基于历史数据给出预测。如果你没有历史数据，可以试试COCOMO方法，如果你在做一个敏捷项目，这本书非常有帮助：
评估架构
：作为一个架构师，你应该能够架构设计在当前和未来上下文中的适应性，这件事不容易，你可以准备一组问题来对架构设计进行“质询”，例如：
