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