遗留系统重建实战 pdf epub mobi txt 电子书 下载 2025

简体网页||繁体网页

☆☆☆☆☆

[英] 克里斯·伯查尔（Chris Birchall） 著，张喻，张耀丹，禚娴静 译

图书标签:

• 遗留系统
• 系统重建
• 软件重构
• 技术债务
• 架构演进
• Java
• 微服务
• 云原生
• 数字化转型
• 案例分析

出版社： 人民邮电出版社

ISBN：9787115465856

版次：1

商品编码：12185555

品牌：异步图书

包装：平装

开本：16开

出版时间：2017-10-01

用纸：胶版纸

页数：180

正文语种：中文

编辑推荐

作为开发人员，你可能会从另一个团队接手一个项目，而且该项目是基于现有代码库的，拥有很多设计模式、使用假设、基础设施和工具。幸运的是，有一些方法可以为遗留项目注入新的活力，这样你就可以维护、改进和扩展它们，而不必顾及它们的局限性。

这是一本以经验为主导的指南，能使遗留软件项目脱胎换骨。它涵盖了重构、质量度量学、工具链和工作流、持续集成、基础设施自动化以及组织文化等内容。在技术层面，读者将学习如何给代码模块化引进依赖注入，如何定量地衡量软件质量，以及如何实现基础设施的自动化。在策略层面，读者将能学到的实践有：软件是应该重写还是应该重构，团队的组织架构应该是什么样的，以及如何让管理层意识到软件质量的重要性。本书的核心议题包括解析和模块化棘手的代码结构、集成和自动化测试、替换过时的构建系统，以及用Vagrant和Ansible 之类的工具实现基础设施自动化。

本书主要内容
● 重构遗留代码库。
● 持续审查和持续集成。
● 遗留基础设施的自动化。
● 给老代码加新测试。
● 单体应用的模块化。

本书面向的读者对象是熟悉面向对象语言（如Java 或C#）的开发人员和团队领导。

内容简介

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

本书篇幅不长，但涵盖的内容很广，例证丰富，有大量的示例代码（主要使用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

