在遗留代码上开发—evelopment on legacy code）
class Manager{... public void kickOff(){ ... DoSomething doSomething = new DoSomething(...); doSomething.doSomething(objects); }...}

?可修改为：

?

class Manager{... DoSomething doSomething;   public void setAction(Action doSomething){   this.doSomething = doSomething; }  public void kickOff(){      ...      doSomething.doSomething(objects); }...}interface Action {void doSomething(List marks);}

?

为DoSomething提供了接口Action，采用诸如依赖，mock这个DoSomething这个类，测试kickOff()方法。

?

4.尽量使测试的范围缩小在受修改影响的类中，对类中的改动进行全面测试。保证每处修改完全测试，保证测试类减少。

?

5.类之间交互的代码重构，如果这些交互仅在修改的代码之中，只要保证修改的代码完全测试即可。而对于那些可能影响此时其他不需要进行修改代码的类，可以先放下，为其创建新的方法，在此次修改和以后修改中，使用和重构新的方法。对于老的方法，等到以后代码覆盖率提高，能够覆盖所有此类交互方法的代码时，重构此方法，这是你会发现，修改很简单，并且如果修改错误，或者不能处理极端的逻辑，也会和容易找出问题所在。

?

6.努力汲取业务逻辑知识。

?

7.《修改代码的艺术》（Michael Feathers 著）建议找到切入点（Inflection Point），往往我们找的点很多，每一次修改都可能不一样，为此花很多代价找寻，还不如直接进入修改，找出最佳的修改方式避免代码过度重构和修改，减少影响，这才是有有实践价值和有意义的。

?

质量保证

总之，和遗留代码打交道时，为了提高发布信心和效率，速度和质量是我们的追求。

?

1.尽可能让一切自动化：

?

单元测试自动化是最基本要求，尽可能让一切测试变得自动化，不管是单元测试，还是功能测试，还是压力测试，冒烟测试，回归测试。

?

发布自动化也是非常重要的。

?

2.为项目加入冒烟测试和回归测试。逐渐保证代码质量。

?

3.坚持可控变化，逐渐渗透的原则，保持系统稳步得朝健壮的方向进行。

?

关于重构推荐的书籍：

?

《重构:改善既有代码的设计》Martine Fowler著

?

《重构与模式》：Joshua Kerievsky著

?

?《修改代码的艺术》： Michael Feathers 著

?

参考：

?

?《修改代码的艺术》： Michael Feathers 著

?

本文作者：

现就任某公司金融软件高级资深技术架构师，著有《漫谈设计模式》一书(清华大学出版社出版)。

?

?