刚写的代码,就变成了遗留系统?
共 1393字,需浏览 3分钟
· 2022-04-17
今天想跟大家聊聊遗留系统,首先,看一下这张图
这是一家银行的核心应用系统模块之间的交互图,我想没有一个人愿意工作在这样的系统上吧?
架构混乱,模块之间职责不明,一个需求就要需要修改四五个服务,这就是遗留系统,留给我们的问题。
遗留系统与架构
一个软件架构的作用,是要解决多个业务模块之间的协作问题。但如果架构混乱,多个模块之间往复调用,数据也是随意访问,模块之间的边界就会变得模糊,数据所有权也会变得含糊。
其实遗留系统的架构重构,我们可以分成“改造老城区”和“建设新城区”两类模式。
改造老城区模式是指对遗留系统内部的模块进行治理、让模块内部结构合理、模块之间职责清晰的一系列模式。
建设新城区模式是指将遗留系统内部的某个模块拆分到外面,或将新需求实现在遗留系统外部的一系列模式。
遗留系统如何全面「改造或重构」
曾经的我也遇到过遗留系统,相当痛苦,每天为毫无头绪的代码和混乱不堪的架构发愁,新需求来了根本不知道从何改起。改造和替换又是高风险操作,应该遵循哪些改造原则?重构还是重写,如何选择?
后来我在搜索解决办法时,看到了一段 Thoughtworks资深咨询师「姚琪琳」分享重构遗留系统方法,给我启发挺大,大约 4 分钟,这里分享给大家。
简单来说,首先,你要先梳理遗留系统的根本问题,找到切入口
其次,全面地了解改造过程,知其然,也知其所以然,就像这张图。
将遗留系统模块进行 6 步拆分,即::①假设驱动 → ②明确度量 → ③确定架构目标 → ④制定演进进度 → ⑤按迭代增量演进 → ⑥验证
「姚琪琳」Thoughtworks 资深咨询师,技术书籍译者。拥有超过十年的软件开发、设计和架构经验。近年来在企业遗留系统现代化、领域驱动设计、敏捷软件开发、整洁代码和重构等方面持续精进,并通过理论指导、实战演练等方式为企业研发团队赋能。参与翻译或审校多本技术书籍,包括《领域特定语言》《.NET 性能优化》等10余本。
最近他专门写了个专栏《遗留系统现代化实战》,我第一时间就入手了,不得不说,真香!
深入剖析了遗留系统的特点和问题,详解遗留系统现代化的原则、模式和最佳实践,并从代码、架构、DevOps 和团队现代化 4 大方向,解决遗留系统治理的疑难杂症。
现在刚刚上线,用我的优惠口令「xitong888」,到手仅需¥68。
或者你可以直接购买极客时间的超级会员,首月 6 元,就能免费看这个课
再简单介绍下内容,他将遗留系统分成了 4 个篇章:
基础篇:为什么要对遗留系统“现代化”
原则篇:以降低认知负载为前提、以假设驱动为指引、以增量演进为手段
模式篇:20+ 经典模式,以及来自一线实战总结的实用模式,帮你分而治之。具体的不说了,自己看图,非常清晰。
实战篇:将带着你一起对一个典型的遗留系统进行现代化
有多干货,看看下面的专栏目录
也许,你当前所在的项目上并没有遗留系统,所有的系统都生机勃勃、一片祥和。不过表面的祥和之下,可能暗藏波涛。
也许,你正在痴迷于新技术,但,新≠好,只有掌握了解决问题的方法,才能不惧任何问题。而不是把新技术当个锤子,看什么问题都是钉子。
扫码试读👆🏻
遗留系统怎么办?将改造进行到底!
↓↓↓阅读原文,立即试读