第10章软件架构的演化和维护 — 系统架构设计师

第10章软件架构的演化和维护 --- 系统架构设计师学习笔记

📖 本章是架构设计师考试的重要章节 ，近年考频逐渐上升。如果说前面章节讲的是"怎么设计一个好架构"，那本章讲的就是"怎么让好架构持续好下去 "。架构不是设计完就一劳永逸的，它会随着需求变化、技术更新而退化，需要我们持续地演化和维护。学完本章，你需要能识别架构退化、选择维护策略、制定演化方案、管理软件重构。

一、章节概览

1.1 本章地位与核心目标

如果把软件架构比作一栋大楼，前面章节讲了"怎么设计蓝图"和"怎么盖楼"，本章则讲"大楼盖好后，怎么翻新改造 、怎么日常维护 、怎么防止大楼变成危楼"。本章是软件全生命周期管理的关键一环，体现了架构师"不仅要会建，更要会养"的能力。

本章围绕四个核心问题展开：

架构为什么会变差？ → 架构退化（腐化）的原因与表现
怎么维护现有架构？ → 软件维护的类型与策略
怎么让架构持续进化？ → 架构演化的方法与过程
老系统怎么办？ → 遗留系统的迁移与再工程

1.2 知识思维导图

复制代码

第10章 软件架构的演化和维护
├── 10.1 软件架构的演化
│   ├── 架构退化的概念与原因
│   ├── 架构退化的表现（技术债务）
│   └── 架构演化的驱动力
├── 10.2 软件维护
│   ├── 软件维护的定义与特点
│   ├── 四种维护类型（纠错/适应/完善/预防）
│   ├── 维护成本与影响因素
│   └── 可维护性分析
├── 10.3 软件架构维护
│   ├── 架构维护的概念
│   ├── 架构一致性检查
│   ├── 架构恢复/重建
│   └── 架构文档维护
├── 10.4 软件演化
│   ├── 软件演化的概念
│   ├── Lehman软件演化定律
│   ├── 演化过程模型
│   └── 演化策略与方法
├── 10.5 遗留系统处理
│   ├── 遗留系统的概念与特征
│   ├── 遗留系统分析（评估）
│   ├── 四种处理策略（淘汰/集成/改造/替换）
│   └── 系统迁移方法
├── 10.6 软件重构
│   ├── 重构的定义
│   ├── 重构的原则
│   ├── 常见重构手法
│   └── 重构与重设计的区别
└── 10.7 技术债务
    ├── 技术债务的概念
    ├── 技术债务的分类
    ├── 技术债务的度量
    └── 技术债务的管理策略

二、核心知识点精讲

10.1 软件架构的演化（★★ 基础概念）

10.1.1 架构退化（腐化）

概念定义： 软件架构在运行和维护过程中，由于各种因素导致架构逐渐偏离 原始设计，质量属性逐渐下降的现象。

通俗解释： 就像一栋大楼------原本设计得很好，但住户私自拆墙、乱接管道、到处搭违建，时间久了大楼的结构就被破坏了。架构退化就是"软件大楼"慢慢变成"违章建筑"的过程。

架构退化的主要原因：

原因	说明	举例
需求变化	新需求不断加入，架构被迫打补丁	原本单体架构，硬塞进微服务功能
时间压力	赶工期走捷径，牺牲架构质量	为了上线直接复制粘贴代码
人员变动	新人不理解架构设计意图	新来的开发不知道分层规范，直接跨层调用
技术更新	旧技术过时，新技术强行塞入	老系统硬接AI模块，架构不匹配
缺乏治理	没有架构评审和约束机制	没有代码审查，随意修改核心模块

架构退化的两种类型：

类型	英文	含义	类比
架构侵蚀	Architecture Erosion	实际实现偏离了设计文档	图纸说建3层，实际盖了5层
架构腐化	Architecture Decay	系统内部质量逐渐下降	房子住久了越来越乱

