基于模式的架构评审(2)

　　在评审结束后，评审者需要向整个团队做出总结。这应该可以进行的很快，因为多数问题已经在评审期间讨论或得到解决。(会议的全部过程可以在一个小时内结束)
　　评审和专注生产式实践
　　表格1展示了专注生产式项目的典型实践以及PBAR和传统重量级评审将如何适应它们。这些实践也可以在很多敏捷和精益方法论中看到。请注意，并不是所有的专注生产式项目都支持敏捷方法论，反之，也并不是所有的敏捷项目都是专注生产式的。

专注生产式项目的通用实践和架构评审
专注生产式实践	PBAR	传统评审
频繁发布 [5], [6], [7]	在早期的多次发布中进行规划，简短的评审反馈周期可以很好的适应较小的发布窗口	在多次发布间没有实际意义；较长的计划-评审-反馈时间会跨越多次发布
随用户需求而变 [5], [7]	专注于质量属性（稳定更胜于功能性需求）；允许功能发生改变	需要保持需求的稳定性，包括功能性需求
轻量级文档 [5], [6]	不需要特定的文档；可以平衡好模式对应的架构质量保证问题	鼓励编写大量的架构文档；有部分文档必须编写，以供评审使用
“可行走的骨架”（Walking skeleton）[6]	在“可行走的骨架”的实现的反馈中进行规划	对于总体计划，需要根据需求建立基于日历的时间表

　　频繁发布
　　为了提高灵活性，一般的项目都可能会有较频繁的内部或外部发布。架构评审应该满足这样的场景：计划和评审本身都应该很简短。因为参与者不需要做任何准备，PBAR可以灵活地规划。它精巧的规模对于非常小的发布周期来说也只有很小的影响。
　　随用户需求而变
　　大多数的架构评审都基于需求说明书(通常以书面的形式)。但是由于需求常常变更，所以评审的功能被削弱了。而PBAR则关注于质量属性，它比功能性需求更加稳定。
　　轻量级文档
　　传统的评审都趋向基于全面的架构文档，但是这很容易让项目为了产出这些文档而多做很多工作。对于这种情况，PBAR是一种轻量级的选择。
　　可行走的骨架(Walking Skeleton)
　　“可行走的骨架”是早期一种贯穿始终的架构实现，经常被作为原型来用于证明架构概念。架构评审的一个完美时间点就是“可行走的骨架”完成之时。因为不需要很多的准备和精力，所以你可以在“可行走的骨架”实现后马上举办PBAR;而不需要像传统的评审那样，必须进行非常慎重的计划和前置工作。
　　PBAR的经验
　　我们曾在9个项目中使用了PBAR。虽然差不多有一半是学生的软件工程课程项目，但都是拥有真实客户的真实项目。在这些评审中，六个非常成功，有一个部分成功，而另外两个是失败的。那个部分成功和两个失败的评审帮助我们改善了评审过程。表格2简要列举了这些项目和结果;“主要问题”这一列包含了架构与重要质量属性之间主要的不协调情况。

基于模式的架构评审
系统	规模	项目阶段	项目描述	被找到的问题个数	主要问题个数	已被解决的主要问题个数	耗费的精力 (以员工小时计算[评审者/团队])
A	大型	实现阶段	流媒体数据的处理与分析	3	1	0	5 (5/0)
B	中型	架构阶段	计算机控制的过程控制	4	1	0	11 (6/5)
C	小型	已发布	嵌入式GPS平台应用	2	0	0	6 (4/2)
D	小型	实现早期	基于Web的定期跟踪系统	7	1	1	8 (3.5/4.5)
E	小型	实现早期	分布式订阅管理系统	3	2	1	9.5 (3.5/6)
F	小型	实现早期	电子商务库存管理系统	3	1	1	8 (3.5/4.5)
G	小型	实现早期	安卓手机应用	3	1	1	7.5 (3.5/4)
H	小型	实现早期	基于Web的游戏平台	5	0	0	7.5 (3.5/4)
I	小型	架构早期	基于Web的业务流程支持系统	0	0	0	4 (2/2)

　　大多数项目都遵循前面描述的多数实践。大都需要开发人员之间的高度沟通，以及与客户之间高度的日常交流。大部分的项目罕有甚至没有架构文档，没有用文档记录甚至没有使用架构模式。大部分会有频繁的集成，少部分会有频繁的发布。大部分项目会更多地考虑用户的需求变更，并维护好一个灵活的排好优先级的功能列表，还有少部分会明确的创建“可行走的骨架”。

原文转自：http://www.ltesting.net