在遗留系统之上工作的一个可行方法

前几天看到一篇文章说，大学的时候经常从头开始写代码，出来工作工作后一直都是改代码。对这句话，深有感触，因为我现在也在干同样的事情，而且还不知道要干到什么时候。说到底，我们很多时候会工作在遗留系统之上。工作的思路和方法与从零开始一个项目应该是不一样的。有一本书《Working Effectively with Legacy Code》专门来指导大家如何工作在遗留系统之上。

编程工作可以分为四个类型：

1. 增加特性

2. 修复缺陷

3. 重构

4. 优化

每个类型有不同的侧重点。可能使改善既有代码的结构，可能是增加或修改功能，也可能是渐少对资源的需求，提供系统效率。我们可以用下面的表格来描述四个类型之间的异同。

	增加功能	修复缺陷	重构	优化
结构	√	√	√
新功能	√
既有功能		√
资源使用				√

我们有两种方法来开展工作：

方法1：编辑代码，然后祈求福祉。

方法2：写测试覆盖改动的代码，然后在做修改。

你可能会想这两种方法的本质区别在于测试在前还是在后。然而这两种方式还是有很多不同的地方：

其一，先写代码会造成先入为主的思想误区。认定自己的改动已经完备了，满足了新功能的要求，也不会破坏既有功能。后面的测试都是在验证自己的假设，随着测试一直没有出现问题，更加坚信自己的改动没有问题。

其二，修改后测试，可能减少了多代码整体的认识。方法1可能使人在没有完全、正确了解代码的情况下做出改动。

其三，测试的侧重点不一样。方法1更多的是用户角度的测试，比如集成测试，黑河测试。方法2更多的是实现角度的测试，比如UT，白盒测试。

其四，方法2更加有利于回归和重构的进行。

既然方法2是一个比较好的办法，那就应该有一个可复用的过程：

1. 去除依赖

去除依赖的目的有两个：一是优化既有代码的结构；二是试代码具有可测易测性。比如两个类相互依赖，这样测试要想测试其中的一个类就非常困难。类似的情况还有很多，一个类依赖于数据库连接，一个类依赖于网络连接，这类属于依赖于具体。

不仅仅是类层次的依赖，还有模块之间的依赖，编译之间的依赖，都是可以考虑的问题点。

2. 编写测试

3. 修改代码和重构

关于2和3，最好的实践是结合TDD。完全的TDD可能并不能轻易实施，比如达不到UT Case 1/10秒的速度要求，既有开发流程对TDD不友好，但通过测试熟悉代码，覆盖代码，进而进行修改和重构可以积极借鉴。