2.4  遗留代码修改算法

以下算法可以用于对遗留代码基进行修改：

(1) 确定改动点；

(2) 找出测试点；

(3) 解依赖；

(4) 编写测试；

(5) 修改、重构。

每日对付遗留代码的工作其实就是改改改，不过并不是随意地改。我们想要在做出能够带来价值的功能性改动的同时使系统中的更多部分进入测试的笼罩之下。在每次编完程之后，我们应当不仅能够指出那些提供了某些新特性的代码，还要能够指出其测试。随着时间的推移，代码基的受测试部分将会变得越来越大，就好像在海里不断生长的岛屿一样。在这些“岛屿”之上工作会容易得多。渐渐地，岛屿变成更大的陆地。最终你将能够在一块全面由测试覆盖的代码大陆板块上工作。

下面就让我们逐个看看以上描述的这些步骤，以及本书是如何帮助你实施它们的。

2.4.1  确定修改点

你所要进行修改的地点与代码的架构联系很紧密，前者敏感地依赖后者。如果你对代码设计的理解程度不足以让你觉得是在正确的地点进行修改的话，请阅读第16章以及第17章。

2.4.2  找出测试点

有些情况下找出测试点殊为易事，然而对于遗留代码来说这事儿往往就不那么容易了。请阅读第11章以及第12章。这些章节中介绍的一些技术可以用来确定出对于给定的改动要在哪些地方编写测试。

2.4.3  解依赖

依赖性往往是进行测试的最为明显的障碍。这表现在两个方面：一是难以在测试用具中实例化目标对象；二是难以在测试用具中（调用）运行方法。通常在遗留代码中你得先解依赖而后才能将测试安置到位。理想情况下我们为安置测试而进行解依赖的动作本身也应当受到测试的保护，这样一旦我们在解依赖时做了不妥当的事就会及时得知，然而这往往只是个奢望。请阅读第23章，其中描述的一些实践技术可以使你在将一个系统放入测试之下时所下手的第一刀（即第一处改动）变得更安全。之后再看一下第9章和第10章，这两章中描述的场景展示了如何解决一般的依赖问题。这些章节都大量引用了书的后面部分（第25章）所列举出来的解依赖技术，但并非全部。所以我建议你花点时间浏览一下后面罗列的目录，里面有更多用于解依赖的技术。

依赖性还会在另一种场合下显现出来，即当我们有一个关于测试的想法然而却不能容易地将其编写实施时。如果你发现之所以不能编写测试是因为大型方法中的依赖性未解决的话，请阅读第22章。如果你发现虽能够解依赖，但用在创建测试上的时间太长了的话，可以参考一下第7章。该章中描述的一些额外的解依赖技术可以用来减少平均构建时间。

2.4.4  编写测试

我发现为遗留代码编写的测试和为新代码编写的测试有些许不同。关于测试在遗留代码工作中的角色的进一步认识可参考第13章。

2.4.5  改动和重构

我提倡使用测试驱动的开发方式（TDD）来往遗留代码中添加特性。第8章中就描述了TDD以及其他用于添加新特性的技术。在对遗留代码做了一番改动之后，我们对其中存在的问题往往也就有了更多的了解，而所编写的用于辅助添加特性的测试则常常也能够“保护”我们去进行一些重构。第20章、第22章以及第21章这三章涵盖了可以用于开始将你的遗留代码挪上一条朝着更良好的结构前进的正轨的大部分技术。别忘了我在这些章节中介绍的东西只是“婴儿阶段”。它们并没有展示如何令你的设计变得理想、干净或者富含模式。这些问题在很多书中都有讨论，而当你有机会去使用这些技术时，我鼓励你去这么做。而本书中的上述章节则是告诉你如何令设计变得更好，这里更好的含义取决于具体问题的上下文，往往只是意味着比原先的设计可维护性更好一些。但你可别低估这一点。往往就是那些最为简单的事情（例如将一个大型的类分解成多个小类以便能够更容易下手）恰恰能够在应用程序中带来显著的不同，尽管这些事情看上去可能有点儿没啥创意。

2.4.6  其他内容

本书的其他内容展示了如何在遗留代码中进行改动。接下来的两章则包含了一些关于遗留代码工作的三个关键概念：感知、分离和接缝的背景知识。