⚠️ 易混淆点：

侵蚀：设计和实现不一致（文档说一套，代码做一套）

腐化：系统质量逐渐下降（能跑但越来越难维护）

两者经常同时发生，互为因果

10.1.2 架构演化的驱动力

概念定义： 推动架构从一种形态转变为另一种形态的内在和外在因素。

通俗解释： 就像城市改造------人口增长（需求变化）、道路拥堵（性能瓶颈）、老城区改造（技术更新）都在推动城市不断演化。

演化的驱动力：

驱动力	类型	说明
需求变化	外部	新功能、新业务、新法规
技术进步	外部	新技术出现、旧技术淘汰
质量下降	内部	性能下降、故障增多
成本压力	内部	维护成本过高
组织变化	外部	团队规模、组织结构变化

10.2 软件维护（★★★ 高频考点）

10.2.1 软件维护概述

概念定义： 软件交付使用后，为纠正错误 、适应环境变化 、满足新需求 和预防未来问题而进行的修改活动。

通俗解释： 就像汽车保养------修bug（修发动机故障）、适配新系统（换轮胎适配新路况）、加新功能（装倒车雷达）、预防保养（定期换机油）。

⚠️ 关键数据（常考）：

软件维护成本占软件总生命周期成本 的 60%~80%

维护阶段是软件生命周期中持续时间最长 、花费最大的阶段

10.2.2 四种维护类型（★★★ 必背）

维护类型	英文	定义	目的	占比	举例
纠错性维护	Corrective	修复已发现的缺陷	改正bug	~20%	修复支付失败的bug
适应性维护	Adaptive	适应外部环境变化	适配新环境	~25%	适配新的操作系统版本
完善性维护	Perfective	增加新功能/提升性能	满足新需求	~50%	新增微信登录功能
预防性维护	Preventive	预防未来可能出现的问题	提高可维护性	~5%	重构老旧代码、更新文档

💡 记忆口诀： "纠适完预"

纠错 = 修bug（亡羊补牢）

适应 = 换环境（随遇而安）

完善 = 加功能（锦上添花）

预防 = 打补丁（未雨绸缪）
💡 通俗理解：

纠错性 = 生病了去看医生

适应性 = 天冷了换厚衣服

完善性 = 身体好了去健身更强

预防性 = 没病先体检防将来
⚠️ 高频考点：

完善性维护占比最大（约50%），因为需求永远在变

预防性维护占比最小 （约5%），但它是最应该做的（防患于未然）

选择题常考"新增功能属于哪种维护" → 完善性维护

10.2.3 可维护性分析

概念定义： 软件能够被理解、改正、适应和改进的难易程度。

通俗解释： 就像一本书的可维护性------排版清晰、目录完整、注释详细的好书，修改起来很容易；密密麻麻没有段位的书，改一页可能毁掉整章。

可维护性的六个维度：

维度	含义	衡量标准
可理解性	能看懂代码的意图	代码可读性、文档完整性
可测试性	能方便地验证修改是否正确	测试覆盖率、测试难度
可修改性	能方便地进行修改	耦合度、内聚度
可复用性	修改后的代码能被其他地方使用	组件通用性
可分析性	能快速定位问题所在	日志完善度、监控覆盖度
可变更性	修改不会引入新问题	回归测试通过率

提高可维护性的架构策略：

策略	说明	举例
模块化	将系统拆分为独立模块	微服务架构
高内聚	模块内部功能紧密相关	一个服务只做一件事
低耦合	模块之间依赖尽量少	通过接口/消息通信
文档化	保持架构文档与代码同步	架构决策记录（ADR）
标准化	统一编码规范和接口标准	API规范、代码规范

10.3 软件架构维护（★★ 常考）

10.3.1 架构维护的概念

概念定义： 在软件运行和维护过程中，保持架构设计与实际实现一致的活动。

