遗留系统重建实战

出版者:人民邮电出版社

作者:[英] 克里斯·伯查尔

出品人:异步图书

页数:180

译者:张喻

出版时间:2017-10

价格:55.00元

装帧:平装

isbn号码:9787115465856

具体描述

正如本书作者所言，大多数开发人员的主要时间都是花费在与现有的软件打交道上，而不是编写全新的应用程序。相信开发人员或多或少都遇到过与遗留系统相关的问题或者困惑，本书致力于帮开发人员回答这些问题，更重要的是，帮开发人员避免把自己当前开发的系统变成别人将来要面临的遗留问题。

本书篇幅不长，但涵盖的内容很广，例证丰富，有大量的示例代码（主要使用Java或C#编写），深入浅出地介绍了工作在遗留系统中会遇到的各种问题及应对方法。书中不仅包含技术性的内容—如何选择构建项目的工具，如何自动化构建基础设施，如何决定并进行重构或重写等，也包含非技术性的内容—应该建设什么样的团队文化，如何引入代码评审等活动，如何进行团队知识的传播、改进沟通方式等。

作者简介

Chris Birchall是伦敦《卫报》的高级开发工程师，致力于为网站提供支持的后台服务。此前，他做过很多不同的项目，包括日本最大的医疗门户网站、高性能日志管理软件、自然语言分析工具和许多移动网站。他拥有剑桥大学计算机科学专业的学士学位。

张喻，ThoughtWorks咨询师，热爱技术，热衷编程。目前主要从事后端API的开发、部署、维护等相关工作，在整洁代码、敏捷实践和软件开发高效团队方面有丰富的理论和实践经验。

张耀丹，ThoughtWorks咨询师，曾长期参与大型遗留系统的开发与改进，在Java服务器端技术、大型系统架构演进、微服务转型、DevOps和云计算方面有丰富的经验。

禚娴静，ThoughtWorks咨询师，乐于知识分享与传播。拥有多年企业和互联网应用的开发实战经验，专注于敏捷实践、软件架构和持续交付领域，在.NET技术栈和微服务架构演化等方面有丰富的积累。

目录信息

