软件架构评审指南

引言

评审是他人审视您文档/设计/代码/软件架构的机会，也是您审视他人工作的机会。它们促进知识交流。但其主要目标是提高软件质量。它们帮助您在错误变成真正的灾难之前发现它们。这段文字试图汇集审阅者在其软件架构评审中可以使用的要素。

背景

如果您想了解软件架构的正式定义，我建议阅读此处的信息。

这些定义中的普遍观点是，您需要对将要构建的系统做出高级别的决策

• 您将使用哪种风格？结构是什么？
• 它将如何运作？架构的结构组件如何协同工作？
• 它如何满足所有利益相关者的需求？

对于现有系统，您可以检测到这些关键因素，它们将为您提供软件架构的思路。评估软件架构的一种方法是推理软件架构所表现出的质量属性。

在下面的要点中，我试图总结不同的质量属性以及在进行评审时通常需要注意的事项。此列表并非详尽无遗。也许您也有想分享的想法……？

性能

响应刺激（事件）所需的时间，或在某个时间间隔内处理的事件数量。

典型设计/架构原则需要注意

• 连接池 - 通过建立共享连接池来减少建立数据库连接的执行时间开销
• 负载均衡 – 在一组资源之间平均分配负载
• 分布式处理
• 缓存 – 使用数据的本地副本以减少访问时间
• 延迟实例化
• 事务并发
• OLTP和OLAP之间的进程隔离
• 数据复制

可以使用的典型测量单位

• 每单位时间事务数
• 完成一笔交易所需的时间

可靠性

系统在应用程序和系统错误以及意外或不当使用的情况下（以可预测的方式运行）随时间保持运行的能力。

典型设计/架构原则需要注意

• 使用预防措施（管理）例如 IIS.6 ASP.NET /COM+ 1.5 中的服务器进程回收。
• 隔离 - COM+ 服务器进程隔离
• 数据库事务日志（回滚）

可以使用的典型测量单位

• 平均故障时间

可用性

系统正常运行的时间比例。

典型设计/架构原则需要注意

• 故障转移 - 使系统更加可用，因为如果一个服务器实例出现故障，另一个实例可以接管工作。
• 事务管理器 - 它通过帮助确保系统始终处于一致状态以及提供处理某些类故障的系统范围策略来提高可用性和可靠性。
• 无状态设计 - 当某个无状态服务器失败时，其工作可以重定向到另一个服务器实例，而不会影响状态管理。

可以使用时的典型测量单位

• 两次故障之间的时间间隔
• 系统在发生故障时能够恢复运行的速度。

安全

衡量系统抵抗未经授权的使用尝试和拒绝服务攻击的能力。

典型设计/架构原则需要注意

• 授权 - 一旦用户被识别和认证，系统中信息的访问控制是如何组织的？（基于角色的 ACL）
• 认证 - 您的系统中最终用户的身份和表示，以及验证他是否说实话？
• 审计 - 安全策略的验证和监控
• 完整性 - 防止在传输或存储过程中信息被不当或未检测到的修改？（加密）
• 保密性 - 防止在传输和存储过程中信息被不当泄露（加密）
• 拒绝服务 - 服务连续性？（入侵检测）
• 数据隔离（公共应用程序与内部 LOB 应用程序）

可修改性

能够快速且经济高效地对系统进行更改。

典型设计/架构原则

• 客户端-服务器（关注点分离）– 这种机制涉及从中央进程提供一组服务，并允许其他进程通过固定协议使用这些服务。
• 接口与实现分离 – 这种机制允许架构师替换同一功能的不同实现。
• 分离 – 这种策略分离了处理不同关注点的数据和功能。由于关注点是分开的，我们可以独立于另一个来修改一个关注点。隔离通用功能是分离策略的另一个例子。
• 将功能编码到元数据和语言解释器中 – 通过将某些功能编码到数据中并提供解释该数据的机制，我们可以简化影响该数据参数的修改。
• 运行时发现，没有硬编码的连接字符串、队列名称等。

典型测量单位

• 使用特定更改作为基准并记录进行这些更改的成本

可移植性

系统在不同计算环境中运行的能力。有时被视为一种特殊的可修改性。

典型设计/架构原则

• 虚拟机

功能

系统能够完成其预期工作的能力。

典型测量单位

• 更改请求数

可扩展性

新功能实现/用改进版本替换组件以及删除不需要或不必要的功能或组件。

典型测量单位

• 轻松、增量地添加功能（时间、预算等）
• 耦合/内聚

概念完整性

统一系统各级设计的潜在主题或愿景。

互操作性

与其他子子系统的交互，或对外部可见的功能和数据结构的明确访问，或与其他运行时环境的交互。

典型设计/架构原则

• 简单数据类型
• XML
• Web 服务

可用性

使用程序有多容易？

典型设计/架构原则

• 产品线之间的 GUI 标准

典型测量单位

• 熟悉先前版本或产品线其他成员的用户所犯的错误数量。

可维护性

问题修复，在发生错误后修复软件系统。

典型测量单位

• 易于本地化
• 更改的涟漪效应

效率

处理软件执行的可用资源的使用，以及这对响应时间、吞吐量和存储消耗的影响。

典型设计/架构原则

• 提前获取，延迟释放
• 减少往返
• 降低流量吞吐量（只发送必需的，只检索必需的）

可测试性

测试代码（单元、子系统等）有多容易？

典型设计/架构原则

• 接口编程
• 控制反转/依赖注入
• 具有明确定义的职责的类

可重用性

在软件架构层面，能够将软件架构重用于另一个应用程序。
在代码层面，框架方面。

易于部署

您可以多快部署系统？

典型测量

• 安装程序（向导）

典型测量单位

• 可以通过安装产品和/或分发新功能单元所需的时间和资源来衡量

易于管理

指维护应用程序健康所需的基础设施、工具以及管理员和技术人员。例如，在对系统其余部分影响最小的情况下更改服务的物理位置。

典型测量单位

• 降低支持成本：可以通过比较标准时间段内的帮助台电话数量来衡量。

可扩展性

用户在维护其他质量的情况下进行的更改数量。支持持续增长以满足用户需求和业务复杂性。必须能够通过增加硬件来扩展应用程序所需的最低硬件配置，以支持增加的工作负载。

典型设计/架构原则

• 无状态设计
• 负载均衡
• 并发（乐观）

可调试性/监控

为轻松高效地调试应用程序做准备。异常行为的注册。实时监控。

典型设计/架构原则

• 跟踪支持
• 异常处理机制中的日志记录

开发生产力

基于软件架构的应用程序开发的成本和时间节省机制。开发人员应该能够轻松学习架构概念以及如何实现它。用新开发人员扩展开发团队不应花费太多精力进行培训等。使用模板和编码标准化的工作方式可以提高学习曲线和质量。

典型设计/架构原则

• 框架
• 模板/代码生成
• 最佳实践编码检查表和标准

历史

• 2007 年 9 月 13 日：首次发布