我的任务是保持一个适度大的系统(约60k LOC的非Moose OO Perl).我开始质疑重构它的智慧,而不是重写它.我知道这个问题已经详细讨论过,但情况异常复杂,有几个因素强烈指向相反的方向,因此我的问题.对不起问题的冗长; 在全面了解情况的同时,我可以尽可能地简洁.
正如系统所代表的那样,它的抽象很难干净地封装任何东西,这可以通过频繁依赖远距离的动作,大量使用if/else块来熟悉与手头模块无关的类型的对象,以及依赖性来实现.看起来像社交网络的图表.我觉得这很糟糕,但可以重构.
测试覆盖率不稳定.当然,这是可以修复的,需要在重构之前修复.当然,在这样的系统中,测试需要大量的脚手架,这使得测试覆盖范围的改善更加艰巨,但是,这几乎不可能.
所以我打算花很多时间慢慢为混乱带来秩序.我认为很难,但可行,系统确实能够很好地用于商业目的,尽管存在所有问题,所以必须做正确的事情.并且"每个人都知道"重写这样的东西是一种灾难.
但最近,我发现系统中一些最重要且写得最差的部分已经深深扎根并且严重的设计错误会一直进入数据模式.整个方法存在重大问题(这是那些已经研究过它的人的共识,而不仅仅是我),并且这方面的解决方案可能构成了该部分代码的一半,尽管它的编写很糟糕,以至于没有希望将它们区分开来.商业逻辑.代码对我自己来说太复杂了(我只用了几个月)或者以前的主要维护者(几年)才能完全理解.它的测试覆盖率也不到10%.
没有人相信他们能够完全正确地描述这一部分的成就,更不用说如何.当代码难以理解且其满足的要求未得到充分理解时,获得此部分的良好测试覆盖几乎是不可能的.没有测试覆盖率重构是不正确的,也不是远程实际在此规模,复杂的系统,利用这种普遍存在的问题(和动态类型做出改变不可能的影响的自动发现).
由于不断变化的业务需求,不能保持这个和黑暗的角落不受影响.
我能看到的唯一切实可行的方法就是在业务层面重新定义系统需求,并承诺满足该规范,并冒任何人无法预料的破坏风险.我知道这是一个糟糕的策略,但我没有看到替代方案.如果选择这种方式作为前进的道路,那么重构的好处似乎超出了窗口,这使我严重质疑甚至试图重构这一点的优点.
这引出了一个具体的问题:在这种情况下重构一个糟糕的策略吗？支持实际经验的答案是非常优选的,因为我认为理论方面在这里和其他地方已经很好地建立.