如何处理遗留代码？绝望案例

Question

我有个方法问题。我面临的是一个相当大的遗留系统()。对于它的代码库-as，团队中的每一个人我都是新手--因为这是我们在外包过程中的一种产品，业务人员之所以决定引进它，是因为它成为了商业上的关键。

该项目目前的状况是：

• 没有人在该系统上工作(除了一位高级开发人员)，这意味着我们对系统内部的实际工作几乎一无所知。
• 代码库的设计非常糟糕(根本没有测试，甚至没有OO设计)。
• 建筑是复杂的，而且没有很好的文档。
• 它与许多第三方组件/系统集成。
• 它对业务至关重要(操作24/7同时处理财务交易)。
• 我们害怕做任何修改，因为如果没有适当的测试覆盖，我们不知道我们是否破坏了一些东西。记住钱是有关系的。
• 没有合适的单元测试是可能的，因为没有面向对象的设计。只有黑匣子集成测试在某种程度上是可行的(请注意它与第三方系统(如支付服务)的复杂同步和异步交互)。
• 由于OO设计不好，很难识别、隔离和排除系统的单个功能.

问题是:你将如何对待这个怪物的再造？我们想要获得对其内部的信心，绝对改进它的OO设计和testability....but如何安全地开始？

理想情况下，我们应该是一个敏捷的团队，但是从这个起点不确定解决这个问题的最佳方法。到目前为止，我们已经开始添加很少的集成测试，但无论如何，我们对take....We没有任何告诉我们是否正在破坏东西的甲骨文/文档没有信心。

Answer 1

在类似的情况下，我们最终将所有输入和输出文件保存到/从生产中的系统中保存。有了它们，我们可以构建一个测试设置，并拥有一个测试工具(运行输入文件仍然提供相同的输出文件)。

然后，我们可以慢慢地开始重构和揭示系统的实际需求，并最终重写主要部分。