02 | 遗留系统现代化：遗留系统的四化建设
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
遗留系统现代化的正确方向是一个重要的技术话题。本文介绍了遗留系统现代化的正确方向，强调了代码现代化、架构现代化、DevOps现代化和团队结构现代化四个方向。在代码现代化方面，重点在于对遗留系统的代码进行安全的可测试化重构，以及添加足够的测试来提供质量保障。在架构现代化方面，提出了“改造老城区”和“建设新城区”两种模式，分别对遗留系统内部的模块进行治理和拆分，以及提供各种支持与集成。文章强调了遗留系统现代化的正确方向不是盲目引入新技术，而是根据实际情况进行合理的改造和现代化，以确保系统的稳定性和可维护性。 在DevOps现代化方面，强调了现代化的DevOps平台对项目的重要性，以及遗留系统的DevOps现代化是一种从0到1的建设。团队结构现代化则着重介绍了团队拓扑理论，强调了团队结构对交付效率和产品质量的重要性。 总结来说，本文通过介绍遗留系统的四个现代化方向，强调了将先进的、现代化的软件开发方法应用到遗留系统上，让遗留系统重获新生、保持活力。文章还提到了遗留系统现代化的三个原则，即以降低认知负载为前提、以假设驱动为指引、以增量演进为手段。这些原则对于遗留系统现代化的举措至关重要。
《遗留系统现代化实战》，新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
术子米德🤔☕️🤔☕️🤔 * 📖：现代化（Modernization），把遗留系统变成现代化的系统（Legacy System Modernization） * 🤔：现代化，到底是一个目标，还是一个过程？为何代码不能在第一天就现代化？我们今天写的代码能持久保持现代化嘛？如果一份代码，从开始到现在，都是一个开发在维护，需要现代化嘛？如果一份代码，至始至终都是流动的状态，有可能现代化嘛？到底是怎样的发心，能够持久呼喊系统现代化，为何我身边没有这样极度追求者？这些困惑和现状，在我心里似乎还是乱序的状态。我得想办法找出一个关键词，能够随时召唤出来，点亮我对于重构遗留系统的核心要义。就像代码评审，我给自己设定的关键词就是“易读性”，代码字面意思易读、代码业务含义易读、代码验证思路易读。可是，遗留系统重构，我还在寻找这样点亮我的关键词。 * 📖：遗留系统现代化四方向：代码现代化、架构现代化、DevOps现代化、团队结构现代化。 * 🤔：现代化代码和古董级代码的关键差异，在于代码本身是否具备可测性。而可测性的关键区别点，就在于改动后，能否在【独立可控条件下验证修改】是否符合预期。难以独立验证，只能整体测试，那是能力问题。如果具备独立可控验证，还选择整体测试，要么认知不到位，要么就是态度问题，不客气说就是职业底线偏低。这样的底线下沉，并非开始如此，每个小地方，稍微懒惰一点，积累起无可挽救的自己。说起来容易，认识起来也容易，如何能让自己真正做到，就像每次带上红领巾，都会撸正每个角，这是天赋异禀，还是刻意可习得的优质。这个困惑，在我心头从未消除。即使我知道要撸正红领巾，可是我就会出现不撸正的时候，至于如此嘛，何以如此呢？这是自己呆在遗留团队太久，还是仅凭自己，就是不可能爬不出遗留系统的坑，怎么能找到棒喝自己的时机？ * 遗留系统现代化三原则：降低认知为前提、假设驱动为指引、增量演进为手段。 * 🤔：降低认知，就像走路要穿鞋，否则必定走不远。假设驱动，就像爬山要地图，否则迟早迷路。增量演进，就像游泳要有换气频率，否则不是憋伤就是憋傻。作者回复: 总结得非常好，感谢。
2022-05-045
aoe遗留系统现代化的三个原则： 1. 以降低认知负载为前提 2. 以价值驱动为指引 3. 以增量演进为手段 关于团队结构现代化的一本书《Team Topologies》中文版《高效能团队模式》 我们的系统 微服务（SpringBoot）：20+ 通信：Dubbo + RocketMQ 运维 - 使用 Jenkins 打包部署 - 测试环境：K8S - 生产环境 --业务线一：阿里云 serverless --业务线二：阿里云 K8S --业务线三：AWS K8S作者回复: 感谢分享
2022-04-1533
escray
我觉得三原则很棒，降低认知负载、价值驱动、增量演进，其实很多系统开发也应该遵循这样的原则。 另外就是遗留代码四个现代化里面，团队结构现代化是不是应该放在最前面？如果指望研发团队去做代码和架构现代化，感觉有点无从下手，我猜测平台团队和赋能团队应该可以做一些示范性的工作。 对于那个 InMemoryEmployeeDao 我也有点疑问，是不是可以考虑行为测试，使用 Mock 工具。 手头的项目是 C++ 开发的桌面应用，似乎对于单元测试的引入不那么友好。作者回复: 四个现代化之间是并行进行的，并没有明显的先后顺序，不过确实交付团队去改进代码和架构的时候，需要平台和赋能团队的协作和帮助。 InMemoryEmployeeDao只是举了一个提取接缝的例子，实际上它也是一种类型的测试替身，只不过是我们手写的而已。
2022-04-132
Lee刚来这家公司，虽然有用阿里云，但是个人感觉基建还是有待提高，对于服务的划分在按照使用者，其次前端nodejs层承接过多业务含义，交互和体验上面前端关注度不太够，后端分层存在比较大的问题，因为存在中台，每次都参考中台的表设计之类，一问中台也是这样设计，对于圣经真的不是作为思想指导去灵活应用，而是必须把圣经定律搬进来，稍微有那么一点心累哈哈哈，如果我来重构，新起一个服务，在服务中按照不同领域进行分层，领域层之间步互相调用，如果需要聚合，单独一层来聚合或者处理，后面拆成微服务的话也很easy，之所以还是考虑新加一个服务还要审核，不一定能通过，这个也是组织结构的问题，也需考虑sre团队的成本编辑回复: 感谢分享你的经历
2022-07-24
拉欧认知负载改成认知成本比较好作者回复: Cognitive Load通常的翻译还是认知负载或认知负荷，主要说的是人在学习的时候需要付出的“努力”，而不是“成本”（cost）。
2022-05-21
克劳斯请教老师，应该怎么定义现代化架构，衡量的标准是什么？先抛开遗留系统来讲，如果是一个全新搭建的系统，怎么判断系统上线后是不是遗留系统？文中提到的更多的是遗留系统现代化的原则，以及已有遗留系统架构现代化的模式和方法。作者回复: 没必要盲目追求现代化的架构，去结合团队的认知负载来考虑，参见第12节课
2022-05-152
peter请教老师几个问题： Q1：devOps就等于CI+CD吗？ Q2：InMemoryEmployeeDao只是测试用的，并不是业务代码，对吗？ Q3：上一课(01讲)，提到“付费软件从非官方渠道下载”，既然花钱买了，肯定会从官网下载啊，怎么会不从官网下载呢？ Q4：上一课(01讲)，提到“java开发的C/S项目”。用java开发C/S项目，这个决策本身就有问题吧。C/S项目一般是桌面软件，桌面软件不是Java擅长的，而应该用微软那一套吧。作者回复: 感谢关注，以下是回答，咱们一起讨论哈： A1：DevOps的外延很广，当然不止是CI/CD，但是对于遗留系统，特别是没有DevOps的遗留系统来说，搭建CI/CD就是最主要的工作了。 A2：是的，这里只是举了一个构造接缝的例子，后面的课程还会介绍更多给遗留代码写测试的方式。 A3：XCodeGhost事件不就是这么发生的么：） A4：在早年Web还不流行的时候，用Java开发桌面软件的解决方案也有很多。
2022-04-132
Anita我所在的遗留系统已经由单体拆成了微服务。为了和老系统一致，需要很多人工验证的工作，投入产出不高。作者回复: 很赞，单体能拆出微服务，就成功了一大半。人工验证确实很繁琐，可以看看有没有可能些一些端到端的测试，来节省这部分人力。
2022-04-13- Anita老师，需求现代化能否再加上呢？了解了需求现代化开发人员可以给外部门提建议
作者回复: 需求方面的治理需要业务部门和开发部门的同心协力，要撬动需求部门不是那么容易。如果你们组织的需求部门愿意配合，可以先尝试一下用用户故事来取代传统的需求文档。
2022-04-13 
MaLu1. 以降低认知负载为前提 -- 其实就是清晰化的 2. 以假设驱动为指引 -- 就是演绎逻辑、就是提前做试验的方法 3. 以增量演进为手段 -- 一是兼顾前后新旧 一是避免冒进冒失2023-02-07归属地：广东1