通俗解释： 就像物业管理------定期检查大楼结构是否被私自改动、管道是否老化、消防通道是否畅通，确保大楼始终按设计运行。

架构维护的核心活动：

活动	说明	目的
架构一致性检查	对比设计文档和实际代码	发现架构侵蚀
架构恢复	从代码中还原架构设计	文档丢失时重建架构视图
架构评估	定期评估架构质量	发现退化趋势
架构文档更新	保持文档与实现同步	防止文档过时

10.3.2 架构恢复/重建

概念定义： 当架构文档缺失或过时时，通过分析源代码来还原架构设计的过程。

通俗解释： 就像考古------原始蓝图丢了，只能通过分析现有建筑的墙壁、管道、电路来推断原来的设计意图。

架构恢复的方法：

方法	说明	工具
代码分析	分析代码结构、依赖关系	SonarQube、Structure101
模式识别	从代码中识别架构模式	人工审查
调用图分析	分析模块间的调用关系	IDE工具、依赖分析工具
数据流分析	分析数据在系统中的流转路径	数据流分析工具

⚠️ 考点： 架构恢复是逆向工程的一种，它不改变系统行为，只是提取设计信息。

10.4 软件演化（★★ 重点）

10.4.1 软件演化的概念

概念定义： 软件系统在其生命周期中，为了适应内外部变化而持续发展和变化的过程。

通俗解释： 就像人的成长------从婴儿到成人，身体、能力、需求都在不断变化。软件也一样，从V1.0到V2.0再到V3.0，功能越来越多，架构也在不断演化。

⚠️ 关键区分：

维护：侧重于保持系统正常运行（被动）

演化：侧重于主动改进和适应变化（主动）

两者有重叠，但视角不同

10.4.2 Lehman软件演化定律（★★ 常考）

概念定义： Lehman在长期研究后提出的8条软件演化定律，描述了软件系统演化的规律。

八大定律：

编号	定律名称	含义	通俗理解
L1	持续变化律	系统必须持续变化，否则逐渐变得不满足需求	不进则退
L2	复杂度递增律	系统演化过程中复杂度不断增加	越改越乱
L3	自相似律	系统演化过程中呈现自相似结构	大结构套小结构
L4	组织稳定性律	系统演化速率在生命周期内保持相对稳定	变化速度有规律
L5	熟悉律	对系统的深入理解随演化而增长	越用越了解
L6	持续反馈律	演化过程需要持续的反馈机制	边改边反馈
L7	质量递减律	如果不主动调整，系统质量会逐渐下降	不保养就退化
L8	反馈驱动律	演化过程需要多方反馈来指导	听用户的声音

💡 记忆口诀： "复复自组，熟持反质"

复杂递增、反馈驱动

自相似、组织稳定

熟悉递增、持续变化

反馈驱动、质量递减
⚠️ 高频考点：

L2（复杂度递增） 最常考------系统越改越复杂是必然趋势

L7（质量递减） 常考------不主动维护质量必然下降

L1（持续变化） 是基础------不变化就会被淘汰

10.4.3 演化过程模型

概念定义： 描述软件如何从一种架构形态逐步过渡到另一种架构形态的过程框架。

演化策略对比：

策略	说明	优点	缺点	适用场景
渐进式演化	小步迭代，逐步改造	风险低、可回退	耗时长	大型系统改造
革命式演化	推倒重来，全面重构	一步到位	风险极高	系统完全不可维护
分支式演化	新旧系统并行，逐步切换	业务不中断	维护两套系统	核心业务系统

10.5 遗留系统处理（★★★ 高频考点）

10.5.1 遗留系统的概念

概念定义： 那些仍在运行 但技术陈旧 、文档缺失 、维护困难的旧系统。

通俗解释： 就像一台用了20年的老冰箱------还能制冷（还在运行），但噪音大（质量差）、费电（成本高）、没有智能功能（技术落后），修起来还找不到零件（难维护）。

遗留系统的特征：

