有一个中型遗留应用程序（20K LoC，150个java类）。设计和代码的质量非常低，没有单元测试，没有文档。但是它有效。
您被雇用来维护该应用程序。有一个非常具体的报告错误列表。理解如何修复它们非常困难。时间有限，你应该在几周内开始解决这些错误（你根本没有时间进行深刻的重构）。怎么做？
答案 0 :(得分：2)
从第一个错误开始。也许最简单，也许是最高优先级。无论你的商店有什么意义。
请勿修复。
相反，找出它为什么不能正常工作。根据您的描述，它不太可能采用一些整洁，美观，可单元测试的方法;它可能深藏在一些错综复杂的逻辑中。找到它。
请勿修复。
找出解决罪魁祸首的方法。也许是Extract Method;也许它是Extract Class;也许其他一些技术会有所帮助。但是把它拿出去，独立于其他代码。仍然失败，只是更容易使用。现在，编写一个演示失败的测试。
好的，现在修复它。
你做了什么？您已经解决了问题，修复了问题，使代码的一小部分更容易使用，并开始实现测试覆盖。泡沫，冲洗，重复。
答案 1 :(得分：1)
我认为你的情况并不好。
我首先从“重构”这项工作开始。向老板说明情况非常困难。你还应该明确指出，既然你不负责制造混乱，他现在需要承诺不让你对没有成功负责，但是你会尽力而为。如果他不愿意在这种情况下事先做出承诺，那么我会找到另一份工作。
现在的问题是如何继续。无论你做什么，你都会在代码中发现问题，并且随着你的进展，这样做会更容易。
首先，您必须浏览代码并获得一些结构感。如果您认为自己理解某事，请插入评论;如果你不这样做并且很重要，请插入带有问题的评论。如果可以，请添加断言。如果这些新断言破裂，如果它们很容易解决，那么这样做;如果没有，你可以通过简单地删除它们或将它们变成问题评论来对它们进行分类。这些评论，问题和断言至少会记录您（不）理解的低级细节。
我还会得到一个工具，可以让你可靠地重命名重构 （强调后者：你不能让这些代码破坏代码比它更糟糕）。疯狂和虔诚地重命名将有助于稳定代码和你的词汇量，并摆脱坏名字。你可以在略读/处理代码的同时以非常低的成本实现这一点，并且在可读性方面获得巨大回报。
要找到错误的（潜在）来源，我会使用测试覆盖率工具。这样的工具告诉你在运行“测试”时执行了什么代码。创造性地使用这样的工具，您可以运行一个“测试”（手动或自动，实际）来执行错误;通过测试覆盖工具点亮的代码必须包含某处的bug。您可以运行其他没有出现错误的“测试”;他们执行的代码与bug跟踪相同，可能不包含bug。
问题是如何在执行的代码中计算这种“差异”？一些测试覆盖工具将帮助您确定这一点。我的公司（Semantic Designs）提供了这些：Test Coverage tools for many languages，它正是这样做的。通常，测试覆盖率向量用于显示代码，其中覆盖显示覆盖范围。我们的工具将允许您处理独立的测试覆盖集：交叉，差异，联合等，以了解生成向量的测试之间的关系，并显示叠加在代码上的结果。这样，您可以直接查看错误的测试覆盖率向量与非错误的测试覆盖率之间的差异。
一旦你知道了bug的位置，就可以在相关代码中加入更多的断言，然后再次运行bug生成测试。触发的指标是你接近的指标。
我最初避免需要严格的代码重构来修复的问题，因为你在时间压力之下。 （在你意识到问题出在哪里之前，你显然不能很清楚这一点;探索是不可避免的成本）。在某种程度上你可以尽早解决一些问题，你会购买政治观点。您可以使用它们来获得更多时间，因此有机会进行更多重构。