QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

如何在不破坏原代码的情况下重写旧系统

  • 2020-02-19
  • 本文字数:1889 字

    阅读完需:约 6 分钟

如何在不破坏原代码的情况下重写旧系统

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

选择重写:噩梦的开始

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


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


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


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


按照这个思路,接下来会发生什么?


  1. 你在重写现有应用程序的同时,与管理层讨论一段时间内停用新功能。

  2. 重写一个包含现在应用程序功能的新程序大约耗时 6 个月。

  3. 几个月后,出现了一个令人讨厌的 bug,并且这个 bug 必须在旧代码中修复。因此,你又修补了旧代码和新代码。

  4. 再过几个月,公司将一些新功能交付给了客户。但新功能必须用旧代码才能实现,因为新版本尚未准备好。你不仅要再次返回到旧代码中,还要添加一个 TODO 以便这些新功能在新版本中实现。

  5. 转眼 5 个月过去了,你意识到项目可能要延迟,旧应用程序远比想象得要棘手。

  6. 7 个月过去了,你开始测试新版本,QA 质量检查发现了很多需要修复的问题。

  7. 9 个月后,公司再也受不了“不开发功能”。领导开始不满,你为此身心俱疲。你一边挣扎着更改旧代码,一边加快速度重写代码。

  8. 最终结果是,你做出了两个系统。摆脱旧代码还需要一段时间,因为新代码还没准备好。每个功能都需要在新系统和旧系统中实现两次。

最终,我选择扼杀

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


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


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


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


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

如何“扼杀”旧代码库

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


具体操作如下:


  • 让新代码充当旧代码的代理服务器(proxy)。用户使用新系统,新系统重定向到旧系统。

  • 在新代码库重新实现每步操作,这种操作在终端用户看来没有任何变化。

  • 通过让用户使用新功能来逐渐淡化旧代码。删除旧的、未使用的代码。

实际操作

来说说我们的系统,我们有一个用于处理付款的 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/


2020-02-19 13:324901

评论

发布
暂无评论
发现更多内容

设计模式与敏捷开发

架构师 架构是训练营

BIGO全球计算平台的技术挑战

DT极客

【架构师训练营】第三周总结

Mr.hou

极客大学架构师训练营

架构师训练营 - 第三周 - 作业

韩挺

架构师训练营作业 --Week3

吴炳华

极客大学架构师训练营

week03 单例作业以及组合模式

李锦

极客大学架构师训练营

Linux性能优化实战-第一天学习

程序员老王

c++ 性能调优

架构师训练营 - 作业 - 第三周

心在飞

极客大学架构师训练营

作业 - 第三周

Happy-Coming

设计模式代码实现

dony.zhang

Kotlin实现组合模式

Acker飏

极客大学架构师训练营

架构师训练营第 3 周作业

在野

极客大学架构师训练营

架构师训练营第三周作业

大丁💸💵💴💶🚀🐟

为什么建议你使用枚举?

王磊

Java 枚举

架构师训练营 - 第三周 - 学习总结

韩挺

如何学习设计模式

elfkingw

极客大学架构师训练营

Apache Zeppelin:可能是开源届最好的Flink开发平台

Geek_8o1tcx

大数据 flink 流计算 Zeppelin

看完这篇 HashMap,和面试官扯皮就没问题了

苹果看辽宁体育

Java 源码分析

week03 架构师培训营总结

李锦

是时候扔掉 Postman 了,Apifox 真香!

狐哥说技术

Postman 面向接口编程 Apifox 接口文档 接口测试

macOS Big Sur、iOS14测试版描述文件

Winann

iOS14 macOS Big Sur 描述文件

拍一拍,微信史上最短一行代码,是如何被网友玩坏的!

程序员生活志

c++ 微信

腾讯健康码16亿亮码背后的Elasticsearch系统调优实践

腾讯云大数据

大数据 elasticsearch

读懂一个 demo,入门机器学习

陈东泽 EuryChen

人工智能 tensorflow 学习 AI

手写一个单例

Acker飏

极客大学架构师训练营

观察者模式详解

Seven七哥

设计模式 观察者模式

漫画通信:有了它,终于可以放心买买买了

阿里云Edge Plus

云通信 短信 语音 通信云

锦囊篇|一文摸懂Glide

ClericYi

架构师训练营 - 第三课作业 -20200624- 单例及组合模式

👑👑merlan

架构设计 极客大学架构师训练营

冒泡排序

wjchenge

冒泡排序

架构师训练营第三周作业

好名字

作业

如何在不破坏原代码的情况下重写旧系统_文化 & 方法_Nicolas Carlo_InfoQ精选文章