特征	说明
技术陈旧	使用过时的编程语言、框架、数据库
文档缺失	设计文档丢失或与代码不一致
人员流失	原始开发人员已离职
业务关键	承载核心业务，不能轻易替换
维护困难	代码质量差，修改风险高
集成困难	难以与新系统对接

⚠️ 考点： 遗留系统虽然"老"，但通常承载着核心业务逻辑，不能简单丢弃。

10.5.2 遗留系统的四种处理策略（★★★ 必考）

策略	英文	含义	成本	风险	适用场景
淘汰	Retirement	直接停用，不再使用	低	高（业务中断）	系统已无使用价值
集成	Encapsulation	通过接口封装，与新系统集成	中	中	系统功能仍有价值，但需要与新系统协作
改造	Reengineering	对系统进行再工程，提升质量	高	中	系统有价值但技术需要更新
替换	Replacement	用新系统完全替代旧系统	最高	最高	系统已完全不可维护

💡 记忆口诀： "淘集改替"

淘汰 = 扔了（最省事但风险大）

集成 = 包起来用（折中方案）

改造 = 翻新升级（最推荐）

替换 = 以新换旧（最彻底但最贵）
💡 通俗理解：

淘汰 = 旧手机扔了不用

集成 = 旧手机当闹钟，新手机打电话

改造 = 旧手机刷机升级

替换 = 买个新手机，旧手机退休

10.5.3 遗留系统分析（评估）

概念定义： 对遗留系统进行全面评估，确定其当前状态和最佳处理策略的过程。

评估维度：

维度	评估内容	方法
技术价值	当前技术栈是否过时	技术成熟度分析
业务价值	承载的业务是否仍然重要	业务影响分析
代码质量	代码的可维护性	代码扫描、复杂度分析
文档完整度	文档是否齐全	文档审查
人员能力	是否有人能维护	人员技能评估

决策矩阵（技术价值 × 业务价值）：

	高业务价值	低业务价值
高技术价值	继续投资/改造	集成/封装
低技术价值	优先改造/迁移	淘汰

10.5.4 系统迁移方法

迁移方式	说明	优点	缺点	类比
直接切换	一次性从旧系统切换到新系统	简单快速	风险极高	旧房拆了直接住新房
并行运行	新旧系统同时运行一段时间	风险低、可对比	成本高	新旧房同时住一段时间
分阶段迁移	按模块逐步迁移	风险可控	耗时长	一个房间一个房间装修
试点迁移	先在部分用户中试运行	验证可行性	覆盖面小	先装修一间样板间

⚠️ 考点： 并行运行是最安全的迁移方式（出问题可以回退到旧系统），但成本最高（维护两套系统）。

10.6 软件重构（★★ 常考）

10.6.1 重构的定义

概念定义： 在不改变软件外部行为 的前提下，对软件内部结构 进行调整，以改善其可理解性和可修改性。

通俗解释： 就像整理房间------东西还是那些东西（功能不变），但重新摆放、归类、收纳后，找东西更方便了（代码更好维护了）。

⚠️ 核心原则： 重构不改变外部行为！只是让代码"更好看、更好改"，功能完全不变。

10.6.2 重构 vs 重设计 vs 重写

对比	重构（Refactoring）	重设计（Redesign）	重写（Rewrite）
改变行为	❌ 不改变	⚠️ 可能改变	✅ 完全重新实现
改变结构	✅ 改善内部结构	✅ 重新设计结构	✅ 全新结构
风险	低	中	高
成本	低	中	高
适用场景	代码质量差但功能正确	架构有缺陷	系统完全不可维护
类比	整理房间	重新装修	推倒重建

10.6.3 常见重构手法

重构手法	说明	举例
提取方法	将过长的方法拆分为多个小方法	把200行的方法拆成5个40行的方法
提取类	将职责过多的类拆分为多个类	把"万能类"拆成专门的职责类
重命名	让变量/方法名更清晰	`a` → `totalPrice`
内联方法	将简单的方法合并到调用处	只有一行代码的方法直接合并
移动方法	将方法移到更合适的类中	把放错位置的方法移到正确的类
以多态取代条件	用多态替代大量的if-else/switch	策略模式替代条件判断

