Part 1： 软件架构是什么

一、什么是架构？

作为名词，“概括起来都与结构有关，将产品分解为一系列组件、模块和交互”；

作为动词，“包括了理解你需要构建什么、设定愿景以便于进行构建和做出恰当的设计决策”。

“所有架构类型都具有结构和愿景”。

二、软件架构和企业架构

“从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构”。

“企业架构一般是指整个组织的中心工作，着眼于如何组织与利用人、流程和技术来使企业有效和高效地工作。换句话说，它是关于企业如何分组或部门，业务流程如何在上层运作，以及技术如何支撑这一切。这跟软件架构形成了强烈对比，因为企业架构没有必要关注技术细节。相反，企业架构可能看重的是如何在整个组织中最好地利用技术，而无需实际介入这些技术的工作原理。”

“从事企业架构工作所需要的思维方式和软件架构大相径庭”，“企业架构需要更高层次的抽象”，“这关乎广度而非深度，关乎战略而非代码。”

三、敏捷软件架构是什么？

“以敏捷的方式交付软件并不能保证得到的软件架构是敏捷的。”

“理解组织或业务变化的速度很重要，因为这能帮助你决定采用何种架构风格，可能是整体架构、微服务架构或者介于两者之间。”

四、架构与设计

格雷迪说：

“所有架构都是设计，但并非所有涉及都是架构。”

“架构反映了一个系统成型的重要设计决策，而重要性则通过改变的成本来衡量。”换句话说，“架构不可能轻易反悔”，那会花费很高的成本。

“重要决策都是‘架构’，其他的都是‘设计’。”

那些重要的决策可能包括：

系统的形态（例如，客户端-服务器，基于Web、原生移动客户端、分布式、异步等）；

软件系统的结构（例如，组件、层、交互，等等）；

技术选择（即编程语言、部署平台，等等）；

框架选择（例如，MVC框架、持久性/ORM框架，等等）；

设计方法/模式选择（例如，针对性能、可伸缩性、可用性等的方法）。

五、软件架构重要吗？

1、缺乏软件架构将引发问题

“如果没人思考软件架构，最终结果往往看起来像一团乱码麻（big ball of mud）。”

“副作用还包括软件系统太慢、不安全、脆弱、不稳定、难以部署、难以维护、难以改变、难以扩展，等等。”

2、软件架构的好处

让团队跟随一个清晰的愿景和路线图；

技术领导力和更好的协调；

便于与人交流，方便回答与重要决策、非功能需求、限制和其他横切关注点相关的问题；

识别和减轻风险的框架；

方法和标准的一致性，随之而来的结构良好的代码库；

正在构建的产品的坚实基础；

对不同的听众，以不同的层次的抽象来交流解决方案的结构。

Part 2、软件架构的角色

六、软件架构的角色

软件架构师“是一个角色，而不是一个级别”。

“软件架构这个角色，可以是一个人，也可以由团队共同承担”，包含如下内容：

• 架构驱动力：理解业务目标和管理架构驱动力，其中包括需求（功能性需求和非功能需求）和环境的限制。非功能性需求和限制往往对软件架构有巨大的影响，因此明确地将其纳入软件架构的角色。

• 设计软件：建立技术战略、愿景和路线图。要理解如何解决架构驱动力带来的问题，创建软件系统的整体结构，并为交付设定一个愿景；另一个是技术选择，有一些组织有一份允许使用的技术清单，你只能从中选择，还要考虑成本、许可、供应商关系、技术战略、兼容性、互操作性、支持、部署、升级策略、最终用户环境，等等。

• 技术风险：发现、减轻和承担技术风险，保证架构的“运转”。

技术选择其实就是风险管理，当复杂度或不确定性高的时候降低风险，有利可图时再冒点险。所有的技术决策，在做出选择时都要把全部因素考虑在内。

一个架构，如果能满足非功能性需求，在给定的环境约束下有效，能为其他代码提供必要的基础，作为平台能解决潜在的业务问题，那就是管用的架构。

• 架构演化：贯穿整个软件交付过程，持续的技术领导和对架构的承担。架构师在创建了一个架构之后，还得在项目的整个交付过程中根据不断变化的需求和团队反馈来对其进行演化。

• 编写代码：参与到软件交付的实践部分。编码为架构师提供了一种与团队分享软件开发经验的方式，从而帮助他们更好地理解如何从开发的角度看待架构。

• 质量保证：引入并坚持标准、指导、原则等。不仅包括代码评审，还包括引入一些标准和工作实践，如编码标准、设计原则和工具，为项目提供一个基线保证。

七、软件架构师应该编码吗？

软件架构师应该编码。优秀架构师的重要特征是抽象思维能力，但你画的那些框框线线，终归要形成代码。你不见得要成为团队里编码最厉害的，但参与到实践和交付流程的好处非常大。毕竟，“知”和“行”还是不同的。贡献代码能帮助你和团队建立起融洽的关系，有助于缩短存在于很多软件团队的架构师和开发者之间的距离。

