第 10 章 软件维护与逆向工程学习目标掌握软件维护的四种类型及占比规律理解退化与技术债的累积机制掌握逆向工程、再工程(重构)的技术路线了解遗留系统现代化的策略(绞杀者模式等)理解软件生命周期的终止(EOL)决策掌握维护工程的具体活动(影响分析、回归选择)10.0 为什么维护是独立学科软件开发的目标不是交付那一刻,而是系统在整个生命周期内持续产生业务价值。经验数据:维护占软件总成本的 60–80%(生命周期视角);完善性维护(新功能)占维护的约一半——维护本质是没有项目外壳的持续开发;因此维护需要与开发同等的工程纪律:估算、设计、测试、配置管理,一样都不能少,只是节奏更小、频次更高。反模式:“开发期正规军,维护期游击队”。维护期没有评审、没有测试补充、随手改——这是第 2 章所述退化的加速器。10.1 维护的定义与类型软件维护:交付后对软件进行的修改活动。经典四分法:类型目的占比(经验)OOS 例纠错性(Corrective)修复上线后发现的缺陷~20%支付回调偶发丢失的修复适应性(Adaptive)适应环境变化(OS/DB/依赖/法规)~25%适配新支付网关 API v2完善性(Perfective)新增/增强功能~50%增加预售功能预防性(Preventive)改善可维护性/性能,防患未然~5%偿还技术债、升级框架关键洞察:完善性维护占大头——软件生而需变。维护不是修 bug,而是持续的再开发。维护成本通常数倍于初始开发成本(10 年生命周期中,维护占 60–80%)。维护类型的管理含义:类型管理含义纠错占比高质量内建机制(第 9 章)有漏洞,查过程适应占比高环境不稳定或依赖管理差(第 7 章依赖锁定)完善占比高正常;但要确认走变更流程,不是顺手改预防占比过低技术债无人管(见 10.2),长期必付出利息10.2 退化与技术债退化(Degradation)每次修改都引入新缺陷的概率 0,而回归测试无法 100% 覆盖 → 长期累积:代码结构腐化(模块边界模糊、耦合升高);文档与实现脱节;知识流失(原作者离开);环境漂移(依赖升级、硬件换代)。结果:修改成本逐年上升,“越改越难改”,直到重写成为选项。退化的可观察信号(提前预警):同一模块的缺陷重复出现(修复无效);修改一个小需求的波及面持续扩大(影响分析越来越长);新人上手时间显著增加;回归测试时间超过开发时间;只有某某懂的模块数量增加。技术债(Technical Debt)隐喻:为短期速度牺牲长期质量,留下利息(未来修改成本);四类(Wang Cowan):故意-审慎(明知有债、权衡后借)→ 健康;故意-轻率(为赶工硬编码)→ 常见;无意-审慎(发现后规划偿还)→ 可控;无意-轻率(没意识到)→ 最危险。管理:技术债显式化(登记册)、按风险排序、定期偿还窗口(OOS:大促后 2 周)、避免无限期展期;利息模型:欠债模块的每次修改成本 基准 × (1 利息),利息随时间复利。技术债登记册字段:ID: TD-07 描述: 计价规则 if-else 链(14 个分支,无策略抽象) 类型: 故意-审慎(促销期赶工,ADR-009 记录在案) 位置: pricing/calc.py 利息: 每次促销规则变更约 2 人天回归 偿还方案: 提取 PricingStrategy 族(预计 3 人天) 优先级: P1(促销季前必须还) 窗口: 2026-10 大促后 2 周还债优先级公式(经验):优先级 ∝ 利息(每次修改附加成本)× 修改频率 × 风险放大系数(资金/安全模块 ×2)。重要但很少改的债可以长期持有,边缘但天天改的债最急。10.3 维护工程活动影响分析(变更前置)修改前回答:这条变更波及哪些模块/接口/测试/数据?工具:静态依赖分析、调用图、变更影响分析(CIA)工具;纪律:无影响分析不进入修改。影响分析输出模板(维护变更单必备):变更: ORD-118 订单列表增加跨境筛选 波及: 订单查询接口(加参数)/ 列表页前端 / 索引(是否需新复合索引) 测试: TC-ORD-031~045 回归 新增 2 条筛选用例 数据: 无迁移(字段已存在) 风险: 低(只读路径);回滚: 关筛选开关回归测试与回归测试选择全量回归成本高 →基于风险的测试选择:用变更影响分析圈定受影响用例集;变更追踪:commit → 受影响模块 → 关联测试用例(需要第 3 章的追溯矩阵)。选择策略梯度:变更规模回归范围单模块小改该模块单测 关联 E2E跨模块/接口变更契约测试 受影响 E2E 集基础设施/依赖升级全量回归 性能基准数据 schema 变更全量 数据兼容性验证文档与知识的持续维护期文档价值 降低陌生人上手成本;活文档:与代码同库、同 PR 更新;知识传承:轮岗、结对、关键模块双人制(第 8 章)。维护期文档最小集:系统地图(模块与依赖)、数据字典、运维手册(部署/回滚/扩容)、已知问题清单、ADR 索引。五项齐备,任何新人 1 周内可独立处理常规维护。10.4 逆向工程(Reverse Engineering)逆向工程:从现有系统(代码/二进制/行为)重建其设计/规格/模型的过程——“从 3 读到 2,甚至 1”。动机遗留系统无文档/文档失实;准备迁移、重构或再平台化;安全审计、合规取证、互操作性(对接第三方);考古:理解它为什么这样设计。技术层次层次产出手段理解层依赖图、调用图、数据流图静态分析工具结构层重构的类图/模块图解析 AST、聚类分析行为层状态机、时序模型动态分析(日志/插桩)、协议抓取规格层伪 SRS/设计文档人工综合 专家访谈纪律:逆向产出是假设,必须与真实运行行为交叉验证(日志、监控、A/B 对比),不可直接当规格使用。逆向工程实操路线(以 OOS 旧单体为例)静态扫描:模块依赖图 → 找出上帝模块(入度最高的 3 个);数据流分析:追踪核心实体(订单)的读写路径 → 识别隐式全局状态;动态验证:接入日志/trace → 验证调用图与真实流量一致性(抽样 100 笔订单);访谈考古:与原维护者(若有)对照为什么这么写,区分历史包袱与业务规则;重建模型:输出模块图 核心状态机 数据字典,标注置信度(高/中/低);冻结基线:重建模型作为后续重构/迁移的事实来源,入版本库。成本控制:逆向的深度按后续动作决定——只查依赖(理解层)可能 1 人周;要支撑迁移(规格层)可能 3 人月。先明确之后要拿它做什么再开工。10.5 再工程(Re-engineering)与遗留系统现代化在逆向理解基础上改造系统:源到源转换:语言/框架迁移(如 COBOL → Java,通过工具 人工验证);重构:结构改善,行为不变(第 5 章);再平台化(Re-platforming):换底层平台(单体 → 容器/云),代码基本不动;重写(Rewrite):基于重建的规格从零实现——成本最高,仅在改造成本 重写成本时选择。四路线成本-风险对照:路线成本风险行为保持适用重构中低(测试保护)完全保持结构腐化、业务稳定再平台化中中(环境差异)完全保持瓶颈在基础设施源到源转换中高中(工具误差)基本保持语言/框架整体淘汰重写高高(需求重犯旧错)需重新验证业务形态根本变化遗留系统现代化策略策略思想风险适用原样运行(Run)不碰,只维护环境漂移、知识流失稳定、低风险、无变更需求重构(Retire/Refactor)内部改善,边界不变中结构腐化但业务稳定再平台化(Re-platforming)换基础设施,不改业务逻辑中运维成本/性能瓶颈在基础设施重写(Rewrite)推倒重来高(新系统重犯旧错)旧系统无法承载新业务形态绞杀者模式(Strangler Fig)新系统逐功能吞噬旧系统,流量渐进切换,旧系统最终退化消失可控遗留单体,业务持续演进(OOS v1→v2 采用)绞杀者模式要点:在旧系统前建路由/网关层,可按功能/租户路由;新系统实现一个功能 → 切流 → 验证 → 旧系统对应部分停用;数据迁移与双写(过渡期)保证一致性;旧系统进入只读退化直至下线;全程可回滚(切回旧路由)。绞杀者执行检查单(每次切流前):该功能在新旧系统的行为对比报告(抽样 N 笔真实流量回放);双写一致性校验通过(对账脚本,差异 0 或可解释);回滚:路由切回旧系统的演练已完成;数据:新库写入延迟/丢失监控就位;观察期:切流后 72 小时关键 SLI 无劣化。OOS 实例:OOS v1(单体)上线两年后,业务要求跨境订单需独立合规与扩缩容 → 采用绞杀者:新微服务先承接跨境订单子集,旧系统其余功能不动,6 个月后旧系统订单模块退役。绞杀者常见陷阱:“切一半卡住”:新功能切了 30%,旧 70% 仍在跑,双系统长期并存成本爆炸 → 每次切流设退役倒计时(旧功能停用日期先定);数据双写不一致无人对账 → 对账脚本是门禁,不是可选项;路由层成为新瓶颈/新单点 → 网关层本身要有容量与故障预案。10.6 软件终止(EOL)决策当维护成本 业务价值时,应决策终止:信号:每次小修改引发大范围回归;关键知识持有者不可得;运行环境无法支撑;安全漏洞无法修复;决策框架:量化:年度维护成本 vs 业务收益 vs 迁移成本(3 年 TCO);选项:Run / 重构 / 再平台 / 重写 / 终止;终止预案:数据迁移、用户沟通、并行期、回退窗口;纪律:EOL 是计划内的,不是突然没人维护了。EOL 决策书模板:系统: X 报表系统(运行 9 年) 维护成本: 3 人全年(含 2 次/年事故处理) 业务价值: 月活 40 人,功能 80% 已被 BI 平台覆盖 选项对比(3 年 TCO): 继续维护 9 人年 / 迁移 2 人年1 人年运维 / 直接下线(数据归档) 决策: 迁移 并行 3 个月 下线 数据: 5 年报表归档至对象存储,保留查询 API 1 年 沟通: 用户公告提前 2 个月10.7 维护阶段的反模式反模式症状对策游击队维护无评审无测试随手改维护变更单模板(10.3)债无限展期登记册只增不还还债窗口 优先级公式(10.2)考古式重写不看旧系统直接重写逆向先行,成本对照(10.4/10.5)双写不对账迁移期数据悄悄漂移对账脚本门禁(10.5)僵尸系统无人用但无人敢删EOL 定期评审(10.6)文档断代原作者离职后文档失实活文档 双人制(10.3)10.8 本章 FAQQ1:维护期还能用敏捷吗?能,且推荐:维护请求进待办列表(与开发同池,竞争优先级),按迭代消化,DoD 相同。维护走加急绿色通道是范围失控的主要来源。Q2:重写还是重构,怎么定量判断?对照三数:① 重构到目标的估算(含测试补全);② 重写估算(含逆向 需求重建 并行验证);③ 期间的业务停滞/双轨成本。经验:行为必须 100% 保持 → 重构/再平台;业务形态根本变化 → 重写或绞杀者。Q3:逆向工程结果可信吗?它是带置信度的假设。可信度 静态证据 × 动态验证 × 人工确认。支撑迁移决策前,至少完成动态验证(10.4 步骤 3)并标注置信度。Q4:绞杀者与微服务拆分是一回事吗?不是。微服务是目标架构,绞杀者是迁移方法——你完全可以用绞杀者方式迁移到单体内部的模块边界。方法可复用,架构按需选(第 4 章信号)。Q5:如何说服业务方给技术债还债排期?用利息语言(10.2 公式):这个模块每次变更多花 2 人日,下两个季度要变更 4 次,合计 8 人日;现在还债 3 人日,净省 5 人日。还债不是成本项,是有回报的项目——按项目格式呈现(投入、回报、期限、Owner),它就能进入 PO 的优先级排序,而不是被新需求永远挤掉。Q6:绞杀者迁移中,“长尾功能”(没人用但不敢删)怎么处理?三步:① 数据说话——拉 6 个月流量/调用数据,近零调用的功能进下线清单;② 下线流程——公告 弃用(deprecation:调用打日志告警,而非直接移除) 观察期;③ 归档——观察期内告警触发则退回维护清单并记录原因。长尾本质是不敢删的心理问题,不是技术问题——把删变成有证据、有流程、可回滚的动作,阻力即消。附录 A:遗留系统盘点与分级维护/演进管理的第一步:知道手里有哪些老资产。盘点表示例:系统年龄月活/用途技术栈文档测试知识持有年维护成本OOS v1 订单2 年核心业务Java/MySQL全好2 人3 人年对账报表6 年40 人PHP/MySQL部分无1 人(已离职)1.5 人年短信网关适配4 年系统级依赖Python无无1 人0.5 人年营销活动 H5 后台1 年高频Node全中2 人2 人年分级判据(决定策略):业务价值(使用频率/收入贡献)×变化频率→ 决定投入还是冻结;变更成本(测试覆盖/文档/知识集中度)→ 决定能不能安全改;风险等级(资金/安全/合规)→ 决定工程纪律最低配置。分级结论示例:对账报表 低价值 高变更成本 中风险 → EOL 评估候选(10.6 流程);短信网关适配 系统级依赖 无文档 → 先特征测试 最小文档(10.4 理解层),再谈重构;OOS v1 高价值高频 → 绞杀者演进(10.5)。节奏:盘点每半年一次,新系统与下线系统都更新此表——它同时是 EOL 评审(10.6)与架构规划(第 4 章)的输入,一张表三个用途。附录 B:维护请求管理维护请求与开发请求同池竞争,但有四个差异:方面开发请求维护请求入口PO 写故事任意渠道,但必须登记(工单 分类)分诊按优先级排序先按四型分类(纠错/适应/完善/预防),纠错类走快速通道额外工件无影响分析单(10.3 模板)强制SLA迭代节奏纠错 P1 24h 响应;适应性批量排期纪律:一切维护请求必须登记——口头需求是维护期范围蔓延的起点;纠错/完善占比是过程指标:纠错占比连续三月偏高 → 触发质量回溯(第 9 章);预防性占比应 ≥5%——长期为 0 说明技术债无人偿还(10.2);月度维护报告:分型计数 平均处理时长 Top3 重复问题模块(重复 根因未除,该修根因而非继续打补丁);大促/发布冻结期(第 7 章),维护请求同样冻结,仅 P1 例外——冻结无豁免,否则冻结不存在。10.9 小结维护四型:纠错/适应/完善/预防,完善占半,维护是持续再开发;维护需要与开发同等的工程纪律;退化有五个预警信号;技术债:登记册 利息模型 优先级公式 偿还窗口;维护工程:影响分析前置(变更单模板) 基于风险的回归选择 活文档最小集;逆向工程:理解/结构/行为/规格四层,产出是假设需验证,深度按用途定;再工程四路线成本递增;绞杀者模式 切流检查单 三个陷阱;EOL 应计划内决策,有决策书模板。思考题为什么完善性维护占比最高这一事实,决定了可维护性应作为架构设计的一级质量属性?技术债四象限中,无意-轻率为何最危险?团队应建立什么机制防止它?一个 15 年的金融遗留系统,无文档、无测试、原作者退休,给出你的现代化路线(策略 阶段 风险)。绞杀者模式中的双写过渡期可能出现哪些数据不一致?如何检测与修复?用 10.2 的优先级公式,给你的系统 3 个技术债排序,并指定偿还窗口。对重写 vs 重构写一份定量对照:三个估算数各怎么取?给出你的判断阈值。识别你所在组织的一个僵尸系统,按 EOL 决策书模板评估:继续/迁移/下线。逆向工程六步路线(10.4)中,哪一步最容易被省略?省略了会付出什么代价?