💡 记忆技巧： 重构的核心就是------让代码像说话一样清晰。

10.6.4 重构的原则

原则	说明
小步快跑	每次只做一小步重构，频繁提交
测试保障	重构前后必须运行测试，确保行为不变
不混合	重构和加功能不要同时进行
先理解	先读懂代码再重构，不要盲目修改
持续重构	重构不是一次性活动，而是持续的过程

⚠️ 高频考点： "重构时不加功能，加功能时不重构"------这是重构的第一原则！

10.7 技术债务（★★ 新兴考点）

10.7.1 技术债务的概念

概念定义： 在软件开发过程中，为了短期利益 （如赶工期）而做出的非最优技术决策 ，这些决策会在未来产生额外的维护成本（即"还债"）。

通俗解释： 就像刷信用卡------现在花钱很爽（快速上线），但以后要还本金+利息（维护成本暴增）。技术债务就是你欠系统的"技术信用卡"。

技术债务的来源：

来源	说明	举例
有意为之	明知不最优但故意为之	为了赶上线日期先写临时方案
无意产生	经验不足导致的不良设计	新手写了大量重复代码
环境变化	当初合理现在不合理	技术栈过时了
代码腐化	长期缺乏维护导致质量下降	多人修改导致代码混乱

10.7.2 技术债务的分类

类型	英文	说明	举例
有意债务	Deliberate	团队主动选择的技术妥协	"先上线，以后再优化"
无意债务	Inadvertent	非故意的技术缺陷	经验不足导致的设计问题
架构债务	Architectural	架构层面的技术妥协	单点设计、紧耦合
代码债务	Code	代码层面的质量问题	重复代码、过长方法
测试债务	Test	缺乏测试覆盖	没有单元测试
文档债务	Documentation	文档缺失或过时	API文档与实际不一致

10.7.3 技术债务的管理

管理策略：

策略	说明	适用场景
识别	通过代码扫描、架构评审发现债务	定期执行
度量	量化债务的大小和优先级	使用SonarQube等工具
优先级排序	按影响和紧急程度排序	高影响先还
制定计划	制定还债路线图	每个迭代还一部分
预防	建立规范防止新增债务	代码审查、架构评审

💡 管理原则： 技术债务不是要全部清除 （有些债务是合理的），而是要可控------知道欠了多少、什么时候还、还多少。

三、重点归纳 & 速记口诀

3.1 必背要点清单

编号	要点	重要度
1	软件维护的四种类型及占比	★★★★★
2	架构退化（侵蚀vs腐化）的概念	★★★★
3	Lehman八大演化定律（核心几条）	★★★★
4	遗留系统的四种处理策略	★★★★★
5	系统迁移的四种方式及优缺点	★★★★
6	重构的定义与原则	★★★★★
7	重构 vs 重设计 vs 重写的区别	★★★★
8	技术债务的概念与管理	★★★★
9	可维护性的六个维度	★★★
10	架构恢复的概念与方法	★★★

3.2 速记口诀

四种维护类型：

🎵 "纠适完预，完善最多预防最少"

纠错（修bug）→ 适应（换环境）→ 完善（加功能）→ 预防（打补丁）

占比：完善(50%) > 适应(25%) > 纠错(20%) > 预防(5%)

遗留系统四策略：

🎵 "淘集改替"

淘汰（扔了）→ 集成（包起来）→ 改造（翻新）→ 替换（买新的）

风险从低到高，成本从低到高

系统迁移四方式：

🎵 "直并分试"

直接切换（最快最险）→ 并行运行（最安全最贵）→ 分阶段（最稳最慢）→ 试点（先试后推）

重构核心原则：

