不少工程师对旧项目和代码库谈之色变。但如果旧代码反复遭到黑客入侵，那就躲无可躲，必须提出有效的方案解决这个“不定时炸弹”。

选择重写：噩梦的开始

复杂繁多的应用程序往往牵一发动全身，当你想重做部分应用时，发现其他的应用程序也会受到影响。

更糟糕的是，当你更改代码前试图编写单元测试时，发现该代码最初并没有设计成可测试的代码。所以，在进行了种种挣扎和尝试后，你可能就会把这个应用程序冻结起来，再也不想碰它了…

那么，有没有一种办法既能更改无法维护的代码，又能使局面不那么糟糕呢？

我们知道，更改代码存在一定风险，而重构成本又太高。在这种情况下，从头开始重新编写代码看起来是个不错的主意。

按照这个思路，接下来会发生什么？

你在重写现有应用程序的同时，与管理层讨论一段时间内停用新功能。
重写一个包含现在应用程序功能的新程序大约耗时6个月。
几个月后，出现了一个令人讨厌的bug，并且这个bug必须在旧代码中修复。因此，你又修补了旧代码和新代码。
再过几个月，公司将一些新功能交付给了客户。但新功能必须用旧代码才能实现，因为新版本尚未准备好。你不仅要再次返回到旧代码中，还要添加一个TODO以便这些新功能在新版本中实现。
转眼5个月过去了，你意识到项目可能要延迟，旧应用程序远比想象得要棘手。
7个月过去了，你开始测试新版本，QA质量检查发现了很多需要修复的问题。
9个月后，公司再也受不了“不开发功能”。领导开始不满，你为此身心俱疲。你一边挣扎着更改旧代码，一边加快速度重写代码。
最终结果是，你做出了两个系统。摆脱旧代码还需要一段时间，因为新代码还没准备好。每个功能都需要在新系统和旧系统中实现两次。

最终，我选择扼杀

我现在的项目，就是在处理这个问题。我们内部有两个并行工作的系统：cart（旧系统）和 booking（新系统）。实际上，booking应该替换掉cart。

该项目始于三年前，但三年过去了，项目仍然未完成。

booking总体上讲要优于cart，但并不是说所有方面都比cart出色，一些购买流程会使用booking，但仍有很多流程沿用cart。

现在，由于新旧系统并行工作，所以新功能的实现时间是原来的两倍。有趣的是，由于最初的设计目的并不是为了支持我们想要的新功能，而是因为booking已经过时了，所以才会建议“适当重写cart系统。”

如果按照这个思路，接下来几个月，我们可能要让两个系统并行运行。显然，这不是个好办法，我还知道另外一种能有效解决系统问题的办法，就是“扼杀”。

方法很简单：逐步删除旧的代码库，使用新的代码库。

具体操作如下：

来说说我们的系统，我们有一个用于处理付款的cart模块。

我们尝试重写，想法是创建一个新的、比cart更好的booking支付方式。但是这个项目没有100％交付，因为重写工作耗费了太多时间，我们不得不在旧cart系统上开发新功能。

最终，我们还是创建了两个模块。

让我们再试一次，这次我们来“扼杀”cart模块。与上一种方式不同的是，这次我们引入新booking模块作为代理服务器。

设置起来很容易。很快，我们可以在不重复付款处理逻辑的情况下将其交付生产。然后，逐步地，我们可以开始将付款逻辑迁移到新的booking模块。

在迁移逻辑时，我们摆脱了cart模块上未使用的代码。这个过程可能会需要一段时间，但我们正逐渐摒弃掉旧的、难以维护的cart，开始应用新的、更好的booking。

这样做最好的地方是可以解决重写期间无法交付新功能的问题。使用这种技术，无需复制代码，更无需实现两次新功能。另外，你需要尽快将新系统投入使用，更快地获得反馈，最大程度减少工作量并且降低把事情搞砸的风险。

最后，你可以有条不紊地进行重写，而无需将代码冻结6个月。尽管“扼杀”可能带有暴力色彩，但这种隐喻恰恰描述了慢慢摆脱旧系统的方法，与完全转换相比，这样做的风险较小。当旧代码实在难以使用时，这可能是迈向更好设计的第一步。

如果你在从事领域驱动设计（DDD），我建议你采用这种方法逐步淘汰旧系统。

你可以将旧系统视为黑匣子，创建一个Bubble Context ，在其中应用部署DDD原理。Bubble Context 与旧系统进行交互。逐渐地，新功能将在不断增长的Bubble context中实现。同时，业务中用到旧系统的机会也越来越少，直到有一天，你可以彻底关闭旧系统。

原文链接：
https://understandlegacycode.com/blog/avoid-rewriting-a-legacy-system-from-scratch-by-strangling-it/