国外专家教你如何处理遗留代码

　　建立这类自动化的最佳方式是什么？最快捷、最容易的方法就是使用一个持续集成（CI）产品。CI产品可以监视你的代码，在每次修改后构建，运行测试，然后通知所有相关人员。

　　持续集成图

　　CI系统会创建一个快速反馈循环。当你修改代码时，如果代码遭到破坏，你就会在忘记为什么修改它之前发现它。（关于CI系统的更多信息，请访问我的CI页面 .net/ci.html">http://www.jaredrichardson.net/ci.html）。

　　所有这些讨论都是关于开发速度和持续不断的进度的。对于保持团队的进度，回顾上周或者上个月所编辑的代码是一条末路，而在数小时内抓住并且解决问题才是真正的解决之道。

　　这里描述了系统是如何进行工作的：你在电脑上编写代码，直到你确信已经完成了某个功能或者修补了某个缺陷，然后你将所作的修改提交到源代码管理系统中 （SCM）。持续集成系统一直监视着SCM，注意到该段代码发生了改变。接着，它就会从SCM中检出代码，构建它，并且运行整个测试。你也将会及时地收到 一封邮件，通知修改和测试是否已经通过或者失败。

　　这个概念相当简单，但是它在实践中力量非凡。

　　测试

　　BAT最后一部分就是指自动测试。现在CI系统正在构建产品，运行你的自动测试，我们需要确信我们的测试充分地覆盖了整个产品。毕竟，从客户的观点来看，如果一个测试不能检验客户所使用的功能，那它就是没用的。

　　首先，设法理解产品是如何使用的……对于一个遗留产品，这常常是出于自身的要求。或许，你甚至要为客户创建一套使用场景。例如，恐怕你要有一组场景，生成日常的报表，完成日常的数据导入，或者增加新的客户。

　　或许，你也想区分用户类别，它被称为“用户角色”。你恐怕要有“Joe——超级用户”、“Mary——系统管理员”或者“Fred——新用户”等用户角色。每个角色使用了该产品中不同的功能，正如一个超级用户与一个新手使用该产品是大相径庭的。

　　下一步就是使用模拟客户测试来重现大多数的普通客户使用场景。

　　模拟客户测试

　　模拟客户测试（Mock Client Test）并不是一套特定的测试框架。它的目的是用来确保预期的功能不会被破坏。你要改变系统中的一部分，却不知道这个修改影响了产品的其他区域，这在遗 留产品中经常出现。曾经我编写一个产品时，修改了通讯协议，却影响了GUI组件布局。CI系统中的模拟客户测试，是你预防意外修改的保障策略。对产品是否 如你所预望进行测试，就会有一个坚实的产品基线。而且测试也会包括更多有趣的情形，正如你所遇到的那样。

　　一个优秀的测试策略是缺陷驱动测 试（Defect Driven Testing）。每次你发现一个系统缺陷，就增加一个相应的测试。当你增加该个测试时，你可以尝试增加一些与该测试相近而不同的测试。随着时间的推移， 这个策略为产品最需要涵盖的范围，提供了相当可观的测试覆盖率。

　　不管你如何选择增加测试，都要设置测试优先级。如果你计划对产品进行任何修改，有一个基本的测试套件是最关键的。

　　最后一步就是将测试集成到持续集成系统。

　　当自动测试运行在持续集成环境下时，你会及时地得到关于所有问题的反馈。每次你修改一段代码，你就会“从头开始”构建和运行完整的测试。大多数开发者很快就会沉浸于此，并且很快依赖这个 “编外成员”。

　　。编写场景

　　。创建模拟客户测试

　　。使用持续集成

　　小结

　　构建、自动化和测试（BAT）对于程序员都是好的建议，但是它对于继承遗留代码者尤其好。拥有自信的重构能力非常关键。我发现如果我要不断地停 下来去查看我正在破坏什么，这种境况下变得高效则很困难。一个好的测试套件可以替我进行监视，而且能够让我集中精力设法完成性能改进。

　　记住，如果你不能测试遗留代码的话，那么就不要修改它。而且不要单纯地进行手动测试，除非没有其他选择。

　　不仅不要害怕遗留代码，还要正确地对待它。用BAT这种方法来处理它，你就会每次都能成功。

　　关于作者

　　Jared Richardson是《Ship It！ A Practical Guide to Successful Software Projects》 一书的作者之一。他是一名演说家和独立顾问，擅长使用非定制技术来解决疑难问题。Jared有着十年丰富的工作经验，曾经做过顾问，开发者，测试者和经 理，包括很多公司开发部主管。直到最近，他领导SAS软件研究所（SAS Institute，Inc.）的一个开发团队和测试团队，为三百个项目，五百万行代码和超过1800个开发者部署了一个持续集成系统。他也带领整个公司提高了测试自动化的使用。