问题 我应该放弃重构这个并计划重写吗？ [关闭]

我的任务是保持一个适度大的系统（约60k LOC的非Moose OO Perl）。我开始质疑重构它的智慧，而不是重写它。我知道这个问题已经详细讨论过，但情况异常复杂，并且有几个因素强烈指向相反的方向，因此我的问题。对不起问题的详细程度;在全面了解整个画面时，我尽可能地简洁。

正如系统所代表的那样，它的抽象很难干净地封装任何东西，这可以通过频繁依赖远距离行动，大量使用if / else块以及与手头模块无关的类型对象的深入了解以及依赖性来证明。看起来像社交网络的图表。我觉得这很糟糕，但可以重构。

测试覆盖率不稳定。当然，这是可以修复的，需要在重构之前修复。当然，在这样的系统中，测试需要大量的脚手架，这使得测试覆盖范围的改善变得更加艰巨，但是，这几乎不可能。

所以我打算花很多时间慢慢为混乱带来一些秩序。我认为很难，但可行，系统确实能够很好地用于商业目的，尽管存在所有问题，所以必须做正确的事情。并且“每个人都知道”重写这样的东西是一种灾难。

但最近，我发现系统中一些最重要且写得最差的部分已经存在严重的设计错误并且一直存在于数据模式中。整个方法存在重大问题（这是那些已经研究过它的人的共识，而不仅仅是我），并且这方面的解决方案可能构成了该部分代码的一半，尽管它的编写很糟糕，以至于没有希望将它们区分开来。商业逻辑。这段代码对我自己来说太复杂了（我只用了几个月）或者以前的主要维护者（几年）才能完全理解。它的测试覆盖率也不到10％。

没有人相信他们能够完全正确地描述这一部分的成就，更不用说如何。当代码难以理解且其满足的要求未得到充分理解时，获得此部分的良好测试覆盖几乎是不可能的。没有测试覆盖的重构是不对的，在具有这种普遍问题的这种大小，复杂性的系统中也不是远程实用的（并且动态类型化使得无法自动发现变更的影响）。

由于不断变化的业务需求，不能选择保持这个和黑暗的角落不是一个选择。

我能看到的唯一切实可行的方法就是在业务层面重新定义系统需求，并承诺满足该规范，并冒任何人无法预料的破坏风险。我知道这是一个糟糕的策略，但我没有看到替代方案。如果选择这种方式作为前进的道路，那么重构的好处似乎超出了窗口，这使我严重质疑甚至试图重构这一点的优点。

这引出了我的具体问题：在这种情况下重构一个糟糕的策略吗？支持实际经验的答案是非常优选的，因为我认为理论方面在这里和其他地方已经很好地建立。