第一部分　开始
第1章　了解遗留项目中的挑战 3
1.1 遗留项目的定义 3
1.1.1 遗留项目的特征 4
1.1.2 规则的例外 5
1.2 遗留代码 6
1.2.1 没有测试和无法测试的代码 6
1.2.2 不灵活的代码 8
1.2.3 被技术债务拖累的代码 8
1.3 遗留基础设施 9
1.3.1 开发环境 10
1.3.2 过时的依赖 10
1.3.3 异构环境 11
1.4 遗留文化 12
1.4.1 害怕变化 12
1.4.2 知识仓库 13
1.5 小结 14
第2章 找到起点 15
2.1 克服恐惧和沮丧 15
2.1.1 恐惧 16
2.1.2 沮丧 18
2.2 收集软件的有用数据 19
2.2.1 bug和编码标准违例 20
2.2.2 性能 20
2.2.3 错误计数 23
2.2.4 对常见的任务计时 23
2.2.5 常用文件 24
2.2.6 度量可度量的一切 25
2.3 用FindBugs、PMD和Checkstyle审查代码库 25
2.3.1 在IDE中运行FindBugs 26
2.3.2 处理误报 29
2.3.3 PMD和Checkstyle 32
2.4 用Jenkins进行持续审查 34
2.4.1 持续集成和持续审查 34
2.4.2 安装和设置Jenkins 35
2.4.3 用Jenkins构建和审查代码 36
2.4.4 还能用Jenkins做些什么 37
2.4.5 SonarQube 39
2.5 小结 39
第二部分　通过重构改善代码库
第3章 准备重构 43
3.1 达成团队共识 44
3.1.1 传统主义者 44
3.1.2 反传统主义者 46
3.1.3 一切都在于沟通 47
3.2 获得组织的批准 48
3.2.1 使它变得正式 48
3.2.2 备用计划：神秘的20%计划 49
3.3 选择重构目标 50
3.4 决策时间：重构还是重写 51
3.4.1 不应该重写的情况 52
3.4.2 从头重写的好处 55
3.4.3 重写的必要条件 56
3.4.4 第三种方式：增量重写 57
3.5 小结 58
第4章 重构 59
4.1 有纪律的重构 59
4.1.1 避免麦克白的悲剧 59
4.1.2 把重构和其他的工作分开 60
4.1.3 依靠IDE 61
4.1.4 依靠版本控制系统 64
4.1.5 Mikado方法 65
4.2 常见的遗留代码的特征和重构 66
4.2.1 陈旧代码 66
4.2.2 有毒的测试 68
4.2.3 过多的null 70
4.2.4 不必要的可变状态 73
4.2.5 错综复杂的业务逻辑 74
4.2.6 视图层中的复杂性 79
4.3 测试遗留代码 83
4.3.1 测试不可测试的代码 83
4.3.2 没有单元测试的回归测试 86
4.3.3 让用户为你工作 88
4.4 小结 89
第5章 重搭架构 90
5.1 什么是重搭架构 90
5.2 将单体应用程序分解为模块 92
5.2.1 案例研究—日志管理应用程序 92
5.2.2 定义模块和接口 94
5.2.3 构建脚本和依赖管理 95
5.2.4 分拆模块 96
5.2.5 引入Guice 97
5.2.6 Gradle来了 98
5.2.7 结论 98
5.3 将Web应用程序分发到服务 99
5.3.1 再看一下Orinoco.com 99
5.3.2 选择一个架构 100
5.3.3 继续采用单体架构 101
5.3.4 前后端分离 103
5.3.5 面向服务架构 106
5.3.6 微服务 108
5.3.7 Orinoco.com应该做什么 109
5.4 小结 109
第6章 大规模重写 111
6.1 决定项目范围 112
6.1.1 项目目标是什么 112
6.1.2 记录项目范围 113
6.2 从过去学习 114
6.3 如何处理数据库 115
6.3.1 共享现有数据库 116
6.3.2 创建一个新数据库 119
6.3.3 应用程序间通信 124
6.4 小结 125
第三部分　重构之外——改善项目工作流程与基础设施
第7章 开发环境的自动化 129
7.1 工作的第一天 129
7.1.1 搭建用户活动仪表盘开发环境 130
7.1.2 出了什么问题 132
7.2 一个好的README文件的价值 134
7.3 用Vagrant和Ansible对开发环境进行自动化 135
7.3.1 Vagrant介绍 135
7.3.2 为用户活动仪表盘项目搭建Vagrant 136
7.3.3 用Ansible进行自动配置 137
7.3.4 添加更多的角色 139
7.3.5 移除对外部数据库的依赖 141
7.3.6 工作的第一天—再来一次 142
7.4 小结 143
第8章 将自动化扩展到测试环境、预生产环境以及生产环境 144
8.1 自动化基础设施的好处 145
8.1.1 保证环境一致性 145
8.1.2 易于更新软件 145
8.1.3 易于搭建新环境 145
8.1.4 支持追踪配置更改 146
8.2 将自动化扩展到其他环境 146
8.2.1 重构Ansible脚本以处理多种环境 146
8.2.2 为Ansible角色和playbook搭建库 150
8.2.3 让Jenkins负责 152
8.2.4 常见问题 154
8.3 移到云上 155
8.3.1 不可变基础设施 156
8.3.2 DevOps 156
8.4 小结 157
第9章 对遗留软件的开发、构建以及部署过程进行现代化 158
9.1 开发、构建以及部署遗留软件的困难 158
9.1.1 缺乏自动化 158
9.1.2 过时的工具 160
9.2 更新工具链 160
9.3 用Jenkins实现持续集成与自动化 163
9.4 自动发布和部署 165
9.5 小结 172
第10章 停止编写遗留代码 173
10.1 源代码并不是项目的全部 173
10.2 信息不能是自由的 174
10.2.1 文档 174
10.2.2 促进沟通 175
10.3 工作是做不完的 176
10.3.1 定期进行代码评审 176
10.3.2 修复一扇窗户 176
10.4 自动化一切 177
10.5 小型为佳 178
10.6 小结 180
· · · · · · (收起)

