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

Question

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

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

2. 有很多重复的逻辑

3. 没有关注点分离
4. 有很多快速破解和硬编码字符串
5. 有过时和错误的文件
6. 要求没有正确记录！这实际上导致了过去测试人员、开发人员和客户之间的纠纷。当然还有一些非功能性的需求，比如不应该慢，不冲突以及其他应用程序用户知道的业务逻辑。但除了最常识性的场景和最常识性的业务工作流程之外，几乎没有关于应该（或不）做什么的指导。

？？？

Answer 1

您需要Michael C. Feathers 所著的《有效处理遗留代码》一书。

Answer 2

尽快编写测试。最好根据要求（如果存在）。从功能测试开始。小块重构。每当你接触代码时，让它比刚开始时更干净、更好。

Answer 3

两件事情。

1. 有机会就编写单元测试。
2. 一旦你有足够的单元测试有信心，就开始重构。

您完成此操作的速度可能很慢......通常，您应该“只是维护它”而不是修复它。

但是，在“学习如何维护它”阶段，您可以编写大量单元测试。

然后，当发现错误并请求改进时，您可以添加更多测试。

它是敏捷的，适用于遗留问题。

Answer 4

我已经看到，工作并且正在使用满足问题中提到的所有条件的代码库:-)

维护这个代码库的方法是不破坏任何东西。FWIW，代码有效，最终用户很高兴。没有人会听开发人员说存在重复代码、硬编码字符串等问题。我们只是抽出一些时间来修复任何可能的问题，并尽最大努力不引入新的错误。

Answer 5

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

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

• 当您意识到在多少个地方调用了逻辑时，这可能是一项艰巨的任务
• 看起来相似的两个函数可能有细微的差别，即 a - 而不是 +

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

Answer 6

须藤 rm -rf /

但更严重的是，我认为必须对其进行评估。如果代码一直是更改请求的来源，并且更改很困难，那么不久之后您就必须考虑是否值得尝试将系统重构/重新设计为更现代的东西。当然，这并不总是可行的，因此您通常最终会在团队中只有少数人负责维护遗留部分。尽可能让团队中的每个人都能够维护系统的所有部分......

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

Answer 7

我基本上同意 Paul C 所说的一切。我不是 TDD 牧师，但无论何时你接触到遗留代码库——尤其是你不太熟悉的代码库——你需要有一个可靠的方法来重新测试并确保你遵循了 Hippocrates：首先， 不要伤害。测试，特别是好的单元测试和回归测试，是实现这一目标的唯一方法。

如果您不熟悉的代码库，我强烈建议您阅读Reversing: Secrets of Reverse Engineering Software 。尽管这本书的深度超出了您当前的需求（以及我的需求），但它教会了我很多关于如何安全和理智地使用其他人的代码的知识。