大话重构连载3：在保险索上走钢丝

当我们开始系统重构的时候，不是着手去修改代码，而是首先建立测试机制。不论什么程序，只要是被我们修改了，理论上就可能引入BUG，因此我们就必须要进行测试。既然是测试就必须要有一个正确与否的评判标准。以往的测试，其评判的标准就是是否满足业务需求。因此，测试人员往往总是拿着需求文档测试系统。

与以往的代码修改不同，重构没有引入任何新的需求，系统原来什么功能，重构以后还是这些功能。因此，重构的测试标准就只有一个，就是与之前的功能完全保持一致，仅此而已。

然而在许多经典的重构书籍中，大师们总是建议我们首先建立自动化测试机制，这已经被我在无数次实践中证明是不现实的。要知道我们现在重构的是一个遗留系统，它往往设计混乱，接口不清晰，程序相互依赖。所有这些都使得最初的自动化测试变得非常困难而不切实际。

因此，从一开始就实现自动化测试是不切实际的，我们所能采用的还是手工测试。在重构之前首先将系统启动起来，执行相应的功能，得到各自相应的输出。然后开始重构，每次重构对代码的修改量不要太大，花费的时间不要太长。因为，修改量太大，花费时间太长，一旦测试不通过，很难定位错误的原因。在这种情况下，我们只能还原代码，将此次修改的工作完全作废。如果此次修改已经花费了你数天甚至数月的时间，这样的损失就实在太大了。

每做一次重构，修改一点儿代码，然后提交，对系统进行一次测试。如果系统依然保持与以往一样的功能，重构成功，继续进行下一次重构。如果不是，你不得不还原回来重新重构。频繁地测试着实让你挺烦的，但却有效减少了重构失败带给你的损失。一个折中的办法就是，平时频繁测试的时候，测试项目少一些，只测试主要项目，定期再进行全面地测试。录制QTP 脚本也是一个不错的方式，它虽然有诸多问题，但却可以在系统重构初期有效地建立自动化测试，系统级别的自动化测试。随着系统重构的不断深入，我们的程序开始在改善，耦合变得越来越松散，程序变得越来越内聚，接口变得越来越清晰。这时候，当自动化测试条件成熟时，我们才可以逐渐开始自动化测试，而这种自动化测试才是建立在代码级别的真正的自动化测试。

一旦某个修改测试不通过，则还原回来。这种一次一小步的修改模式，我们形象地称之为“小步快跑”。在测试集成工具的不断监督下一点一点地修改程序，是系统重构异于以往的另外一个特点。通过小步快跑可以使我们在重构的过程中，以最快的速度发现修改的问题，将因修改错误带来的损失减到最小，毕竟是人都不可能避免犯错。

大话重构连载首页： http://fangang.iteye.com/blog/2081995
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！