您将如何维护遗留应用程序

Question

您将如何维护以下遗留应用程序：

1. 没有单元测试有大方法

2. 有很多重复的逻辑

3. 没有分离关注
4. 有很多快速黑客和硬编码 字符串
5. 有过时和错误 文档
6. 要求未正确记录！这实际上导致了过去测试人员，开发人员和客户之间的争议。当然，存在一些非功能性要求，例如不应该慢，不要冲突以及应用程序用户已知的其他业务逻辑。但是，除了最常见的场景和最常见的业务工作流程之外，对于应该（或不应该）完成的内容几乎没有指导。

???

Answer 1

您需要图书Working Effectively with Legacy Code by Michael C. Feathers。

Answer 2

尽快编写测试。优选地违反要求（如果存在的话）。从功能测试开始。以小块重构。无论何时触摸代码，都要比开始时更清洁，更好。

Answer 3

两件事。

1. 在有机会的情况下编写单元测试。
2. 一旦你有足够的单元测试来自信，就开始重构。

你完成这个的速度可能很慢....通常，你应该“只是维护它”而不是解决它。

在“学习如何维护”阶段，你可以编写很多单元测试。

然后，当找到错误并请求增强功能时，您可以添加更多测试。

它是敏捷的，适用于遗产。

Answer 4

我已经看到，工作过并且正在代码库中工作，该代码库满足问题中提到的所有条件： - ）

维护此代码库所遵循的方法是不打算。 FWIW，代码工作，最终用户很高兴。没有人会听开发人员的呼声，即有重复的代码，硬编码的字符串等等。我们只是偷了一些时间来修复任何可能的事情并且非常谨慎地不引入新的错误..

Answer 5

我想我会创建一小组最新信息：什么动作调用哪些功能等。

从那里，我会考虑重构。重复逻辑似乎是可以重构的东西，但请记住

• 当你意识到逻辑被调用多少个地方时，这可能是一项艰巨的任务。
• 两个看似相似的功能可能会有微小的差别，即a - 而不是+

我认为抵制的最大冲动是“重建整个该死的东西！”并首先了解系统，揭开野兽的神秘面纱。

Answer 6

sudo rm -rf /

但更严重的是，我认为必须对其进行评估。如果代码不断地是变更请求的来源并且变化很困难，那么不久之后你必须考虑是否值得尝试将系统重构/重新设计成更现代的东西。当然，这并不总是切实可行，因此您最终只需要团队中的一些人负责维护旧部件。尽可能地，团队中的每个人都应该能够维护系统的所有部分......

我认为另外一件重要的事情是跟踪团队在执行维护/功能请求的遗留系统上花费的时间和精力。在评估替换旧系统/组件的新工作的规划时，这些指标可能是令人信服的。

Answer 7

我基本同意Paul C所说的一切。我不是TDD牧师，但无论何时你触及遗留的代码库 - 特别是你不熟悉的代码库 - 你需要有一个坚实的方法来重新测试并确保你跟随希波克拉底：第一， 不要伤害。特别是测试，良好的单元和回归测试是实现这一目标的唯一方法。

如果它是您不熟悉的代码库，我强烈建议您选择Reversing: Secrets of Reverse Engineering Software的副本。虽然这本书深入到了你当前需求之外的深处（就我而言），它教会了我很多关于如何安全和合理地使用其他人的代码的方法。