内容简介
本书旨在阐释如何将软件架构技能和知识应用于更为庞大、复杂的产品开发流程中。书中对软件架构进行了定义，明确了软件架构在产品开发团队众多专业领域中的定位和作用，以及架构与和它关联的概念、流程、标准等要素的多个连接点，并深入探讨“变更”这一主题，以及架构实践的核心——识别、管理和设计系统的变更。同时，探讨规模较大的项目中至关重要的考量因素——管理和沟通，以及如何选择架构师团队的组织结构，架构师如何与组织内其他专业部门互动。本书适合软件架构师、架构师团队管理者以及产品管理、用户体验、项目管理等领域的读者阅读。
目录
目 录
本书赞誉
译者序
前言
致谢
关于作者
第1章 软件架构
1.1 基础架构 ……………………………2
1.2 系统概述 ……………………………3
1.3 在组件中的体现 ……………………4
1.4 组件之间的关系 ……………………6
1.5 系统与环境的关系 …………………7
1.6 决定设计的原则 ……………………9
1.7 架构演进 …………………………11
1.8 总结 ………………………………13
第2章 架构的背景
2.1 概念 ………………………………15
2.2 可靠性 ……………………………17
2.3 具有重要架构意义的需求 ………18
2.4 产品家族 …………………………20
2.4.1 一款产品，多平台发布 …20
2.4.2 产品线 ……………………22
2.4.3 产品套件 …………………23
2.4.4 跨平台的平台 ……………24
2.5 平台建设 …………………………25
2.6 标准规范 …………………………27
2.7 总结 ………………………………29
第3章 变更
3.1 变更的阶段 ………………………31
3.2 变更的类型 ………………………32
3.3 产品驱动型变更 …………………33
3.4 技术驱动型变更 …………………35
3.5 简洁性 ……………………………36
3.6 投资思维 …………………………39
3.7 增量交付 …………………………42
3.8 架构演进 …………………………44
3.9 总结 ………………………………47
第4章 流程
4.1 编写系统文档 ……………………49
4.2 奔向愿景 …………………………51
4.3 撰写变更提案 ……………………52
4.4 维护待办事项列表 ………………54
4.5 考虑其他可行方案 ………………55
4.6 学会说不 …………………………58
4.7 紧急性与重要性 …………………59
4.8 重新编写系统文档 ………………59
4.9 总结 ………………………………60
第5章 设计
5.1 如何加速架构设计 ………………64
5.2 设计如何驱动架构演进 …………66
5.3 分解 ………………………………67
5.4 组合 ………………………………69
5.5 组合与平台 ………………………70
5.6 循序渐进 …………………………71
5.7 并行处理 …………………………72
5.8 组织结构 …………………………73
5.9 在开放环境下工作 ………………74
5.10 放弃 ………………………………76
5.11 完成 ………………………………77
5.12 总结 ………………………………77
第6章 决策 ………………………………79
6.1 更多的信息会有所帮助吗 ………80
6.2 决策期间发生了什么 ……………81
6.3 有多少决策正在进行 ……………82
6.4 不这样做的代价是什么 …………83
6.5 我能接受这个变更吗 ……………84
6.6 犯错的代价是什么 ………………86
6.7 我能有多大把握 …………………87
6.8 这是我应该做的决策吗 …………88
6.9 决策是否符合要求 ………………89
6.10 应该将决策记录下来吗 …………90
6.11 总结 ………………………………91
第7章 实践 ………………………………93
7.1 待办事项列表 ……………………94
7.2 目录 ………………………………97
7.3 模板 ………………………………98
7.4 评审 ………………………………100
7.5 状态 ………………………………103
7.6 速度 ………………………………105
7.7 思考 ………………………………107
7.8 总结 ………………………………108
第8章 沟通 ……………………………110
8.1 心智模型
前言/序言
前 言
坦率地说，当我从大学计算机科学专业毕业时，我对打造一款软件的科学原理只具备一个外行人的粗浅理解。我学习过数据库、算法、编译器、图形学、CPU架构、操作系统、并发性等知识，并且在某种程度上，我还拥有一个将这些技术联系起来的框架。
由于我经常在课堂之外编写软件（主要是暑期工作），因此我深知将学术知识用于实际产品开发面临多重挑战。选择和实现合适的算法通常只是其中相对容易的部分，真正的困难之处在于如何处理庞大的代码库，如何创建实用的用户体验，如何进行质量和性能测试，以及如何与团队成员协同开发同一个产品。
毕业后，我从事过一系列软件产品的开发工作。尽管大多数项目并未取得成功，但我始终秉持着从经验中学习的态度。如果说“从失败中学习”这一老生常谈的观点是正确的，那么在那段时间里，我确实收获颇丰。
在参与多个不同项目的过程中，我发现与大多数同行相比，自己往往对产品有更系统性的理解，能够更清晰地认识到产品的内部组件及其相互之间的关系。尽管我当时并未完全意识到，但这种洞察全局并进行推理的能力实属一种难得且相当有用的技能。
软件架构的实践旨在全面理解软件系统的所有组件及其相互之间的关系。“架构”一词并非软件行业独创，它实际上来源于建筑行业，并适用于各种类型的产品。例如房屋、汽车、电视、火箭，都有各自的架构。如果我是一名火箭科学家，我可能更关注火箭的各部分如何协同工作，而非特定阀门或喷嘴的设计。当然，这只是假设，毕竟我现在从事的是软件领域的工作。
回顾我几十年的行业生涯，软件产品的复杂性发生了翻天覆地的变化。在我职业生涯的初期，一个可行的软件产品指的就是能够盈利的产品，仅需要一张软盘的容量，一次只能在一台计算机上运行，而且无法连接互联网。
如今，一个在“云端”运行的软件产品可能包含数百个相互协调的程序，这些程序运行在多个地理位置分散的节点上，每天更新数次，并被期望能够永远不间断地运行（尽管有时也会出现中断）。在较短的时间内，软件产品的本质已经发生了根本性的变化。
软件架构的演进使其比以往任何时候都更加复杂，也更加重要。复杂性体现在需要管理和追踪的组件和关系的数量激增。重要性则体现在如果无法有效管理这些关系，系统的复杂性将不可避免地限制其可靠性和未来开发的速度，最终导致大多数产品的终结。我个人也曾目睹过这种情况的发生。
软件架构的意义远不止于管理复杂性，但如果要评选架构作为一门学科最有价值的成果，那么非它莫属。复杂性会对软件的功能造成全方位的损害：它会导致软件行为难以预测，进而损害用户信任；它会导致缺陷，降低软件的可靠性；它会传播故障，将不起眼的错误演变成大规模的故障；它还会阻碍人们对于软件的理解，最终导致任何简化软件状态或结构的尝试都以失败告终。总而言之，复杂性是软件的大敌，而规范的架构实践则是对抗它的最佳武器。
在我职业生涯的后期，我有幸带领团队负责多个大型复杂软件产品的架构设计。这些产品均已问世十多年，并非全新的产品。我的工作内容与其他架构师别无二致，首先要完成以下任务：了解系统当前的架构，评估其是否满足当前和预期的需求，并提出和评估改进方案。我将在本书后面的章节中详细讨论如何完成这些工作。
虽然上述活动必不可少，但将它们与软件架构等同，就好比上过几节计算机课程便声称自己会写软件。这仅是一个良好的开端，要真正使软件架构成为软件开发中不可或缺且成功的部分，还有很长的路要走。而这也正是本书的意义所在：如何在软件开发组织中进行架构实践。
专注力
本书并非软件架构指南，不会阐述客户端-服务器、领域驱动设计、感知-计算-控制等架构风格，也不会探讨如何选择数据库技术、进行区域化部署或实施扩展性设计。当然，这些都是重要的话题，已经有众多的书籍、博客和其他资源对此进行了详细介绍，也有很多架构师精通这些领域。
但是，仅掌握归并排序算法的实现方法，并不足以编写出一个应用程序；同样，仅熟悉某种特定架构，也远不足以创建出应用该架构的系统。归并排序算法或许可以由一名工程师单独完成，而系统架构的设计则必然涉及更多人员的参与。
本书旨在阐释如何将软件架构技能和知识应用于更为庞大、复杂的产品开发流程之中。本书没有局限于特定的架构风格，而是对软件架构进行了定义，明确了它在产品开发团队众多专业领域中的定位和作用，并明确架构与和它关联的概念、流程、标准等要素的多个接触点。
我们将深入探讨“变更”这一主题。识别、管理和设计系统的变更是架构实践的核心。架构设计的过程有时如同一个“黑盒子”，对话从一端进入，一个完整的设计方案从另一端产出。实际上，变更的过程是
