重写旧系统的一场噩梦被我亲手终结

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

最终，我选择扼杀

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

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

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

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

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

如何“扼杀”旧代码库

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

（编辑：柳州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!