驯服烂代码场景之一：活多时间紧，但我的新代码依赖于烂代码，我该如何改烂代码？

指导思想：将新代码与烂代码实现逻辑分离，这样只是对新代码写单元测试并实施TDD，而无须对烂代码写单元测试。

手法之一（当新代码的职责与烂代码明显不同，且烂代码的类已经塞满了许许多多彼此不同的职责，而新职责在很多地方被调用时）：外敷类，即使用Decorator模式将新职责外覆在烂代码的职责之上，用TDD来开发新职责类。

手法之二（当新代码的职责与烂代码明显不同，且烂代码的类很难实例化并放入单元测试用具中）：新生类，即将新职责放入一个新写的类中，并用TDD来开发新类，烂代码调用新类的方法。

手法之三（当新代码的职责与烂代码的职责同等重要，代码很脆弱，IDE重构工具不好使）：外覆方法，即创建一个和原烂代码方法同名的新方法，在新方法中调用烂代码原先的方法，或者干脆创建一个新方法，用TDD方法开发新方法。

手法之四（烂代码以前的方法的职责已经清晰地呈现出来了）：新生方法，即用TDD方法创建一个新方法，由烂代码调用。

心法之一：省时间，虽然用TDD写新代码要费些时间，但是新代码的职责没有搅和在烂代码中，便于我今后的代码理解，节省我今后读代码的时间。

心法之二：成就感，新代码的职责有TDD的单元测试罩着，而不是搅和在烂代码中无法测试，这样新代码的实施就没有挫败感，增加了自己的专业精神的自豪感。