使用旧代码

语境

大型组织的系统可能有成千上万到几百万行代码，而这些代码中有很大一部分是旧代码。

遗留代码是指没有测试的代码。 这些系统中的许多系统是在很多年前就开始编写的，而在今天我们认为很酷的事物和框架还没有出现之前。 由于某些系统的配置方式（数据库，属性文件，专有xml），我们不能简单地更改类构造函数或方法签名以传递依赖项，而无需进行更大的重构。 更改一段代码可能会破坏系统中完全未知的部分。 开发人员不习惯在系统的某些区域进行更改。 测试优先和单元测试没有被开发人员广泛使用。

规则

为了使现有系统更好，更可靠，更易于处理（更改和添加更多功能），我们建立了以下规则：如果测试未涵盖现有代码，则无法更改。 如果我们需要更改现有代码以编写测试，则应该仅使用IDE提供的自动重构工具来执行此操作。 如果您是像我这样的Java开发人员，则Eclipse和IntelliJ对此非常有用。

这意味着，在进行任何更改之前，我们需要对当前代码进行测试，以确保我们不会破坏其当前行为。 对现有代码进行测试之后，我们将为新功能编写一个新测试（或者如果对现有行为进行了更改，则对现有测试进行更改），最后我们可以对代码进行更改。

问题

在论坛，邮件列表和用户组中，关于TDD负责增加或减少团队速度的讨论是永恒的。 我不想在这里开始讨论，因为大部分时间我们都没有进行TDD。 对于遗留代码，我们将大部分时间花在测试现有代码上，然后才能进行TDD以满足新要求。 这很慢。 非常慢。 根据我们的经验，这可能比仅进行我们需要的更改和手动测试要慢5到20倍。

您可能会问，为什么要花这么长时间？ 我的答案是：如果还没有，请尝试对2000+行类中所有可能的执行路径进行单元测试？ 您是否尝试过使用1000行方法，充满多个return语句，硬连线的依赖项，重复负载，一大堆嵌套的IF和循环等来实现？ 相信我，这将花费您很长的时间。 请记住，编写测试之前不能更改现有代码。 只是自动重构。 安全第一。 :-)

为什么我们“表现不佳”？

在开始遵循此规则后，管理层经常会询问团队绩效不佳的原因。 尽管事实是团队需要花费更长的时间来实现某个功能，但这也是对该问题非常幼稚的看法。 当管理和开发团队谈论团队的速度时，他们只是考虑编写与一些特定需求相关的代码所花费的时间。

随着时间的流逝，管理层和团队只是忘记了他们花了多少时间在由于代码质量和测试不足而导致的事情上。 他们从来没有考虑过，开发人员绝对不可能手动测试整个系统并保证他们不会破坏任何东西。 对于他们编写或更改的每段代码，这将需要几天的时间。 因此，他们将其留给质量检查人员。

通过不增加测试范围，团队将永远不会拥有回归测试套件。 随着系统的规模和复杂性的增长，手动测试系统将由质量检查团队开始花费越来越长的时间。 由于测试脚本需要与系统的当前行为保持同步，因此也更容易出错。 这也是浪费时间。

同样，仅时无刻地修改代码将使系统更加脆弱，理解方式也更加复杂，这将使开发人员花费更长的时间来修改更多代码。

因为我们不能按下按钮，而只能对特定的代码进行单元测试，所以团队被迫花费大量时间调试应用程序，这意味着团队需要花费时间来编译和部署它。 在某些系统中，为了测试一小段代码，您需要依靠其他系统来触发某些事情，以便您的系统可以做出响应。 或者，您需要手动将消息发送到队列，以便调用您的代码。 有时，根据系统的复杂性及其依赖性，您甚至无法在本地运行它，这意味着您需要将应用程序复制到另一个环境（烟，UAT或公司中使用的任何名称）才能测试您编写或更改的一小段代码。 当您最终设法执行所有添加的代码行时，您意识到代码是错误的。 叹。 让我们重新开始。