🎵 "重构不加功能，加功能不重构"

Lehman核心定律：

🎵 "越改越复杂，不改质量降"

L1 持续变化（不变就废）

L2 复杂度递增（越改越乱）

L7 质量递减（不保养就退化）

技术债务：

🎵 "借债一时爽，还债火葬场"

有意债务 = 明知故犯

无意债务 = 不知不觉

管理原则：不是还清，是可控

四、历年真题 & 考点映射

4.1 近5年真题汇总

年份	题型	分值	考点内容
2024	选择题	2分	软件维护类型判断（新增功能属于哪种维护）
2024	选择题	2分	重构的定义（不改变外部行为）
2024	案例分析	25分	遗留系统评估与迁移方案设计
2023	选择题	2分	遗留系统的处理策略选择
2023	选择题	2分	Lehman演化定律
2023	案例分析	25分	架构退化分析 + 重构方案设计
2022	选择题	2分	四种维护类型中占比最大的
2022	选择题	2分	技术债务的概念
2022	案例分析	25分	系统迁移方案对比与选择
2021	选择题	2分	架构侵蚀与架构腐化的区别
2021	选择题	2分	重构与重设计的区别
2021	案例分析	25分	遗留系统评估 + 处理策略分析
2020	选择题	2分	适应性维护的定义
2020	选择题	2分	并行运行迁移方式的特点
2020	案例分析	25分	架构维护方案 + 技术债务分析
2019	选择题	2分	预防性维护的目的
2019	选择题	2分	遗留系统的特征
2019	案例分析	25分	综合题：架构演化方案 + 迁移策略 + 重构分析

4.2 出题规律分析

规律	说明
维护类型必考	每年必考判断某种修改属于哪种维护类型
遗留系统是案例常客	案例分析题常考遗留系统评估与处理策略
重构概念高频	选择题常考重构的定义和原则
迁移方式对比常考	常考四种迁移方式的优缺点对比
技术债务是新热点	近年新增考点，选择题和案例都可能出现
Lehman定律出选择	通常出1道选择题，考核心定律含义

五、典型例题 & 解析

例题1（选择题）

题目： 某企业为了适应新的操作系统版本，对其ERP系统进行了适配修改。这种维护活动属于（）。

A. 纠错性维护

B. 适应性维护

C. 完善性维护

D. 预防性维护

答案：B

解析：

纠错性 = 修复bug（题目没有说修bug）
适应性 = 适应外部环境变化（操作系统版本变化 = 环境变化）
完善性 = 增加新功能（题目没有说加功能）
预防性 = 预防未来问题（题目没有说预防）
关键词："适应新的操作系统版本" → 环境变化 → 适应性维护

例题2（选择题）

题目： 以下关于软件重构的说法，正确的是（）。

A. 重构会改变软件的外部行为

B. 重构和增加新功能应同时进行

C. 重构不改变软件的外部行为，只改善内部结构

D. 重构就是重写系统

答案：C

解析：

A错误：重构的核心原则就是不改变外部行为
B错误：重构和加功能不能同时进行（第一原则）
C正确：重构 = 不改变行为 + 改善内部结构
D错误：重构 ≠ 重写，重写是推倒重来，重构是在现有代码上调整

例题3（案例分析题）

题目： 某银行的核心交易系统是一个运行了15年的遗留系统，采用C/S架构，使用VB6.0开发，数据库为Oracle 9i。该系统存在以下问题：

原始开发人员已全部离职
设计文档严重缺失
系统响应速度越来越慢
无法与新的移动端渠道对接
维护成本占IT总预算的40%

但该系统承载着银行80%的核心交易业务，每天处理超过100万笔交易。

问题：

请分析该遗留系统的现状，评估其技术和业务价值。
请选择最合适的处理策略，并说明理由。
请设计一个系统迁移方案。

参考答案：

问题1：

