架构思维 != 思考架构。
架构思维是：
- 了解架构与设计之间的差异，并了解如何与开发团队合作以使架构正常工作。
- 这是指拥有广泛的技术知识，同时又保持一定水平的技术深度，使架构师能够看到其他人看不到的解决方案和可能性。
- 它涉及了解、分析和协调各种解决方案和技术之间的权衡。
- 它是关于了解业务驱动因素的重要性以及它们如何转化为架构问题的。
架构 vs. 设计
架构师负责诸如分析业务需求以提取和定义架构特征（"-ilities"），选择适合问题领域的架构模式和风格以及创建组件（系统的构建模块）之类的事情。 然后将通过这些活动创建的工件移交给开发团队，该团队负责为每个组件创建类图、创建用户界面屏幕以及开发和测试源代码。
image.png
架构师和开发人员必须在同一个虚拟团队中才能进行这项工作。此模型不仅促进架构与开发之间的强大双向通信，而且还允许架构师为团队中的开发人员提供指导。
image.png
技术广度
与必须具备大量技术深度才能执行其工作的开发人员不同，软件架构师必须具有相当多的技术广度才能像架构师一样思考并以架构的观点看待事物。 知识金字塔说明了这一点。
image.png
- 您知道的东西包括技术人员每天用来执行工作的技术，框架，语言和工具。
- 您不知道的东西包括技术人员了解或听说过但很少或没有专门知识的那些东西。
- 您所不知道的东西是知识三角中最大的部分，包括全部技术，工具，框架和语言，这将完美解决技术人员要解决的问题 ，但技术人员甚至都不知道那些东西存在。
随着开发人员过渡到架构师角色，知识的性质也会发生变化。 架构师价值的很大一部分是对技术及其如何解决特定问题的广泛了解。
image.png
广度比深度更重要。 由于架构师必须做出使功能与技术约束相匹配的决策，因此对各种解决方案的广泛了解非常有价值。
image.png
我们的知识金字塔说明了架构师与开发人员相比在根本上有何不同。 开发人员将整个职业生涯都花在磨练专业知识上，而转变为架构师的角色意味着这种观点的转变，这对许多人来说都是困难的。 反过来，这导致了两个常见的功能失调：首先，架构师试图在各个领域保持专业知识，在这些领域都没有成功，并且在过程中陷入困境。 其次，它表现为过时的专业知识、错误的感觉是您过时的信息仍在前沿。 我们在大型公司中经常看到这种情况，在大型公司中，创建公司的开发人员已经担任领导角色，但仍然使用古老的标准来做出技术决策。
分析权衡
像架构师一样思考，就是要在每种解决方案（无论是技术解决方案还是其他解决方案）中进行权衡，然后分析这些权衡以决定最佳解决方案。架构是您无法使用的工具。
image.png
建筑中的一切都是权衡的，这就是为什么宇宙中每个架构问题的著名答案都是"取决于"。 尽管许多人对此答案感到越来越烦恼，但不幸的是，这是事实。
image.png
从架构上考虑不仅要考虑给定解决方案的优势，而且还要分析与解决方案相关的负面因素或权衡取舍。 软件架构师将分析主题解决方案的负面影响。
image.png
软件架构中的一切都有一个权衡：优点和缺点。 像架构师一样思考是在分析这些折衷，然后问“哪个更重要：可扩展性或安全性？” 不同解决方案之间的决定将始终取决于业务驱动因素，环境以及许多其他因素。
了解业务驱动因素
像架构师一样思考是在理解系统成功所需的业务驱动程序，并将这些需求转换为架构特征（例如可伸缩性，性能和可用性）。 这是一项艰巨的任务，需要架构师具有一定程度的业务领域知识，并需要与关键业务利益相关者建立健康，协作的关系。
平衡架构和动手编码
架构师面临的困难任务之一是如何在动手编码和软件体系结构之间取得平衡。 我们坚信，每个架构师都应该编写代码并能够保持一定水平的技术深度。 尽管这看起来很容易，但是有时却很难完成。
在动手编码和成为软件架构师之间寻求平衡的第一个技巧是避免瓶颈陷阱。 当架构师在项目的关键路径（通常是基础框架代码）中拥有代码所有权并成为团队的瓶颈时，就会发生瓶颈陷阱。
第一种方法是频繁进行概念验证或POC。 这种做法不仅要求架构师编写源代码，而且还通过考虑实现细节来帮助验证架构决策。
我们在进行概念验证工作时的建议是，架构师应尽可能编写最佳的生产质量代码。 我们推荐此做法有两个原因。 首先，通常，一次性的概念验证代码会进入源代码存储库，并成为其他人遵循的参考体系结构或指导示例。 架构师想要做的最后一件事就是将他们的一次性代码松散地表现出来。 第二个原因是，通过编写生产质量的概念证明代码，架构师可以练习编写高质量，结构良好的代码，而不是不断开发不良的编码实践。
作为一名架构师，动手实践的最后一种方法是进行频繁的代码审查。 虽然架构师实际上并未编写代码，但至少它们与源代码有关。
网友评论