自从开始练习TDD以来，我意识到我很少使用调试器，也很少需要部署和运行应用程序来对其进行测试。

因此，基本上，当人们认为我们因为首先为现有代码编写测试而花太多时间编写功能时，他们很少考虑在其他地方花费的时间。 我已经看过很多次了：“我们现在没有时间这样做。 让我们做一个快速修复。” 然后，与物理定律相矛盾，发现错误并需要延长QA阶段会花费更多时间。 恐慌接手：“哦，我们需要中止发布。 我们不能那样生活。” 究竟。

上图不基于任何正式研究。 这完全基于我在职业生涯中的经验。 我还认为，团队速度的下降与未经测试的代码的状态有关。 那里有未经测试的代码，编写得很好，并且对其进行测试非常简单。 但是，以我的经验，这将是一个例外。

总而言之，如果您不断应用“童子军规则”并始终不断改进您需要触摸的代码，那么随着时间的流逝，您将使代码变得更好，并且将变得越来越快。 如果您不这样做，您会在开始时会产生错误的印象，认为它具有良好的速度，但往往没有引起您的注意，就会逐渐放慢速度。 过去需要几天的时间，现在要花几周的时间。 由于这种速度损失是缓慢发生的（数月甚至数年），因此直到为时已晚，现在一切都需要数月，才真正注意到。

漂流而失去焦点

不断改进遗留代码，编写测试和重构的一个有趣的副作用是，它太容易被遗忘了。 我不止一次看到配对，同时尝试清除一段代码，逐渐偏离了他们正在处理的任务/故事。 这在我身上也发生了很多次。 我们在进步和使事情变得更好时会发疯。

最近，一位开发人员问我：“我们什么时候停止？”。 我的回答是：“当我们完成任务时。” 在这种情况下，这意味着重点始终放在手头的任务上。 我们需要继续交付与产品所有者（或负责要求的人）达成的协议。 因此，使系统更好，但始终将重点放在任务上。 不要在几天之内尝试重构整个系统的重构就发疯了。 做足够的工作以完成任务，并尝试隔离仍然不够好的部分。 宝贝的步骤。

更积极的副作用

遗留系统中的另一个非常普遍的问题是缺乏对系统以及业务的理解。 我们经常会遇到这样的情况，即开发人员和业务人员早已不在，而没人真正知道系统的行为。

为现有代码编写测试会迫使我们了解它的作用。 我们尝试在过程代码的中间挖掘一些隐藏的业务概念，并在命名测试时使其变得非常明确。 这是使用测试捕获的业务概念来推动我们以后进行重构的好方法。 通常，我们还会使业务人员参与进来，向他们提问，并检查某些假设是否有意义。

现在，在编写测试和重构代码时，测试和代码已很好地记录了系统以前完全未知的行为。

质量是一项长期投资

在最近的一次对话中，我们正在讨论如何衡量质量的“投资”。 一个简单快速的答案是，我们可以通过漏洞数量和团队交付新需求的速度来衡量这一点。 但是，这从来都不是那么简单。 问题是，为什么您认为自己需要质量？ 您今天遇到哪些问题，使您认为它们与质量有关？ 质量到底是什么意思？

在处理传统时，多年后，我们往往会忘记过去的情况。 我们只是“接受”事情需要很长时间才能完成，因为它们已经花费很长时间了。 我们只接受（长期）质量检查阶段。 这是过程的一部分，不是吗？ 这是错误的。

不断提高遗留系统的质量水平可能会在该项目上花费的时间和金钱产生巨大的差异。 这就是我们追求的目标。 我们希望提供更多，更快，没有错误的工具。

由我们（专业软件开发人员）来恢复这种状况，以显示出对客户的良好态度和尊重。 我们绝不能让自己陷入因自身无能而导致工作速度和质量下降的情况。

参考： 使用我们JCG合作伙伴的 遗留代码   制作软件博客上的Sandro Mancuso。

翻译自: https://www.javacodegeeks.com/2012/03/working-with-legacy-code.html