读后感

废墟的召唤 代代层累并不是历史。废墟是毁灭，是葬送，是诀别，是选择。时间的力量，理应在大地上留下痕迹，岁月的巨轮，理应在车道间辗碎凹凸。没有废墟就无所谓昨天，没有昨天就无所谓今天和明天。废墟是课本，让我们把一门地理读成历史；废墟是过程，人生就是从旧的废墟出发...

废墟的召唤 代代层累并不是历史。废墟是毁灭，是葬送，是诀别，是选择。时间的力量，理应在大地上留下痕迹，岁月的巨轮，理应在车道间辗碎凹凸。没有废墟就无所谓昨天，没有昨天就无所谓今天和明天。废墟是课本，让我们把一门地理读成历史；废墟是过程，人生就是从旧的废墟出发...

废墟的召唤 代代层累并不是历史。废墟是毁灭，是葬送，是诀别，是选择。时间的力量，理应在大地上留下痕迹，岁月的巨轮，理应在车道间辗碎凹凸。没有废墟就无所谓昨天，没有昨天就无所谓今天和明天。废墟是课本，让我们把一门地理读成历史；废墟是过程，人生就是从旧的废墟出发...

废墟的召唤 代代层累并不是历史。废墟是毁灭，是葬送，是诀别，是选择。时间的力量，理应在大地上留下痕迹，岁月的巨轮，理应在车道间辗碎凹凸。没有废墟就无所谓昨天，没有昨天就无所谓今天和明天。废墟是课本，让我们把一门地理读成历史；废墟是过程，人生就是从旧的废墟出发...

废墟的召唤 代代层累并不是历史。废墟是毁灭，是葬送，是诀别，是选择。时间的力量，理应在大地上留下痕迹，岁月的巨轮，理应在车道间辗碎凹凸。没有废墟就无所谓昨天，没有昨天就无所谓今天和明天。废墟是课本，让我们把一门地理读成历史；废墟是过程，人生就是从旧的废墟出发...

用户评价

我对这本书的兴趣点主要集中在**遗留系统中的数据迁移和兼容性挑战**上。我们现在用的数据库版本老旧，数据结构也随着业务发展变得非常臃肿和冗余。如果要升级数据库技术栈，或者进行数据清洗，那简直是一场噩梦。很多重构项目失败，不是因为代码写不好，而是因为数据层面的兼容性没处理好，导致灰度发布时数据不一致，业务流程中断。我希望能看到书中是否有详细阐述**如何在不停止服务的前提下，实现数据结构的演进**。比如，如何利用双写（Dual Write）策略，如何设计可靠的回滚机制，以及最头疼的——**如何处理历史数据的质量问题**。如果数据本身就是错的，那么新的系统建立在错误的数据之上，那不是白费力气吗？我希望这本书能提供一些经过实战检验的“数据漂洗”流程图或工具集推荐。纯粹的代码重构是美丽的，但数据层面的“手术”才是真正见真章的地方，我非常期待看到这方面的深入探讨。

这本书的标题让我联想到一个非常现实的问题：**团队文化和组织结构对遗留系统改造的影响**。很多时候，技术瓶颈的背后是组织瓶颈。如果开发团队对老系统持有“厌恶”情绪，或者维护和创新部门之间存在壁垒，再好的技术方案也难以落地。因此，我非常好奇作者在书中是如何描述**“说服”业务方投入资源进行重构的**。重构往往看不到短期效益，而业务部门更关心眼前的KPI。书中是否提供了一些**量化评估重构价值**的方法？比如，用“修复一个Bug所需时间”的下降率，或者“部署失败率”的降低来展示重构的 ROI (投资回报率)。此外，一个成功的遗留系统改造，往往需要建立一套新的、更加敏捷的开发和部署流程。我期望看到作者分享他们是如何在重构过程中，逐步引入 DevOps 理念，实现**持续集成/持续部署（CI/CD）**的经验，尤其是在一个“半新半旧”的混合环境中，这套流程该如何搭建才能既不影响旧系统的稳定运行，又能加速新模块的迭代速度。

