【译】如何跳过古董代码的坑

做者：Isha Tripathi

翻译：老齐

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

---

想象下面的场景：

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

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

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

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

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

之因此继承，一般是由于你（做为公司或开发人员）须要接手另外一个公司或开发人员编写的代码，而且须要扩展和维护上述代码库。我将要在这篇文章中讨论使用遗留代码的两方面的问题：

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

代码覆盖率

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

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

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

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

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

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

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

注：纸杯蛋糕模式被视为反模式，由于相同数量的信息是在多个层次上测试的。然而，与传统（遗留）的代码库相比，这更适用于绿地代码库。若是你从头开始一个项目，绝对应该避免这种模式。在传统的代码库中，正是这种迫切须要但并不理想的中间地带，帮助铺平了通往理想状态的道路。

随着时间的推移，你对系统更加熟悉了，就能够继续在全部级别添加测试，并对你的项目实现一个可接受的测试金字塔。

过期的库/技术

我遇到过这样的状况：开发人员很是不肯意升级到新版本的库，由于引入的更改会形成破坏；或者因为担忧破坏系统而继续使用过期的工具和技术来编写项目。

这些担忧是彻底正确的，绝对值得考虑。然而，人们必须记住，使用过期的工具和库会形成的反作用。这些反作用可能会在最不经意的时候累积起来，并咬伤你。旧的工具一般再也不受支持，并且很难找到问题的答案。还有一个事实是，随着时间的推移，你的需求会发生变化，在某些时候，过期的工具将再也不知足你的需求。

为了不这些误区，请确保在项目中始终使用库和工具的最新版本。库的频繁更新还意味着你在升级时不会须要作出大量更改。大多数的库不会在不一样版本之间（我从你的角度来看）作出重大更改，更新起来应该至关简单。即便你必须进行一些更改，更改中所花的时间也比确保整个项目的版本兼容性所花的时间更有效，由于项目中可能会有一个依赖项没法升级。

使用过期工具的必然结果是最终不得不使用极新的工具。有些工具/库仍处于测试阶段或者甚至没有一个主要版本，使用这些工具/库就要冒着不受全部平台支持的风险。我建议远离这样的库，除非你的项目有一个很是具体的利基要求。

重构

做为一名开发人员，我常常忍不住直接进入代码库，开始从新编写我认为能够改进的代码。在处理遗留代码时，第一步是阅读并理解代码，当某一部分代码理解起来很是吃力时，你会但愿重构代码，让其余团队成员避免一样的痛苦。虽然你的队友会欣赏这样的行为，但它可能会损害项目的总体状态，由于它没有增长任何功能价值或业务价值。正如我以前所说的，你很难向客户证实这种作法的合理性，由于客户寄但愿于你所带来的商业价值。在尝试重构这样的代码时，也很容易误入迷途。即便你决心对重构进行时间限制，你也可能会身不禁己，由于你不想让本身的精力白费。

不要绝望，由于有一种方法能够处理你不太理解的代码。每当你渴望重构某段代码时，请问本身如下两个问题：

• 这段代码是我正在开发的功能的一部分吗?
• 这段代码当前的形式是否不够完善?

若是这两个问题的答案都是否认的，那么就不要对其进行重构。与代码覆盖同样，只重构那些在实现过程当中要用的代码。其余的一切均可以添加到这个项目的“技术债务墙”。一般状况下，所谓的“墙”外观以下：

墙是一种方法，用来记录代码中的问题，或者记录你所继承的代码。技术债务墙并非糟糕的设计决策的倾销地，我认为这是不言而喻的。它应该只应用于跟踪现有的问题，团队应该有意识地在项目过程当中下降技术债务。我在一些项目中的作法是：在获得有关人员或产品全部者的批准后，优先处理迭代中的一些技术任务，以平衡所要交付的功能价值和技术价值。若是你只关注技术价值，客户会不高兴的；而若是你只关注功能价值，会不断积累技术债务，你的代码会愈来愈难以维护。

结论

处理别人的代码库并不老是有趣或容易的，坦率地说，有时会使人沮丧。这多是因为人们对代码的书写方式有不一样的观念，代码的原做者能力有限，或其余的一些因素。然而，这是大多数软件开发人员在他们的职业生涯中必须处理的事情。

我在处理别人的代码的实践中积累了一些有用的作法，并尝试着作了如上记录。

原文连接：www.womenwhocode.com/blog/dealin…

搜索技术问答的公众号：老齐教室

为了方便你们阅读、查询本微信公众号的资源，回复：老齐，便可显示本公众号的服务目录。