第二十九章 集成

集成是指一种软件开发行为：将一些独立的软件组合为一个完整系统。

集成方式的重要性

从周到的继承中，你能预期获得某些下列的益处：

• 更容易诊断缺陷；
• 缺陷更少；
• 脚手架更少；
• 花费更少的时间获得第一个能工作的产品；
• 更短的整体开发进度表；
• 更好的顾客关系；
• 增强士气；
• 增加项目完成的机会；
• 更可靠地估计进度表；
• 更准确的现状报告；
• 改善代码的质量；
• 较少的文档。

集成频率——阶段式集成还是增量集成

阶段式集成

它遵循下列明确的步骤：

1. 设计、编码、测试、调试各个类。这一步称为单元开发；
2. 将这些类组合为一个庞大的系统；
3. 测试并调试整个系统。这称为系统瓦解。

增量集成

增量集成遵循以下步骤：

1. 开发一个小的系统功能部件；
2. 设计、编码、测试、调试某个类；
3. 将这个新的类集成到系统骨架上。测试并调试骨架和新类的结合体，在进一步添加任何新类前，确保该结合体能工作。如果做完了剩余的所有工作，就回到步骤2开始重复这一过程。

增量集成的益处

• 易于定位错误；
• 及早在项目里取得系统级的成果；
• 改善对进度的监控；
• 改善客户关系；
• 更加充分地测试系统中各个单元；
• 能在更短的开发进度计划内建造出整个系统。

增量继承的策略

• 自顶向下集成；
• 自底向上集成；
• 三明治集成；
• 风险导向的集成；
• 功能导向的集成；
• T型集成；

Daily Build与冒烟测试

• 每日构建；
• 检查失败的build；
• 每天进行冒烟测试；
• 让冒烟测试与时俱进；
• 将daily build和冒烟测试自动化；
• 成立build小组；
• 仅当有意义时，才将修订加入build中，但是别等太久；
• 要求开发人员在把他的代码添加到系统之前，进行冒烟测试；
• 为即将添加到build的代码准备一块暂存区；
• 惩罚破话build的人；
• 在早上发布build；
• 即使有压力，也要进行daily build和冒烟测试。

核对表：集成

集成策略

• [ ] 该策略是否指明了集成子系统、类、子程序时应该采用的最优顺序？
• [ ] 集成的顺序是否与构建顺序协调，以便在适当的时候准备好供集成的类？
• [ ] 该策略是否易于诊断缺陷？
• [ ] 该策略是否使脚手架最少？
• [ ] 所选的策略是否好于其他方式？
• [ ] 组件之间的接口是否有明确定义？

daily build与冒烟测试

• [ ] 项目是否经常build——理想情况下，每天build一次——以支持增量集成？
• [ ] 每次build之后是否都支持冒烟测试，让你直到这个build能否工作？
• [ ] 你是否以使build和冒烟测试自动进行？
• [ ] 开发人员是否频繁地check in他们的代码——两次check in之间最多间隔一两天？
• [ ] 冒烟测试是否与代码同步更新，随代码发展而发展？
• [ ] 破坏build是汉奸的事件吗？
• [ ] 是否在有压力的情况下，也对软件进行build和冒烟测试？

要点

• 构建的先后次序和集成的步骤会影响设计、编码、测试各类的顺序；
• 一个经过充分思考的集成顺序能减少测试的工作量，并使调试变得容易；
• 增量继承有若干变型，而且——除非项目微不足道的——任何一种形式的增量集成都比阶段式集成好；
• 针对每个特定的项目，最佳的集成方式通常是自顶向下、自底向上、风险导向及其他集成方法的某种组合；
• daily build能减少集成问题，提升开发人员的士气，并提供非常有用的项目管理信息。