作者：Isha Tripathi

翻译：老齐

与本文有关的图书推荐：《跟老齐学Python：Django实战（第二版）》

想象下面的场景：

这是一个黑暗的暴风雨之夜。闪电每隔几分钟就会划破天空。在远处，你可以看到一大堆几年前写的代码。这些代码大部分都被作者遗忘了，甚至找不到作者。你小心翼翼地接近它，却不知道从哪里开始。你惴惴不安地决定从某一处开始，不知道你的勇敢会给团队带来什么样的灾难。

如果这个场景不适合你，那么请想象下面的场景：

在一种叫做层层叠的益智类游戏中， 每一层都在另一层上保持不稳定的平衡。只要有一个仓促的动作，整座塔就倒塌了。

这正是处理遗留代码的感觉。让我首先描述一下我所说的“遗留”代码。我指的是：

源代码来自其他人和（或）源代码来自旧版的程序。

之所以继承，通常是因为你（作为公司或开发人员）需要接手另一个公司或开发人员编写的代码，并且需要扩展和维护上述代码库。我将要在这篇文章中讨论使用遗留代码的两方面的问题：

• 遗留代码库的常见问题
• 通过实现交付和代码质量的平衡，有效克服这些问题

代码覆盖率

我在使用遗留系统时遇到的一个常见问题是缺少测试。即使有测试的话，也很少有单元测试，也许还有一些集成或功能级别的测试——这些测试大部分都是事后进行的，而不是对代码进行实际的保护。大多数测试或所有测试只会涉及基本逻辑的场景，并且会忽略系统中的边缘情况。

这本身可能不是一个严重的问题，但随着系统的发展和开发人员的轮换，问题就出现了。人们越来越难以追踪这些变化对系统造成的影响，因为就写了一些孤立的东西或者使用了全局变量等等，这使得代码必须高度依赖“熟悉系统”的人。

毋庸置疑，并不是每个问题都可以通过增加代码覆盖率和进行更多测试来解决，但它确实有助于消除一些风险。我们都希望确保对系统的任何更改不会影响现有功能，更广泛的测试覆盖范围恰好有助于此。此外，更多的单元测试可以确保在较低的级别捕获逻辑问题，从而更容易识别出有问题的代码。

在一个理想的世界中，任何系统都将遵循测试金字塔——大量的单元测试，一些服务测试和较少的UI/功能测试。

然而，对于你可能遇到的大多数遗留代码库，测试金字塔可能看起来像这样：

当第一次使用类似于以上图像的遗留代码库时，一个常见的误区是试图立即开始编写单元测试。虽然目的是非常可贵的，但这也意味着你在那个时候不会创造任何业务价值。对于没有看到向系统中添加功能价值的客户来说，更难证明你这样做的意义。

一个更有效的方法是，首先为你所接触的任何一段代码或你所添加的新代码编写测试。这将有助于你找到一个中间地带，这种做法叫做纸杯蛋糕模式。