前言

软件架构在一个成功的软件交付中扮演关键角色，然而令人沮丧的是，很多团队都忽视了这一点。即使在最敏捷的团队中，软件构架这一角色也都是必需的，不管是由一个人还是整个团队共同扮演，但要寻求到预先和演化两种构架理念的平衡，往往还只是人们美好的意愿而并没有变为现实。

(资料图)

有需要领取资料的可后台私信扣【777】免费领取

第一章什么是软件架构

通过学习这部分，我们将了解软件架构是什么，架构和设计的区别，敏捷的架构意味着什么，以及为什么思考软件架构很重要。

架构作为名词来解释时，概括起来都与结构有关:将产品分解为一系列组件、模块和交互这需要考虑整个产品，包括处理(建筑物的)供电、供水、空调，或处理(软件的)安全、配置错误处理等横切关注点的基础设施服务。

这部分将关注软件架构的角色，包括软件架构的角色是什么，需要哪类技能，以及为什么编码、指导和合作很重要。

一个软件系统很少孤立存在，可能有不少人要为整个架构过程作贡献。这包括了从需要理解和认同架构的直接开发团队，一直到那些对安全性、数据库、运营、维护或支持感兴趣的人组成的扩展团队。任何担任软件架构角色的人都需要与这些人合作，以确保架构能与周围环境成功整合。如果不合作，就等着失败吧。

这部分是关于设计软件的整个流程，特别是开始编码前真正需要思考的事情。

软件架构谈论的是重要的设计决策，其重要性以变动的成本来衡量。对于那些从根本上塑造了最终软件架构的重要决策而言，起点是在高层次上对需求、约束和原则的理解。早些理解它们,将有助于避免将来昂贵的返工。

这部分是关于用一套轻量但有效的草图对软件架构进行可视化。

当告诉人们我到世界各地去教人软件架构和如何绘图时，得到的反应通常是怀疑或取笑。平心而论，不难看出这是为什么。软件架构的名声已经很差了，一说“大局”往往会让人想起分析瘫痪和一堆很少有人真正理解的 UML图。毕竟，软件开发行业在过去十年已经有了长足发展特别是敏捷宣言的影响以及由此催生的大量技术

这部分是关于一个我们爱恨交加的重要话题:编写文档!

我曾被要求评审和参与开发没有文档的系统。你当然可以从代码的角度评估大部分问题的答案，但这会很繁重。阅读代码的作用始终有限，但某些时候你可能需要向团队的其他人请教一些可题。如果没有问对问题，你就得不到正确的答案:你不知道你未知的。

最后这部分将探讨如何将前面的内容融入软件开发的日常工作，也会解答应该做多少软件架构(以及预先设计)这一问题。

考虑架构的驱动力不需要花很长时间，却能为软件设计的其他部分提供一个开始。当然，这并不意味着架构不应该更改，特别是当你开始编写代码、获得反馈后。关键在于你现在有了一个框架和一定的工作范围,能为团队提供一些经常需要的愿景和指导。我的经验是小方向有大用场.

有需要领取资料的可后台私信扣【777】免费领取

标签：