《修改代码的艺术》之如何让新加代码都在测试范围下

在《Clean Code》一书中，Kent Beck说过我们有80%的时间是在维护代码，因此编写Clean Code很重要，但是，如果大家一来就面对已经开始腐烂的代码怎么办呢？《Working Effectively With Legacy Code》一书给出了答案，该书可以说是《Clean Code》和《Refactoring》的结合体。该书列举了工作在Legacy Code上的程序员会遇到的各种各样的情况，然后给出了在各种情况下，可以选择的策略。

[b]场景一：时间紧迫，必须修改[/b]
可采用的策略有
1、新生方法：当需要修改的代码能够独立成块的时候，使用新生方法。
2、新生类：为某个类添加新的职责，或者被修改的类很难放进测试。
3、外覆方法：当出现2个行为需要同时出现时实现，使用外覆方法有2种形式，一是创建与原方法同名的方法，然后修改原方法名，另一个是创建一个新的方法。
4、外覆类：当想添加的行为是完全独立的，或者是原类已经很大，不想让它变得更臃肿。
其实从场景来看，这四个策略都是很容易修改代码，添加新特性，而且危险系数很低，尤其是在有IDE的refactor功能帮忙的情况下，另外，这几个策略，解决的都是无法把原类纳入测试范围中，可是，却想把新增加的功能纳入测试范围下的难题。即使再急，也必须写测试，不然代码就会彻底腐烂了。

[b]场景二：漫长的修改[/b]
工作在遗留代码上时，理解现有代码将是一个漫长的过程，把现有代码纳入测试范围也是一件非常耗时的过程，没有测试，对于我们的每一个修改，获取反馈的周期会特别长，而这就是影响我们工作效率最大的凶手。而无法把现有代码纳入测试的一个最大原因就是现有代码的依赖，因此，对于这个场景，作者的建议策略就是解依赖，具体步骤如下：
1、定位哪些依赖类会成为拦路虎
2、对依赖类进行接口提取
这也就是面向对象经常说的依赖倒置原则，提取结构以后，就可以通过一些很简单的fake对象来完成原代码类的实例化，从而就很容易把其纳入测试范围下，从而缩短修改代码的反馈时间，最终缩短修改代码的时间。