《代码的生命线：应对复杂遗留系统的重塑之道》 引言 在软件开发的漫长旅途中，我们常常会遇到一个无可回避的挑战——遗留系统。它们是企业运营的基石，承载着多年的业务逻辑和用户信任，但也可能成为阻碍创新的“代码泥沼”。这些系统往往因技术陈旧、文档缺失、耦合紧密而难以理解、维护和扩展，如同古老的巨石，既是价值的象征，也是前进的障碍。本书《代码的生命线：应对复杂遗留系统的重塑之道》并非一本介绍具体操作步骤的书籍，而是旨在为开发者、技术领导者和架构师提供一套关于遗留系统重塑的哲学思考、策略蓝图和实践智慧。我们将深入探讨遗留系统为何会产生，它们所带来的挑战，以及如何在不冒不必要的风险的前提下，逐步、稳健地将其转型为适应未来发展需求的高效、可维护的现代化系统。 第一章：遗留系统的“前世今生”——理解其根源与价值 在着手任何“重建”之前，首先必须深刻理解遗留系统的本质。它们并非凭空出现，而是历史的产物。本书将追溯软件发展各个阶段的典型技术栈、开发模式和业务驱动因素，解析为何某些系统会逐渐演变成如今的状态。我们将探讨早期系统设计理念的局限性，例如过度的“硬编码”、缺乏模块化思维、以及对未来技术演进预见不足等。同时，我们也会强调遗留系统并非一无是处，它们往往凝聚了企业最核心的业务流程和宝贵的知识财富。理解这些系统的价值，是后续一切重塑工作的出发点和价值衡量基准。我们将通过案例分析，展示遗留系统在业务连续性、数据积累和用户习惯方面的重要性，帮助读者认识到“保护”和“传承”遗留系统中的精华，是重塑成功的关键。 第二章：揭开“遗留”的面纱——挑战与机遇并存的现实 “遗留”二字常常伴随着“风险”、“成本”和“低效”。本章将深入剖析遗留系统带来的典型挑战。我们将详细讨论代码的可读性差、测试覆盖率低、技术债务堆积、缺乏现代化开发工具支持、以及潜在的安全隐患等问题。然而，挑战的背后往往也隐藏着巨大的机遇。每一次对遗留系统的改造，都是一次技术升级、流程优化的契机。本书将引导读者从战略层面思考，如何将这些挑战转化为驱动创新的动力，例如通过引入自动化测试来提升代码质量，通过微服务化改造来提高系统的灵活性，通过云原生技术来增强系统的弹性与可扩展性。我们将强调，对遗留系统的恐惧源于对未知的担忧，而清晰的认识和周密的计划，是克服恐惧、抓住机遇的关键。 第三章：重塑的策略艺术——在保守与激进间的平衡之道 面对一个庞大而复杂的遗留系统，简单粗暴的“推倒重来”往往是不可取且高风险的。本书将重点阐述一系列“渐进式重塑”的策略。我们将详细探讨“绞杀者模式”（Strangler Fig Pattern）的应用，如何逐步将新功能和新服务接入现有系统，最终将遗留系统“蚕食”殆尽。我们还将介绍“数据迁移策略”、“API封装”、“服务拆分”等核心概念，以及在不同场景下选择最适合的策略组合。本书会特别强调“最小可行产品”（MVP）的思维在遗留系统改造中的重要性，以及如何通过迭代的方式，逐步验证改造效果，降低整体风险。此外，我们还将讨论如何评估不同重塑策略的成本效益，以及如何根据业务优先级来制定改造路线图。 第四章：技术工具箱的升级——为遗留系统注入新活力 尽管遗留系统可能使用着老旧的技术，但重塑过程离不开现代化的技术工具。本章将重点介绍一系列能够帮助我们理解、分析、重构和部署遗留系统的技术手段。我们将讨论静态代码分析工具的应用，如何揭示代码中的潜在问题和“坏味道”。自动化测试框架的重要性将贯穿始终，从单元测试到集成测试，再到端到端测试，我们将探讨如何逐步建立一套完善的自动化测试体系，为重构提供安全网。此外，本书还会介绍API网关、服务注册与发现、容器化技术（如Docker）、持续集成/持续部署（CI/CD）流水线等现代化架构实践，以及它们如何帮助我们更好地管理和演进遗留系统。我们将强调，选择合适的技术栈并非盲目追随潮流，而是要根据遗留系统的特点和重塑目标来做出明智的决策。 第五章：架构的演进之路——从整体到局部的现代化蜕变 架构是遗留系统重塑的灵魂。本书将深入探讨如何对遗留系统的架构进行演进。我们将从宏观层面出发，讨论如何识别系统中的“技术孤岛”和“单体巨兽”，并逐步将其解耦，引入微服务、事件驱动架构等现代化设计模式。我们将详细讲解“领域驱动设计”（DDD）在理解和拆分复杂业务域中的作用，以及如何通过“限界上下文”（Bounded Context）来划分服务边界。本书还将深入剖析API设计的重要性，如何通过统一的API层来屏蔽底层技术的差异，为前端和第三方集成提供稳定可靠的接口。此外，我们还会探讨数据架构的演进，如何从集中式数据库走向分布式的、更具弹性的数据存储方案。 第六章：人的因素与文化变革——拥抱变化，共创未来 技术改造的成功，最终取决于人的努力和团队的协作。本书将把目光聚焦于“人”这个关键因素。我们将探讨如何建立一支能够应对遗留系统挑战的跨职能团队，以及如何培养团队成员的“遗留系统思维”。本书会强调沟通、协作和知识共享在重塑过程中的重要性。我们将讨论如何管理利益相关者的期望，以及如何通过有效的沟通，争取资源和支持。此外，本书还将探讨文化变革的力量，如何鼓励团队拥抱新技术、新方法，并从中学习成长。我们将强调，成功的遗留系统重塑，不仅仅是技术的升级，更是组织文化的积极蜕变。 第七章：风险管理与质量保障——在不确定中稳健前行 遗留系统的重塑充满了不确定性，因此，有效的风险管理和质量保障是必不可少的。本书将深入探讨如何识别、评估和规避重塑过程中可能出现的各种风险，从技术风险到业务风险，再到项目管理风险。我们将详细介绍“回归测试”、“性能测试”、“安全测试”等关键的质量保障环节，以及如何利用自动化工具来提高测试效率和覆盖率。本书还将讨论“回滚策略”和“故障转移机制”的重要性，确保在出现问题时能够迅速恢复。我们将强调，质量不是在项目结束时才检查，而是贯穿于整个重塑过程的始终。 第八章：案例精粹与经验总结——他山之石，可以攻玉 理论固然重要，但成功的实践经验更是无价之宝。本章将通过精选的案例研究，展示不同行业、不同规模的组织在遗留系统重塑过程中所遇到的问题、采取的策略以及取得的成就。这些案例将涵盖从银行核心系统改造，到电商平台架构升级，再到传统制造业数字化转型等多个维度。我们将深入分析每个案例的成败之处，提炼出可供借鉴的经验和教训。本书将鼓励读者跳出自己的特定场景，从更广阔的视角审视遗留系统重塑的普遍规律。 结论：拥抱变革，再塑辉煌 《代码的生命线：应对复杂遗留系统的重塑之道》并非提供一蹴而就的解决方案，而是希望成为指引您穿越遗留系统“迷雾”的灯塔。我们相信，每一个遗留系统都蕴藏着巨大的潜能，只要我们以审慎的态度、创新的思维和坚定的执行力去面对，就能够为其注入新的生命力，使其重新焕发光彩，驱动企业走向更辉煌的未来。本书的目标是赋能您，让您能够更有信心地规划、执行和管理遗留系统的重塑项目，最终实现技术与业务的和谐统一，为组织的长期发展奠定坚实的基础。

