07 | 遗留系统现代化的五种策略：重构还是重写？这是一个问题
姚琪琳
你好，我是姚琪琳。
从今天开始，我们正式进入模式篇的学习。这一部分我会带你学习代码、架构、DevOps、团队结构四个现代化中的各种模式，这些模式是我们实战的理论基础，希望你能牢牢掌握。
不过深入学习这些模式前，今天我们先从重构和重写的“两难”问题说起。到底是重构，还是重写？这是一个困扰着很多团队的问题。
重构吧，遗留系统积重难返，重构之路遥遥无期，三年、五年时间，可能也只是刚开了个头，还不如重写。
但重写就真的比重构好吗？遗留系统中最难获取的就是业务知识。当你问起一块业务时，得到的回答往往是：“没有文档”、“没人知道”或者“只能看代码”……没有业务，或者说没有需求，怎么可能构建出来一个新的系统呢？
那我们到底应该如何应对呢？除了重构和重写，还有没有其他方式呢？
遗留系统现代化的五种策略
Gartner 在 19 年曾经有一篇报道，提出了遗留系统现代化的七种方案。我把这七种方案做了整合，把它们整理成后面这五种策略。它们各有各的特点，而且分别对应不同场景，你要根据项目自身情况选择不同的策略或组合。然后，再应用后面要讲的模式来落地。
Encapsulate
第一种策略是 Encapsulate，也就是将遗留系统中的数据或者功能封装成 API，供外部调用。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
遗留系统现代化的五种策略：重构还是重写？这是一个问题 姚琪琳在文章中介绍了遗留系统现代化的五种策略，以及它们的特点和适用场景。这五种策略分别是Encapsulate（封装）、Replatform（替换运行时平台）、Rehost（迁移部署环境）、Refactor/Rearchitect（代码和架构调整）、Rebuild/Replace（重建或替换）。这些策略各有特点，读者可根据项目情况选择不同策略或组合，以实现遗留系统的现代化。 除了上述策略，还有Retain（保持系统当前状态）和Retire（完全停止使用）等策略。选择适当的策略需要综合考虑目标和系统现状，以实现业务敏捷、运营效率、客户洞见、系统韧性与弹性等目标。 作者提供了一些思考题，例如在升级.NET Framework版本时的选择，强调了根据具体情况做出决策的重要性。 总的来说，本文介绍了遗留系统现代化的多种策略及其适用场景，强调了根据项目情况选择不同策略组合的重要性。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《遗留系统现代化实战》，新⼈⾸单¥59
《遗留系统现代化实战》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(10)
- 最新
- 精选
webmin短期计划，应急先升级到4.6.2 4.8已经是没有未来的技术，升上去以后，将来还是要升级到5.0，那就要评估这两周到一个月的工作，会不会给将来升级5.0带来收益，即减少升级5.0的时间，如果是否定，那么不升级4.8，考虑直接升级到5.0。 升级到5.0需要五到六个月，但这是一个总时间，可以考虑把项目进行拆分，化整为零，一部分一部分的升级到5.0， 例如： 1. 通过拆分为微服务，进行部分升级； 2. 通过条件编译一部分一部分把依赖项目升级为支持.net Standard标准的代码。作者回复: 感谢分享，非常好的思路，遵循了增量演进的原则。
2022-04-2513
人间四月天很赞 我做过所谓遗留系统的重构升级，您说的7种策略和方法都用到了，这就是所谓的套路和经验，其实这样方案，我们也是通过成本，收益，风险进行权衡，方案是解决问题，要达成目标的，通过总目标和细分目标牵引方向，不跑偏，得到最佳收益，对于策略和方案，有个难点是确定改造的范围和评估工作量，评估风险，例如重构代码，首先要知道哪些代码有坏味道，评估哪些功能不用了，最好都有工具支持，这样能够精准快速确定范围，做完了也通过工具去验证。 个人愚见作者回复: 感谢分享，很赞。
2022-04-2527
HoshinoKanade我正正遇到这处境。遗留系统是ASP .NET，全部代码封装在一个专案里。咱们看到第三方库无法顺利过渡到NET core，于是像楼上说的先拆成几个库打包成NET standard。然而ASP.net core跟前一版差异很大，要硬着头皮上去也得花两三个月吧，于是放弃虽可耻但有用。 做到一半，因为这项目像个后妈生的，所以全人员被抽调到亲儿子项目，大部份同事辗转因跨地域和不适应工程文化等相继离职，现在成为一个不折不扣的遗留系统，还得我加班去做这吃力不讨好的项目。它的前端的jQuery也很多年没更新过，依赖的初代angular也经已EOL了。我们还得为这上了线的系统修修安全隐患，只是这样一来，升级到angular.js的最终版后，又啥都毁了。有时候无论风险，该做的还是得做，该加班还是该加班。作者回复: 感谢分享。 关于前端，可以考虑引入微前端，用新的前端框架（React或Vue）做新的功能，和老的AngularJS并存，再慢慢绞杀。 总之，任重而道远，加油！
2022-05-281
怀揣梦想的学渣从第一课看到这，站在我自己的角度，我认为这个课程并不适合新人，更适合有2年以上开发工作经验的人，姚老师分享的思考，不是一个新人可以深刻理解的。作者回复: 确实不适合新人，比较适合有一定工作经验的资深开发和架构师
2022-08-16归属地：河北
特修斯之船如果没有人力和时间的压力，会选择方案3 方案1与方案2只是治标不治本，这个技术债迟早要还的。 而且这个升级拖得越是久，到时候出来.NET6或.NET7，升级的难度只会越来越大。作者回复: 感谢分享。 理想情况下肯定3是相对来说“一步到位”的，但现实往往会有更多约束，除了升级还债，还有业务需求要开发，所以肯定不会是那么理想的。
2022-04-26
aoe方案1，原因： 1、最简单 2、风险低 3、可解燃眉之急作者回复: 感谢分享
2022-04-25
花花大脸猫短期先不做升级，如果业务发展上后续发展需要跨平台和容器化，那需要将5.0作为升级的目标，进行时间规划，根据时间规划逐步的进行往5.0的目标迈进；如果说业务上的发展可预见的不需要4.8或者5.0上面的最新的特性功能，那直接升级到4.6.2作短期的过度升级即可。2022-10-04归属地：江苏
雨落～紫竹如果比较紧急 必须升的话 也是先1后3 给自己缓冲期 如果没必须升级的必要 并且工作量不大 会考虑方案32022-06-22
王王王王王王。方案2，我们的系统就是这么升的，前两年把旧代码从3.5到4.5，后面又由于技术需要升到4.7.2，虽然也想大跨步，但为了不影响业务需求，只能稳步提升，毕竟活下去是最重要的2022-05-19
JC先1，快速解决眼下的问题；后面再按照系统的业务价值，以及未来的发展方向（是否会长期存在），决定怎么做2022-04-29
收起评论
