01｜遗留系统之殇：为什么要对遗留系统进行现代化？
关于遗留系统的误区
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
遗留系统并非仅仅因为存在时间长而被定义，而是应该根据其代码质量、架构、测试、DevOps以及技术和工具等方面来判断。文章通过作者的项目经历，深入探讨了遗留系统的误区。作者以自身经历为例，指出时间长短并非衡量遗留系统的标准，而是系统的代码质量差、架构混乱、缺乏测试、落后的技术和工具等才是遗留系统的真正特点。文章强调了遗留系统的现代化改造的必要性，为读者提供了对遗留系统的深入了解和分析的基础。 遗留系统的特点和问题主要包括代码质量差、架构混乱、维护成本高昂、合规和安全问题、缺乏测试、落后的DevOps手段以及技术和工具存在安全漏洞等。这些问题导致遗留系统的维护成本高、合规和安全方面存在隐患、难以集成新系统，以及核心数据难以互联等挑战。 遗留系统的定义是使用旧的方法和技术的、过时的，却仍旧在使用的计算机系统。这些系统往往具有重要性，但却存在着旧、过时的特点。举例包括医院的急救寻呼系统和仍在使用的Windows XP系统。 现代化改造对于遗留系统的重要性不言而喻，需要引起企业的重视和投入。文章提到了遗留系统的现代化价值，包括成本、数据资产和业务知识。现代化改造需要从代码、架构、DevOps和团队结构等方面对遗留系统进行治理，以应对挑战和提升企业的核心竞争力。 总的来说，本文深入探讨了遗留系统的定义、特点、现代化改造的重要性以及现代化的方向。读者可以从中了解到遗留系统的挑战和价值，以及应对遗留系统现代化的必要性。
《遗留系统现代化实战》，新⼈⾸单¥59
全部留言(21)
- 最新
- 精选
子夜枯灯置顶目前工作的遗留系统是单体应用，架构混乱并且没有任何测试。每次开发时都需要大量的人工测试。方案文档不连续，参加价值很低。作者回复: 这是非常典型的遗留系统，后面的课程会涉及如何添加自动化测试，如何在没有文档的情况下梳理业务，希望对你有所帮助。
2022-04-123
aoe置顶在遗留系统中上班写bug加班改bug 目前应对策略； 1、新功能使用TDD开发 2、修改原有功能时尽量加一些测试 3、修改特别复杂的原有功能，基本靠运气作者回复: 1和2能做到已经相当棒了，超越了绝大多数遗留系统。 3你可以试着先把复杂功能做一下重构，把复杂的代码拆分成相对容易的代码。后面课程会讲如何重构遗留代码。 一起加油！
2022-04-1262
刘大明老师您好，感谢抽空回答。接上次提问。 我先介绍下项目背景，和自身定位. 自己属于客户二开工程师，也就是针对现有的代码进行二次开发。 开发ide:eclipse 开发数据库:oracle11g 开发代码：本地home文件库 痛点如下： 1.全国各地是部署在各个项目本地机器上面，开发的代码包括源文件全部集中在本地环境，导致代码没有版本管理，会导致开发的文件冲突。 2.项目属于老旧巨石项目，本地home文件库一般都是10几G以上，数据库都是几百G，而且很多都是内网环境，可能需要挂VPN才能访问。 3.平时的开发模式，就是先操作页面，然后录入操作日志，定位具体的代码文件，然后本地起开发环境去debug该文件，根据现象去定位具体的代码可能出现的问题(可能需要重复debug的次数)，找到问题之后，修改相应代码，一般不敢新建文件，只能在旧文件里面去新增方法，导致代码坏味道很重，但是不敢重构。 4.测试，修改代码完成之后，重启服务(可能需要10来分钟)，之后在页面看效果，成功就给实施出相应文件的补丁包，实施经理将补丁放到线上环境验证改动是否成功。 说明：因为自己还是老测试方式，起服务，页面手动看效果，然后debug跟踪代码，debug效率有时候会很慢，不然定位不到具体的问题。 想请教下老师，基于这样一个背景下，以及自己的身份，怎么最大化提高工作内容呢，或者说针对这种遗留项目需要怎么做，才能变的更好呢？现在有点迷茫。。。。作者回复: 你好，你的迷茫我十分理解，这样的遗留系统的确十分棘手。从你的描述看，似乎看不到业务方/甲方主动重构或替换系统的希望，那么我只能从技术侧试着给你一些建议： 1. 立即给代码加入版本管理（这个不需要太多工作量），否则代码合并起来太麻烦，增加了很多认知负载（下节课会介绍什么是认知负载）。 2. 尝试给系统的关键特性添加一些端到端的测试（针对后端），自动化测试可以重复运行，比人工调试要方便很多；针对Swing的测试工具都比较老了，不知道还能不能跑，你可以试一下Swinger、Squish等等。 3. 代码库10G的话，需要看一下是否都是源代码，是否把一些依赖的工具包、系统应用上传的文件、图片等也放到了代码库中，如果是的话，把这部分摘出来，给代码库瘦身。 4. 尝试从业务影响这个方面去说服客户，比如系统太旧bug修改缓慢会影响业务、旧系统难以支撑企业创新等等，看看客户是否愿意投资重新开发或者购买新的软件。 希望对你能有帮助。
2022-04-1235- 刘大明现在在维护老项目，基于本地的工作库开发，工作库很大有10几个G，而且源码都是根据class反编译出来的才能二次开发，有些页面是基于swing开发的，但是客户已经习惯了这种操作模式，想请教老师，这种开发模式属于遗留系统，应该怎么改造呢？
作者回复: 你好，这是第一个留言，感谢你学习这门课。 很遗憾，根据遗留系统的定义，你维护的系统肯定是一个遗留系统，而且问题很严重。单从你的描述无法了解全部细节，我就先从这些线索中给你一两个建议： 1. 既然“客户已经习惯了这种操作模式”，我猜从客户方来说，就没有修改的紧迫性，可能是系统尚能满足需求，或者是“可以将就着用”。这时遗留系统造成的问题，主要是给开发者的，而不是业务方。只有业务方切实感受到痛点（如交付周期太长，bug太多），才会同意改造。所以，你可以进一步说说，系统的需求量是什么样的？交付周期是多长？是否每次都能按质按量交付？ 2. 从开发角度来说，不知道你说的“工作库”是不是指的代码库，如果是的话，强烈建议你按模块进行拆分，否则很难一次性打开整个工程，甚至编译一次都需要很长时间。拆分之后可以更聚焦，效率更高。当然如果代码耦合很严重，这种拆分也是很难的。 你可以再多介绍一些细节，我们一起来想想办法。加油！
2022-04-115 
lipop自动化测试需要做到分支覆盖吗，分支覆盖的话感觉光是写测试用例就超过了开发的时间作者回复: 账不能这么算。要看你一个需求的交付时间，包括开发、测试、修bug、上线（假设上线后没bug了）的时间。你在开发时编写了自动化测试，开发时间看似延长了，但同时也缩短了修bug的时间。要算总账，不要纠结于局部。 另外，全面的自动化测试本身就是软件质量强有力的说明，没有测试的代码，质量好不好，谁也不知道。你可以问问需求方，是要量还是要质。我猜他们一定是两个都要的。
2022-04-182- 2022痛点： 1. 项目周期安排紧凑，总有各种各样的原因导致项目延期 2. 设计之初写的设计文档，大致方向没问题，细节上会出现多处变动，但项目开发完后，没人去更新设计文档了。人员流动后，对于修复该模块的bug，可能存在改一发而动全身 3. 开发的代码，没有进行自动测试，全依赖人工测试 4. 开发人员水平高低，导致即使有设计文档，但写出来的代码架构完全没法看（只保存了最终需求是按照设计文档上做的）。
作者回复: 感谢分享，是十分典型的遗留系统。
2022-04-241 
_MISSYOURLOVE
如此看来，我们维护的也是一个遗留系统了；据说系统最初的版本是由外包团队开发，后面由公司自己的技术团队接手开始维护，代码质量一言难尽，基本就没有什么文档可言，都已经2022年了，某些项目还一直是使用前后端耦合的方式在进行维护着，由于年代久远，某些业务功能连产品都不知道具体逻辑，需要进行改造的时候，还需要我们去看代码然后给产品梳理相关的业务逻辑作者回复: 确实是非常典型的遗留系统
2022-04-171
公号-技术夜未眠老师好，遗留系统和现代化系统进行集成的策略和步骤有哪些？谢谢作者回复: 后面的课程中会有涉及
2022-04-111
术子米德🤔☕️🤔☕️🤔 * 📖：遗留系统 ：！=长时间存在的系统，！=短时间存在的系统。判断维度：代码<cha>、架构<luan>、测试<wu>、DevOps<shou>、技术<jiu>、工具<lao>等方面。 * 🤔：代码差，可以重写；测试无，可以补上；DevOps手动，可以改造；技术旧，可以学习；工具老，可以更新；可是，架构乱，难道要重来嘛，那所有的可以都变得可以，还是都变得不可以。这是架构带来的最大困惑，它不是问题的时候，就当它不存在，它称为问题的时候，就像空气里放进点硫磺，怎么也弄不干净的味道。不过，如果核心问题真的是架构乱，重写、补上、改造、学习、更新估计都不顶用。架构的问题，要么是基因病，要么是血液病，发作起来，所有的组织和结构，都无法幸免。 * 📖：遗留系统蕴含数据资产，隐藏业务知识，它很重要，它还能用。 * 🤔：遗留系统有点像泥石流后形成的冰川，又乱又脏的感觉，搬不动挪不走的样子。但是它蕴含着大量的淡水，它携带着气候变化的信息。作者回复: 感谢分享
2022-04-22
西米我们现在的系统就是一套大的单体系统，虽然它才上线5年，目前是基于 .net core 3.1 。部署在Azure web app上，看了老师您这篇文章，我可以很快的定义它为：遗留系统，因为没有 devops、测试全靠人工黑盒测试。目前公司也下定决心开始 大力全新打造一套系统。作者回复: 加油，这其实并不算是特别“遗留”，还是相对好改的
2022-04-18