《敏捷教练：如何打造优秀的敏捷团队》一书中说：

如果你了解如何编程，往往会忍不住对开发者该如何编写代码提出建议。小心，因为你可能在浪费时间：如果你没有参与项目的编程，开发者多半会无视你的编码经验。他们还会认为你越权，影响了他们的工作，所以尽量别在这方面指指点点。

但软件架构师常常会发现，自己不能像期望的那样写很多的代码。这可能因为时间压力，因为你有很多“架构”工作要做。这时，对软件系统中有疑问的概念构建原型和证明是一个很好的参与方式。这让你可以和团队建立起融洽的关系，也是评估你的架构是否管用的好办法。

别把时间都花在编码上，否则，软件架构角色其他的部分谁来承担？

八、软件架构师应该是建造大师

架构师要和团队一起工作。对很多组织来说，这里有个大问题：找不到足够的架构师。我们常常遇到一些架构师要协助多个不同团队，很明显，这时候他没有时间写任何代码。在多个团队中扮演软件架构角色，并不是一个有效的工作方式。我们看看中世纪建筑行业是怎么解决这个问题的：

每个石匠都会带一个为他工作的学徒。当石匠接下一份新工作，学徒也会跟着他。如果石匠觉得自己的学徒已经对行当足够了解，就会让他在石匠行会接受考验。

这也是为什么指导和辅导应该是软件架构角色的一部分——我们需要培养未来的架构师。

九、如何分辨架构师的能力？

他们过去的经验往往能很好评判他们承担这个角色的能力，但你需要看得更深：

• 架构驱动力：是捕捉和挑战一套复杂的非功能需求，还是简单地假设它们的存在；
• 设计软件：从零开始设计一个软件系统，还是扩展已有的
• 技术风险：证明架构能够工作，还是盲目乐观
• 架构演化：持续参与和演化你的架构，还是把它交给“实现团队”
• 编写代码：参与交付的实践部分，还是袖手旁观
• 质量保证：保证质量并选择标准，还是反其道而行之或无所作为 其中，大部分可以归结为是承担寻找方案的责任还是推诿问题。

十、对任何特定软件系统所使用的所有技术，软件架构师是否都应该是专家？

不，合作才是关键。找到那些知你所不知的人，与他们紧密合作。结对编程有好处，那么为什么不结对架构？

十一、架构师的软技能

• 领导力：简单来说，就是创造共有的愿景，并带领人们向着共同目标前行的能力
• 沟通：你有世界上最好的想法和愿景，但如果不能有效地传达给其他人，也是死路一条
• 影响力：这是重要的领导技能，从毫不掩饰的劝说到神经语言编程或绝地控心术，它能够以多种途径实现。通过妥协和谈判也可以达到这样的目的。每个人都有自己的想法和计划，你在处理时还得让他们都不反感，并主动地去追求你需要的结果。好的影响力也要求好的倾听和探索能力。
• 信心：信心很重要，是有效的领导力、影响力和沟通的基础。但信心不代表傲慢。
• 合作：软件架构师不应该被孤，（与其他人）合作想出更好的方案是一项值得实践的技能。这意味着倾听、谦虚和响应反馈。
• 指导：不是每个人都对你正尝试做的事情又经验，你需要对他们进行角色、技术等方面的指导；
• 辅导：辅导室对人进行学习方面的指引，而非告诉他们怎么做一件事。作为领导，你可能会被要求去辅导团队中的其他人； 动力：这说的是保持团队愉快、开朗、积极。团队要有积极性，才会跟随你这个软件架构师所创建的任何愿景。你还要面对团队中的一些人不买账的局面。
• 润滑剂：你经常需要退后一步，促进讨论，特别是团队内有不同意见时。这需要探索、客观，帮助团队达成共识
• 政治：每个组织都少不了政治。我的咒语是，离得越远越好，但你至少应该明白周围发生了什么，这样才能做出更可靠的决策
• 责任感：你不能因为失败就责备软件开发团队中的其他人，有责任感对你而言很重要。如果软件架构不能满足业务目标，无法交付非功能性需求或技术品质很差，那都是你的问题；
• 授权：授权对任何领导角色来说都是一个重要部分，作壁上观和事必躬亲之间有一条模糊的界。你应该学会在适当的时候授权，但请记住，你授权的可不是责任。

保持积极：

不管你是否意识到了，你都在一个非常有影响力的位置上，你的一举一动都被整个开发团队看在眼里。不管愿不愿意，单是这一个原因，你就有改变整个团队的能量。如果你很主动，开发团队也很可能变得主动。如果你对工作充满热情，团队其他人也会很可能充满热情。但你任何成都的懒散、冷漠或悲观传染到团队的速度，也会很快。