软件实践教学模式：敏捷重构优于传统模型

传统的软件开发模型多数是在经典的瀑布模型基础上演化而来。调查数据显示，全球软件开发行业所应用的开发模型中，瀑布模型、快速原型模型、迭代模型和螺旋模型，是目前应用最为广泛的软件开发模型。表3-1总结了这四种模型的技术特征和适用范围。

表3-1　四种模型的技术特征和适用范围

敏捷模型是迭代和增量的，这意味着当代码增量完成后，测试人员都可以及时进驻并且输出测试报告。一个迭代周期可能短至只有一周，或者长也就一个月左右。团队构建并测试少量的代码，确保增量部分的代码与基础代码作为一个整体正常工作，然后以此为基础，实施下一个需要构建的模块。增量代码在被测试之前处于“未完成”状态，只有通过测试，该迭代任务状态才由“未完成”转换为“完成”。

以瀑布模型为例，图3-3展示了瀑布模型和敏捷模型的开发过程，从图3-3可以看出，相较于敏捷模型，瀑布模型主要存在以下缺陷：

图3-3　瀑布模型与敏捷模型(www.xing528.com)

（1）软件开发早期客户对自己的真实需求并不明晰，因此需求模型往往不能准确包含系统所需的功能以及要达到的性能。软件开发过程中一旦发生用户需求变更，开发人员将不得不推倒重来或者对软件系统做频繁修改，从而影响软件开发效率和软件系统的兼容性。

（2）严格按照需求—设计—编码—测试—发布的顺序实施，若前一个环节未完成，后一个环节便无法开始，造成后续环节的实施工程师（比如测试工程师）在项目开始阶段将无所事事，但在最后的测试阶段将会加班加点，异常忙碌。同时，软件产品设计和架构的缺陷无法消灭在萌芽阶段，等产品差不多定型后再对测试环节发现的缺陷进行修改将会举步维艰，从而导致产品开发成本居高不下。

（3）测试在发布之前进行，由于技术性的和非技术性的干扰，一旦编码过程占据了比预期更长的时间，在总的开发时间不变的情况下，开发团队不得不压缩测试时间，从而导致本应该在测试阶段发现的问题没有被发现，或者来不及被发现，最终将导致软件产品的稳定性、可靠性、鲁棒性和容错性变得非常糟糕。

而在敏捷模型中，测试人员不仅是在编码完成之后才有用武之地，在开始编码之前的几天或者几小时，测试人员就应当编写反映用户故事的测试用例或测试项。测试人员通过执行手工测试来发现已有的测试用例可能存在的重要缺陷，也可以与团队其他开发人员结对执行自动化测试脚本，或者将自动化脚本添加到回归测试集中。

敏捷过程重视测试的作用，测试用例从另一个层面反映了用户需求，是用户需求的另一种表现形式，因此，测试人员对用户需求理解的程度以及技术实现细节，都会直接影响测试的广度和深度，并最终影响软件产品的质量。

敏捷过程与传统软件开发过程的一个重要区别是敏捷过程的“团队协作”机制。敏捷过程打破了原有的每人“一亩三分地”格局，强调团队协作所需的技能和资源，每个参与者都应当是多面手角色，“编写代码的人员同时参与自动化测试脚本的编写”“测试人员与编码人员结对走查代码并修改完善代码”等场景将会很常见。整个团队考虑得最多的是如何设计出有价值、高质量的软件产品给客户或用户，以实现团队价值。为实现该目标，敏捷团队必须具有交付高质量代码的过硬技能，这意味着团队中具有业务经验的资深开发人员应当占有一定比例，例如专业开发人员和测试人员。