我的任务是保持一个适度大的系统(约60k LOC的非Moose OO Perl).我开始质疑重构它的智慧,而不是重写它.我知道这个问题已经详细讨论过,但情况异常复杂,有几个因素强烈指向相反的方向,因此我的问题.对不起问题的冗长; 在全面了解情况的同时,我可以尽可能地简洁.
正如系统所代表的那样,它的抽象很难干净地封装任何东西,这可以通过频繁依赖远距离的动作,大量使用if/else块来熟悉与手头模块无关的类型的对象,以及依赖性来实现.看起来像社交网络的图表.我觉得这很糟糕,但可以重构.
测试覆盖率不稳定.当然,这是可以修复的,需要在重构之前修复.当然,在这样的系统中,测试需要大量的脚手架,这使得测试覆盖范围的改善更加艰巨,但是,这几乎不可能.
所以我打算花很多时间慢慢为混乱带来秩序.我认为很难,但可行,系统确实能够很好地用于商业目的,尽管存在所有问题,所以必须做正确的事情.并且"每个人都知道"重写这样的东西是一种灾难.
但最近,我发现系统中一些最重要且写得最差的部分已经深深扎根并且严重的设计错误会一直进入数据模式.整个方法存在重大问题(这是那些已经研究过它的人的共识,而不仅仅是我),并且这方面的解决方案可能构成了该部分代码的一半,尽管它的编写很糟糕,以至于没有希望将它们区分开来.商业逻辑.代码对我自己来说太复杂了(我只用了几个月)或者以前的主要维护者(几年)才能完全理解.它的测试覆盖率也不到10%.
没有人相信他们能够完全正确地描述这一部分的成就,更不用说如何.当代码难以理解且其满足的要求未得到充分理解时,获得此部分的良好测试覆盖几乎是不可能的.没有测试覆盖率重构是不正确的,也不是远程实际在此规模,复杂的系统,利用这种普遍存在的问题(和动态类型做出改变不可能的影响的自动发现).
由于不断变化的业务需求,不能保持这个和黑暗的角落不受影响.
我能看到的唯一切实可行的方法就是在业务层面重新定义系统需求,并承诺满足该规范,并冒任何人无法预料的破坏风险.我知道这是一个糟糕的策略,但我没有看到替代方案.如果选择这种方式作为前进的道路,那么重构的好处似乎超出了窗口,这使我严重质疑甚至试图重构这一点的优点.
这引出了一个具体的问题:在这种情况下重构一个糟糕的策略吗？支持实际经验的答案是非常优选的,因为我认为理论方面在这里和其他地方已经很好地建立.
去过那里，做到了。我目前维护的遗留代码是几个非 CS 人员（工程师）的累积努力，他们开始让他们的程序实现所需的功能，而几乎不考虑可维护性、灵活性或可扩展性。
但对我有用的可能并不适合所有人。
在这种情况下，列出所有相关标准并权衡一个人的选择通常是有帮助的。我倾向于问自己以下问题：
您的雇主是否看到代码重写/重构的价值？
做正确的事很容易被冲昏头脑，但只有在您得到雇主的支持时才这样做。
我的经验- 如果业务没有看到重写/重构的价值，那么你真的应该把这个活动放在次要位置。在尝试根据需要编写/修改/测试任何内容之前，专注于记录现有代码并更好地了解代码的工作方式。
新的更新/功能请求多久添加到代码中？
此类活动进行得越频繁，重构/重写的理由就越强。
我的经验-有时对业务更有价值的是您使用现有代码并以最少的修改为其应用记录良好的补丁。
该代码将需要在 n 个月后执行功能 X。今天的能力如何？
如果开发正在进行，这适用。着眼于长期，看看代码需要能够做什么，以及它在当前状态下能在多大程度上满足这些需求。
我的经验- 重构有时并不能解决问题，因为代码的当前状态严重不足
实施所设想的变化需要多长时间？
估算应包括理解、记录、实施、测试、验证和发布修改所需的时间。
我的经验- 它真的比人们最初想象的要长得多，尤其是测试和验证。
| 归档时间： |
|
| 查看次数： |
288 次 |
| 最近记录： |