评分☆☆☆☆☆

我是一名长期与遗留系统打交道的开发者，深知其带来的无奈与挑战。每次面对那些如同一团乱麻的代码，我都希望有一本能够指引方向的书。这本书的题目《遗留系统重建实战》立刻吸引了我。我关注的重点在于“实战”二字。我希望这本书能够提供具体的案例分析，详细阐述如何一步步地拆解、重构、甚至重写遗留系统。 特别想了解的是，书中对于“零停机”重构是否有深入的探讨。在实际工作中，很多遗留系统都承载着关键业务，停机时间意味着巨大的损失。因此，如何设计和实施能够平滑过渡的重构方案，是我最关心的问题。比如，是否会介绍一些“绞杀者”模式（Strangler Fig Pattern）的具体应用场景和实践经验？又或者，书中是否会提供一些关于如何安全地迁移数据，以及如何在并行运行新旧系统时处理数据一致性的详细指导？另外，我也期待书中能分享一些关于如何识别系统中的“关键路径”，以及如何优先处理那些影响最大、风险最高的模块的策略。

评分☆☆☆☆☆

我一直在寻找能够帮助我理解和应对复杂技术挑战的资源，尤其是那些关于如何处理“老旧”但又至关重要的软件系统的。这本书的出现，让我眼前一亮。我特别看重的是书中是否能够提供一些前瞻性的视角，不仅仅是解决当前的问题，更是为未来的系统演进打下基础。 我希望这本书能深入探讨在遗留系统重建过程中，如何引入新的技术和架构模式，同时又不至于“推倒重来”，导致巨大的风险。例如，书中是否会讲解如何逐步引入微服务架构，或者如何利用容器化技术来隔离和管理遗留系统的不同模块？更重要的是，我期待书中能提供一些关于如何在不牺牲性能和可维护性的前提下，提升遗留系统安全性的具体实践。关于如何评估不同重构方案的成本与收益，以及如何在长期的维护过程中，持续地保持系统的健康度，也是我非常关注的方面。

评分☆☆☆☆☆