评估维度	现状分析	评估结果
技术价值	VB6.0和Oracle 9i均已过时，技术栈严重老化	低
业务价值	承载80%核心交易，日处理100万笔	高
代码质量	无原始开发人员，维护困难	低
文档完整度	设计文档严重缺失	低
维护成本	占IT总预算40%，成本过高	低

结论： 高业务价值 + 低技术价值 → 需要优先改造或替换。

问题2：

选择改造（再工程）+ 分阶段迁移的组合策略，理由：

系统承载核心业务，不能直接淘汰（风险太大）
一次性替换风险过高（100万笔/天的系统不能停）
简单集成无法解决技术栈过时和性能问题
改造可以逐步将核心逻辑迁移到新技术栈，同时保持业务运行

问题3：

采用分阶段迁移 + 并行运行的方案：

阶段	内容	迁移方式	时间
第一阶段	架构恢复：分析现有代码，还原架构文档	-	2个月
第二阶段	搭建新系统基础框架，建立API网关	-	1个月
第三阶段	逐步迁移非核心模块（查询、报表等）	分阶段迁移	3个月
第四阶段	迁移核心交易模块，新旧系统并行运行	并行运行	3个月
第五阶段	验证新系统稳定性，逐步切换流量	并行→直接切换	1个月
第六阶段	旧系统下线，完成迁移	直接切换	1个月

风险控制：

并行运行期间保持旧系统作为回退方案
每个阶段设置验收标准，不达标不进入下一阶段
核心交易模块迁移时先在非高峰时段试运行

六、易错点 & 避坑指南

6.1 常见错误一览

错误	正确理解	纠正建议
❌ "架构侵蚀和架构腐化是一回事"	侵蚀=设计实现不一致，腐化=质量下降	侵蚀是"走样了"，腐化是"变差了"
❌ "完善性维护占比最小"	预防性维护占比最小(5%)，完善性最大(50%)	口诀：完>适>纠>预
❌ "重构就是重写系统"	重构不改变行为，重写是推倒重来	重构=整理房间，重写=拆了重建
❌ "重构时可以顺便加新功能"	重构和加功能不能同时进行	这是重构的第一原则！
❌ "遗留系统应该直接替换"	遗留系统承载核心业务，直接替换风险极高	优先考虑改造或分阶段迁移
❌ "并行运行成本最低"	并行运行需要维护两套系统，成本最高	并行运行最安全但最贵
❌ "技术债务应该全部清除"	技术债务管理的目标是可控，不是清零	有些债务是合理的（有意为之）
❌ "维护就是修bug"	修bug只是纠错性维护(20%)，完善性才是大头	维护包括四种类型
❌ "软件交付后就不需要架构工作了"	架构需要持续维护和演化	架构是活的，不是死的

6.2 案例分析题答题技巧

遗留系统题的标准答题框架：

复制代码

第一步：评估（技术价值 × 业务价值）
第二步：选策略（淘汰/集成/改造/替换）
第三步：定方案（迁移方式 + 分阶段计划）
第四步：控风险（回退方案 + 验收标准）

架构退化分析题的答题框架：

复制代码

第一步：识别退化现象（哪些质量属性下降了）
第二步：分析退化原因（需求变化？技术过时？人员流失？）
第三步：提出改进方案（重构？迁移？引入新技术？）
第四步：制定实施计划（分阶段、控风险）

维护类型判断题的关键词法：
- "修复/解决/改正" → 纠错性
- "适应/兼容/升级环境" → 适应性
- "新增/增加/扩展/提升" → 完善性
- "预防/优化/改善结构" → 预防性

📝 本章小结： 本章的核心就是五件事------理解架构退化 （侵蚀+腐化）、掌握维护类型 （纠适完预）、管理遗留系统 （淘集改替）、做好软件重构 （不改行为改结构）、控制技术债务 （不是清零是可控）。其中维护类型判断 和遗留系统处理是每年必考的核心！

第10章 软件架构的演化和维护 — 系统架构设计师