我目前正在处理的代码中,逻辑和数据访问都出现在GUI类中。显然,我想改善这种情况。
当前的结构基本上是:
- 庞大的代码堆积
最终目标是实现像DDD一样的结构:
- DAL
- 领域模型
- 服务层
- 展示模型
- GUI
那么,你会如何解决这个问题呢?
- 全面重构
- 定义最终状态的结构并将代码推到其最终位置。
- 分而治之
- 尝试将庞大的代码堆积分成两部分。重复此过程直到完成...
- 勒索
我目前正在处理的代码中,逻辑和数据访问都出现在GUI类中。显然,我想改善这种情况。
当前的结构基本上是:
最终目标是实现像DDD一样的结构:
那么,你会如何解决这个问题呢?
永远不要尝试“大爆炸”。它几乎总是会让你吃亏,因为当其他所有方法都失败时,这是一种高风险、绝望的措施。
分而治之:如果你的世界只有两面,那么这个方法很有效。但在真正的软件中,你必须同时征服很多方面,所以你很少有机会生活在一个非黑即白的幻想中。
我想我在我的职业生涯中一直在使用类似“扼杀”的东西:逐渐将糟糕的旧代码转变为闪亮的新代码。以下是我的步骤:
从某个地方开始,不管它是哪里。编写一些单元测试来了解代码的实际行为。弄清楚它做你认为它要做的事情的频率和它不做的频率。使用你的IDE重构代码,以便可以测试它。
第一天后,猜测你是否已经开始了正确的地方来拆散这个怪物。如果是,继续。如果不是,找一个新的地方重新开始。
这种策略的优点:它采取小步骤,因此风险可以控制,如果出现问题,它必须是在你上周正在工作的代码中。
缺点:需要很多时间,而且你会感到沮丧,因为经常会觉得进展缓慢,直到“结”的部分突然解决,一切都像魔术般自然地落入了位。
http://mikadomethod.wordpress.com/
还有一场关于Mikado方法的演讲来自于Øredev 2010。
http://oredev.org/2010/sessions/large-scale-refactorings-using-the-mikado-method
取决于你是否需要始终保持工作状态,以便在必要时进行错误修复和部署,那么分而治之将是一个不错的解决方案。如果你可以在编写新代码的同时维护旧代码(并有纪律性地将错误修复应用于两个代码库),那么重写可能是更好的解决方案。
对我来说,这取决于情况。
如果是一个非常小的项目,我会考虑从头开始重写它...然而你很少有这种奢侈。
如果不行,我会逐步地分解它。我会编写单元测试来验证现有功能,并慢慢使用TDD将代码转换为优雅和良好设计的系统。根据这个过程需要多长时间,它可能会开始看起来像你上面提到的StranglerApplication。
BigBang非常危险,因为你没有简单的方法来验证更新后的系统是否与旧系统执行相同的操作。
分而治之比BigBang风险小...但如果它是一个足够大的系统,它可能会变得像BigBang一样棘手。
大爆炸/大重构/重写软件等其他名称都不能为现有软件提供支持。
原因如下:您仍然需要使用(可能是)相同的资源来支持现有软件。
您可能没有重写的要求。您的旧代码已经嵌入了所有要求。您的工程师不知道所有的软件领域和所有的要求。
重写需要时间。在此期间,您将发现现有软件已经改变以支持这段时间内所需的东西。 您的新软件实际上是从原始软件中分离出来的,需要合并(这也需要时间)。
是否考虑全面重写?根据我的经验,从头开始重写通常比试图清理现有混乱的代码更有效率。您仍然可以保留现有代码的部分内容,但在新的上下文中使用。如果您有GUI和数据库,也同样适用。从头开始重写,并带上您可以使用的内容。