在我看来，许多关于软件开发的图书，虽然理论扎实，但在实际操作层面往往显得过于抽象，难以直接套用到我们这些在“一线”奋战的开发者身上。《遗留系统重建实战》这个书名，精准地击中了我的痛点。我对于书中所述的“重建”过程，有着非常具体和现实的期盼。 我尤其感兴趣的是，书中是否会涉及如何构建一个能够有效支持遗留系统重建的团队文化和工作流程。一个成功的重建项目，不仅仅是技术层面的突破，更是组织层面协同努力的结果。例如，书中是否会讨论如何与业务方沟通，争取他们对重建项目的理解和支持？又或者，它会提供一些关于如何培训团队成员，让他们掌握必要的遗留系统分析和重构技能的建议？此外，我还好奇书中是否会提及一些在重建过程中可能遇到的非技术性挑战，比如如何处理遗留系统的“隐性知识”传承，以及如何在紧迫的时间表下平衡质量和速度。

评分☆☆☆☆☆

从事软件开发多年，我深切体会到遗留系统带来的“甜蜜的负担”。它们是企业核心业务的基石，却也常常成为技术创新的桎梏。《遗留系统重建实战》这个名字，就像沙漠中的甘泉，瞬间点燃了我探索的渴望。 我最期待的是书中能够提供一系列可复制、可借鉴的“实战”案例，而不仅仅是停留在理论层面。我希望能够看到详细的技术栈对比、架构演进图示、以及在面对具体技术难题时，作者是如何一步步分析、决策并最终实施解决方案的。例如，书中是否会展示如何利用“测试驱动开发”（TDD）等敏捷方法来重构遗留代码，或者如何通过自动化测试来确保重构过程的安全性？我也非常好奇书中是否会分享一些关于如何选择合适的工具链，以及如何构建持续集成/持续部署（CI/CD）流水线来支持遗留系统的现代化改造。最后，如何衡量一个遗留系统重建项目的成功与否，以及如何建立一个长期的维护和演进机制，也是我希望书中能有所解答的。

评分☆☆☆☆☆

在信息爆炸的时代，寻找一本真正能解决实际问题的技术书籍，如同在大海捞针。我一直对系统架构和重构领域充满兴趣，特别是那些能够提供切实可行的解决方案，而非空谈理论的书籍。最近，我偶然发现一本名为《遗留系统重建实战》的书，虽然我还没来得及深入阅读，但从它扎实的标题和市面上稀缺的同类主题来看，我对其抱有极大的期待。 我特别关注的是书中是否能深入剖析遗留系统存在的普遍痛点，例如技术债务的累积、代码的脆弱性、文档的缺失，以及团队在面对这些挑战时可能遇到的阻力。一个好的“实战”书籍，应该能够触及这些核心问题，并提出行之有效的诊断方法。我希望这本书不仅仅是列举一些重构技巧，而是能教会读者如何系统地评估一个遗留系统的健康状况，理解其演进的脉络，并在此基础上制定出合理的重建策略。例如，书中是否会提供一些量化的指标来衡量遗留系统的“老旧”程度，或者介绍一些工具来帮助我们自动化地识别代码中的坏味道？此外，对于那些庞大且复杂到令人望而生畏的系统，如何在不影响核心业务的情况下，分阶段、有计划地进行改造，也将是我非常期待的内容。

评分☆☆☆☆☆

编程风格：好代码的逻辑

评分☆☆☆☆☆

据说还不错的一本书，用来提高自己的编码水平

评分☆☆☆☆☆

还没有看，不过肯定是好书

评分☆☆☆☆☆

发票大小写不一致，还不承认，然后还要我自己寄发票到什么广州去差评送给京东

评分☆☆☆☆☆

非常好，趁做活动敢紧买，买，买。还没看

评分☆☆☆☆☆

这是好书，有时候就需要这种概念性的书，而且没有什么废话

评分☆☆☆☆☆

看起来不错

评分☆☆☆☆☆

传承经验的重要媒介,对人类文明的开展,贡献至钜

评分☆☆☆☆☆

非常好听