这本厚厚的书拿在手里，就感觉沉甸甸的，封面设计朴实，没有太多花哨的东西，一看就是那种老老实实讲干货的类型。我当初买它，主要是因为我们团队现在正面临一个头疼的问题：手里有个跑了十多年的老系统，业务逻辑错综复杂，代码像 spaghetti 一样缠绕在一起，文档更是凤毛麟角。每次想加个新功能或者修复个Bug，都得小心翼翼地像拆手雷一样，生怕碰坏了哪个不该碰的地方。市面上关于“重构”的书很多，但大多都停留在理论层面，讲一些高大上的设计原则，听起来很美，但在面对真实、混乱的生产环境时，总觉得隔了一层纱。我特别关注这本书里有没有关于**如何快速摸清老系统现状**的实战技巧，比如有没有介绍一些高效的静态分析工具的使用心得，或者更重要的是，有没有描述团队在**如何进行“低风险”的业务边界拆分**方面的经验。毕竟，一口吃不成胖子，如何把一个巨石系统，逐步蚕食成小块可控的微服务或者模块，这才是最关键的实战环节。我期待看到作者是如何处理那些历史遗留的“技术债”的，是硬着头皮推倒重来，还是采取更温和的“绞杀者模式”（Strangler Fig Pattern）？这些细节，才是真正决定项目生死存亡的关键。

坦白说，市面上很多“实战”书籍的“实战”部分，其实只是一个精心搭建的Demo项目。我更看重的是**处理“人”的因素和项目管理上的智慧**。遗留系统重建是一个旷日持久的战役，很容易在过程中丧失目标和动力。这本书里是否有关于**如何设置里程碑、如何保持团队士气**的章节？比如，作者有没有分享过**“小胜利”的庆祝机制**？即，如何快速实现一些小的、可见的改进点，来向管理层和团队证明重构的方向是正确的。另外，关于**“技术选型”的决策过程**也极其重要。面对海量技术栈，选择哪种语言、哪个框架来承载新业务，是决定未来十年系统生命力的关键。我希望能看到作者详细阐述他们当年是如何权衡**“熟悉的旧技术栈”与“前沿的新技术栈”**之间的利弊，特别是如何处理那些必须保留但又无法轻易替换的、高度定制化的第三方集成模块。决策的逻辑和背后的权衡艺术，往往比最终的技术选型本身更有价值。

当我翻阅这本书的目录时，一个关键点立刻抓住了我的眼球：**如何在新旧系统并行期间，保证用户体验的一致性和稳定性**。在“绞杀者模式”中，流量的切割和分发是技术上的核心难点。用户请求可能需要同时命中新旧两个服务，甚至依赖共享的数据源。我非常想知道书中是如何描述**API 网关或服务代理层**的构建和治理的。如何设计一套高效且低延迟的**流量切换和灰度发布策略**？特别是针对那些对延迟极其敏感的交易型业务。是采用百分比随机分流，还是基于用户标签进行定向灰度？更进一步，书中是否探讨了**系统可观测性（Observability）**在改造期的重要性？在双系统并存的复杂环境下，传统的监控手段可能无法提供全局视图。我期待看到关于**分布式日志追踪、跨系统调用链分析**的实战经验分享，确保在任何阶段，一旦出现问题，团队能迅速定位到是新系统、旧系统还是连接层面的错误，从而保证整个改造过程的透明度和可控性。

本书介绍重构的篇幅较少，主要介绍各种工具的使用，如构建工具、测试工具、持续集成工具、版本控制工具、自动化工具等。

坦率的讲，对于遗留系统的改造功夫在代码之外

本书介绍重构的篇幅较少，主要介绍各种工具的使用，如构建工具、测试工具、持续集成工具、版本控制工具、自动化工具等。

适合1-3年的工程师审视自己的项目,找出问题所在,并提出了切实可行的解决方案

坦率的讲，对于遗留系统的改造功夫在代码之外