debugging - 处理神物

Question

我在一个中等规模的团队中工作，我经常遇到这些令人痛苦的大类文件。我的第一个倾向是用刀去砍他们，但这通常只会让事情变得更糟，让我的精神状态变得很糟糕。

例如，假设您刚刚获得了一个 Windows 服务来工作。现在此服务中存在一个错误，您需要先弄清楚该服务的作用，然后才能有希望修复它。您打开该服务，发现有人决定只使用一个文件来处理所有事情。开始方法、停止方法、定时器、所有处理和功能都在那里。我说的是数千行代码。一百行代码以下的方法很少见。

现在假设您无法重写整个类，并且这些上帝类会不断出现，那么处理它们的最佳方法是什么？你从哪里开始？你首先要尝试完成什么？你如何处理这种事情而不只是想被刺伤。

如果您有一些策略来控制自己的脾气，我们也欢迎。

到目前为止的提示:

1. 建立测试覆盖率
2. 代码折叠
3. 重组现有方法
4. 记录发现的行为
5. 以渐进式改进为目标

编辑:

查尔斯·康威推荐了一个播客，结果非常有帮助。 link

Michael Feathers(播客中的人)以这样的前提开始:我们太害怕简单地将项目脱离源代码控制并直接使用它，然后丢弃更改。我可以说我对此感到内疚。

他实质上是说拿走你想了解更多的东西，然后开始把它拆开。发现它的依赖关系，然后打破它们。无论它走到哪里，都跟随它。

很棒的提示 获取在其他地方使用的大类并让它实现一个空接口(interface)。然后使用该类获取代码并让它实例化接口(interface)。这将为您提供代码中该大类的所有依赖项的完整列表。

Answer 1

哎呀!听起来像是我以前工作的地方。

看看Working effectivly with legacy code 。它有一些关于如何处理残暴代码的精华。

DotNetRocks 最近做了一个 show关于使用遗留代码。没有什么 Elixir 可以让它发挥作用。

我听到的最好的建议是开始在测试中逐步包装代码。