佛山模板网站建设,鄂州第一官方网站,免费建站网站一级大录像不卡在线看网页,西安工装装修公司排名遗留系统之殇#xff1a;为什么要对遗留系统进行现代化#xff1f;
Hi#xff0c;我是阿昌#xff0c;今天学习记录是关于遗留系统之殇#xff1a;为什么要对遗留系统进行现代化#xff1f;的内容。
不知道你是否跟曾经一样#xff0c;身处一个遗留系统的漩涡之中为什么要对遗留系统进行现代化
Hi我是阿昌今天学习记录是关于遗留系统之殇为什么要对遗留系统进行现代化的内容。
不知道你是否跟曾经一样身处一个遗留系统的漩涡之中每天为毫无头绪的代码和混乱不堪的架构发愁。
一个新的需求来了都不知道从哪儿开始改起即便看似简单的需求都要很久才能上线。 到底什么样的系统才能称之为遗留系统呢它存在哪些问题复杂在哪里 一、关于遗留系统的误区
一个问题假如一个系统七八年了它是不是个遗留系统系统的时间长等同于就是遗留系统这是很多人的一个误区。
虽然大多数遗留系统确实是存在的时间很长但并不等于时间长的都是遗留系统。一个项目上工作 6 年多这是一个有着 12 年历史的老项目。
它的技术栈最初是.NET Framework现在已经有部分迁移到了.NET Core它最初是单体架构现在是一个小单体加多个微服务它从第一行代码开始就使用 TDD 的方式开发至今已经有 30000 多个不同类型的测试它一开始使用 SVN 来管理源代码不过早在十年前就被迁移到了 Git它从第一天就有 CI/CD 相伴并且一直坚持基于主干开发的分支策略每个月都有稳定的版本发布它没有一行注释但是任何开发人员都能通过阅读源代码快速了解系统的实现也就是说代码质量相当高……这个系统历时 12 年之久比很多公司活的时间都长。
那它是遗留系统吗答案是否定的。
因为它的代码质量高、架构合理、自动化测试丰富、DevOps 成熟度也高各种技术、工具都是相对先进的怎么能说是遗留系统呢 思考一下存在时间短的系统就不是遗留系统吗
一个项目它仍旧是基于 JDK 1.4 的那个时候 Java 6 已经发布 4 年了很多 Java 的新特性都无法使用。它是一个 C/S 结构的软件前端基于 Java 富客户端后端是一个大单体向前端提供 RPC 服务
它没有一行测试每改一行代码都提心吊胆有时为了不影响别的功能只好把代码复制一份加入自己的逻辑这就导致了大量的重复代码每次发布日期都是一拖再拖而部署到生产环境上的 war 包甚至在是开发机器上打包的……别看这个系统只开发完 3 年但毫不客气地说它从刚开发完毕的那一刻起恐怕就是个遗留系统。
它的代码质量差、架构不可演进、没有自动化测试、缺乏 DevOps各种技术、工具也十分落后、老旧这样的系统即使刚开发完也是遗留系统。
那么从上面的描述看已经发现了我判断遗留系统的几个维度代码、架构、测试、DevOps 以及技术和工具。
所以说啊时间长短并不是衡量遗留系统的标准。代码质量差、架构混乱、没有测试、纯手工的 DevOps或运维、老旧的技术和工具才是遗留系统的真正特点。 二、遗留系统的特点和问题 首先就是代码质量差。说优秀的代码都是相似的而糟糕的代码则各有各的糟糕之处。一个有着 6000 行代码的单个方法至今印象深刻。其中包含 6 个大的 if/else 块每个块中大概有 1000 行左右的代码这 6 个 1000 行的代码只有十分细小的差别。显然是开发人员为了偷懒不敢在原代码上改动于是复制出来加入自己的逻辑。他倒是图省事儿了但是对于维护人员来说简直是噩梦。正所谓编码一时爽维护火葬场。 其次是架构这也是遗留系统的重灾区。一个软件架构的作用是要解决多个业务模块之间的协作问题。但如果架构混乱多个模块之间往复调用数据也是随意访问模块之间的边界就会变得模糊数据所有权也会变得含糊。试想一下如果一张表被 10 个模块访问谁能说得清这张表到底属于哪个模块呢
下图是一家银行的核心应用系统模块之间的交互图想没有一个人愿意工作在这样的系统上吧 综合来看代码和架构的质量差会导致遗留系统的维护成本相当高昂。这里的维护就包括新需求的添加、线上 Bug 的修改以及为了维护系统运行所需投入的软硬件和人力等。
IEEE 就曾报道过2010 年以来全世界在 IT 产品和服务上的支出达到了 35 万亿美元。其中四分之三用于运营和维护现有的 IT 系统至少有 2.5 万亿用于尝试替换旧系统其中差不多三分之一的资金都打了水漂感兴趣的话可以看这里。
企业在遗留系统上的投入巨大却没能得到相称的回报。很多资金只是用来维持系统的现状却不能让它们变得更好。 更严重的是代码和架构的落后还会导致系统在合规和安全方面的问题。随着我国法律法规的健全软件系统的合规性越来越重要而一个面对任何需求都难以实现的遗留系统要想进行修改以符合新的法律法规是难上加难的事情。
去年我国正式施行了《中华人民共和国数据安全法》即中国的 GDPR明确规定了软件系统的数据安全规范。如果不能依法进行系统的整改将面临法律的制裁。而在遗留系统开始构建的时候可能就没有考虑太多的安全性。随着新的攻击手段越来越丰富遗留系统的安全性越来越脆弱企业也很难对此投资去专门改善安全性。
然后接着看缺乏甚至没有测试所造成的问题。在一个遗留系统上添加新需求简直如履薄冰当好不容易找到要修改的位置敲了几行代码感觉可以了的时候系统的另一个功能可能会因为你的这几行代码而崩溃。而一个线上 Bug 想要找到元凶可能会难如登天一方面缺乏有效的日志难以定位很多遗留系统的日志是打在命令行里的
另一方面修复了一个 Bug 也可能会导致更多的 Bug。这时就体现出自动化测试的重要性了。
不知道系统里有没有或者有多少测试总之我在那个有着 30000 多个自动化测试的项目上修复一个 Bug 的过程是这样的
先在本地复现 Bug找到产生这个 Bug 的业务场景为这个业务场景添加一个自动化测试并运行发现这个测试是失败的修改代码让这个新增的测试通过运行所有的测试确保所有的测试通过。
经过这一系列操作我就可以有十分有信心地宣布这个 Bug 被修复了而且在目前测试覆盖的场景下没有引入新的 Bug。但对于没有测试的遗留系统在测试人员告知测试通过之前我简直是胆战心惊。那遗留系统落后的 DevOps 手段会造成哪些问题呢这会造成重大的安全隐患。
那个例子部署到生产环境的安装包是本地打出来的就是非常严重的安全问题。不知你是否记得几年前著名的 XCodeGhost 事件开发人员使用非官方渠道下载的注入了恶意代码的 XCode并用这样的 XCode 打包 App上传到了 App Store 上。结果下载了这种 App 的手机信息就被窃取了。
这里多说两句这次事件延伸到我们的日常工作中也是有值得深思之处的。 一是不要从非官方渠道下载开发工具但这个教训直到现在仍然没有引起足够的重视仍然有很多团队使用的付费开发工具不是从官方渠道下载的。 二是不要在开发机器上打包部署到非开发环境特别是生产环境上要通过 CI/CD 来编译、打包和部署当然 CI/CD 上的工具也必须是从官方渠道下载。这就是 DevOps 的作用之一。最后技术和工具也可能存在很大的安全漏洞比如前段时间爆雷的 log4j。新的系统虽然也存在这样的风险但是非常容易补救。反观遗留系统的工具升级那就举步维艰了原因也很简单投入产出比合不来。
另外落后的技术和工具也使得遗留系统难以与新系统集成。基于 Delphi、PowerBuilder、VB 或 Lotus Notes 那一代的桌面应用就是很好的例子。新的开发团队在面临遗留系统集成的时候往往都是唯恐避之不及。
这样的系统也使得自己所拥有的企业核心数据成为孤岛难以与其他系统互联。 三、什么是遗留系统
说了这么多我们似乎已经有了一个很具体的关于遗留系统的画像了参考如下 那是不是可以进一步抽象一下概念了呢很简单不妨直接看看维基百科是如何定义的吧 在计算机领域遗留系统是一种使用旧的方法和技术的、过时的却仍旧在使用的计算机系统。 而 Gartner 给出的定义是 基于过时技术但对日常运营至关重要的信息系统。 嗯有信息重合找找关键字旧的、过时的、重要的、仍在使用的……这里找找对应的例子辅助下理解。
不知道是否看过一些医疗类型的美剧还记得发生危急情况时医院是如何通知医生们的吗是使用寻呼机——一个在现实生活中已经寿终正寝了快 20 年的古老的通信设备。
难道美国的通信设施如此落后吗当然不是诞生了 iPhone 和 Android 的美国怎么可能通信落后呢真正落后的是医院的急救寻呼系统。
这些系统往往有着六七十年的历史很难被替换。它就完美符合上面的所有关键字旧、过时、重要、仍在使用。还有 Windows XP 系统尽管它很经典但微软在 2014 年就已宣布不再维护了。
不过直到现在仍然能在很多 ATM 机上看到它的踪影。到这已经完全明确了遗留系统的定义以及它所带来的问题所以觉得一个遗留系统还有保留的价值吗为什么没有替换甚至丢弃还要继续维护并为其打上重要的标签呢 四、遗留系统的现代化价值
原因有很多。首先可能是成本太高了企业不愿意投入资源去改进也可能是因为积重难返根本改不动。而遗留系统往往都是企业的核心业务系统支撑着整个企业的业务运营这样的系统就算问题再多也是不可替代的。
其次遗留系统蕴含了大量的数据资产。遗留系统中的数据虽然很难与其他系统进行集成但这部分数据的价值又是巨大的。企业的新系统常常不得不在这些数据的基础之上去构建其他系统要想获得遗留系统中的数据就必须对遗留系统进行修改所以很多团队为了避免修改代码就会去寻求数据库层面的复制和同步这也是一个选择。
另外遗留系统中还藏匿着丰富的业务知识。由于业务人员长期使用并且养成了习惯很多软件系统已经与业务融为一体很难区分哪些是真正的业务哪些是系统的设计。而由于系统历时太久已经失去了能够正确描述系统现状的文档所以到最后只有遗留系统的代码才能够准确表达系统的行为以及与之对应的业务知识。
系统改造有可为有可不为而对于遗留系统来说结合其现代化价值看上去更像是一种不得不为。所谓现代化其实就是从代码、架构、DevOps 和团队结构这四个方面来对遗留系统进行治理。既然不能对遗留系统听之任之就要下决心迎难而上掌握主动权否则当问题真正出现时就为时已晚了。
举个例子疫情期间美国大量人口失业但上世纪 80 年代建造的失业系统无法及时发放失业福利他们的国税局系统则更加老旧是 60 年代建造的总共需要 20 个星期的时间才能为符合条件的纳税人发放疫情补贴。
看到的是在全球疫情这种黑天鹅事件发生时一方面高响应力的公司能够快速推出像疫情地图、行程码这种全新的服务以造福社会服务大众而一方面陈旧的遗留系统却在拖着整个时代的后腿。
用巴菲特的话说就是当潮水退去之后你才知道谁在裸泳。如果说不得不为那怎么为之更好呢
在数字化时代每家企业都应该意识到科技是核心竞争力要依赖科技去重塑业务、创造新的商业模式创造数字化收益。也就是我们常说的 TechCore。
很多互联网公司的数字化基因是与生俱来的它们能够根据当前的形式和热点迅速地开启一个全新的商业模式并站稳脚跟。比如在疫情下买菜难的问题很多公司就迅速推出了买菜 App。
然而与此同时对于传统企业来说与上下游客户和供应商合作的数字化需求其实也是在不断增多的。
以汽车保险这个行业为例与车主、4S 店、汽车制造商、交管系统等等合作方之间存在着大量的互联需求这里面有很多商机。
一个有雄心的企业是不可能用一个落后的遗留系统去应对这些挑战的。 所以迎难而上是必须的让老旧、过时的遗留系统变得现代化也是必须的这样才能更好地为企业的战略和运营服务。 五、总结
从业界对遗留系统的定义中总结出了 4 个关键字
旧、过时、重要、仍在使用。
然而人们对于遗留系统的认识存在一个普遍的误区即时间长的系统就是遗留系统。事实并非如此。有些系统时间虽长但如果一直坚持现代化的开发方式在代码质量、架构合理性、测试策略、DevOps 等方面都保持先进性这样的系统就像陈年的老酒一样历久弥香。而有些系统虽然刚刚开发完成但如果在上述几个方面都做得不好也可以把它叫做遗留系统。遗留系统在维护成本、合规性、安全性、集成性等方面都会给企业造成巨大的负担但同时也蕴含着丰富的数据和业务资产。应该对遗留系统进行现代化让它重新焕发青春。
