技术债偿还策略

• "20% 规则"的提出与落地争议
• 童子军军规（boy scout）的替代思路
• 两种方式在工程实践中的取舍

"20% 规则"建议每个迭代拿出约 20% 的时间用于重构/质量投入，以平衡业务与债。其落地争议在于：1) 20% 往往被业务挤压，实际很难兑现；2) 比例是拍脑袋，不适应不同团队/阶段的差异；3) 容易变成"为完成配额而做形式化重构"。替代思路是"童子军军规"（boy scout rule）——"每次离开时让营地比来的时候更干净"，即每次修改代码时顺手清理所触碰区域的债，不设独立时间块，零协调成本。童子军军规的优势是持续、增量、无排期负担，把还债融入日常开发。实践中两者常结合：用童子军军规处理小债、控制增量恶化，用"专项还债周"或"空窗期"处理需要集中投入的大债，并根据团队债务水位动态调整投入比例，而非死守 20%。

本题考察"重构与功能的比例治理"。核心是"比例配额有争议，需结合增量清理与专项集中"。回答能指出 20% 的落地痛点并给出更可持续的替代，体现工程成熟度。

• 表征测试的定义与目的
• 先固化现有行为再修改的顺序
• 表征测试在重构中的作用

表征测试（characterization test）是为"现有系统行为"写的测试，它不验证"应该怎样"，而是忠实地记录"现在是什么样"，从而把当前行为固化成契约。重构前先写表征测试，把当前行为（包括那些看似"错误"或"异常"的行为）全部锁住，作为安全网：重构时若测试变红，说明重构改变了行为，可立即发现并修复。这解决了"遗留系统没有测试、不敢重构"的难题——因为无法立刻写出理想的测试，就先写"记录现状"的表征测试，保证重构不改变行为。使用顺序：1) 为待重构代码写表征测试（覆盖主要输入输出与边界）；2) 所有测试通过后开始重构；3) 重构中保持测试通过，一旦变红即停止并分析；4) 重构完成后，再把表征测试逐步演化为真正的单元测试。

表征测试是重构遗留代码的"安全垫"。核心是"先固化行为、再修改"，让重构变得可验证、可回退。回答强调"记录现状而非理想"与"测试变红即警示"，体现对遗留系统重构的实操理解。

• 适应度函数（fitness function）的概念
• 用代码检查强制依赖方向与边界
• 架构重构的持续守护

适应度函数（fitness function）是一组可自动验证的"架构契约"，用于持续守护架构约束。在单体拆微服务等架构级重构中，重构周期长、风险高，需要用适应度函数防止"拆着拆着又耦合回去"。常用工具如 ArchUnit（Java）、依赖规则检查、构建期约束。示例：1) 依赖方向守护——用 ArchUnit 断言"domain 层不得依赖 infrastructure 层""services 不得互相依赖"，违反即测试失败；2) 边界违规守护——断言"订单模块不得引用商品模块内部类""跨模块只能通过公共 API 通信"，防止边界被破坏；3) 允许清单——规定"哪些包可以相互依赖"，其余一律禁止。适应度函数在 CI 中随构建运行，任何违反架构约束的提交都会立即暴露，从而让架构重构在持续推进的同时保持"方向正确"。它把"架构纪律"从口头约定变成可自动执行的检查。

本题考察"架构治理的自动化"。核心是"用可执行检查守护架构演进"。回答能给出 ArchUnit 式的具体约束（依赖方向、边界违规），体现对架构重构实操的把握。

• 债务看板的结构与角色
• 偿还冲刺的组织方式
• 节奏与评审机制

债务看板（debt board）与偿还冲刺（debt sprint）是让债务管理"可执行、可监督"的组织手段。债务看板：把债务项按状态（待评估/待还/还债中/已还）放到看板上，每张债务卡包含类型、本金、利息、优先级、负责人、截止时间，看板让债务一目了然、进度可追踪。偿还冲刺（debt sprint）：定期（如每季度或每两个迭代）安排一个专门的冲刺，集中处理一批高优先级债务；冲刺有明确的冲刺目标（如"还清 top 5 热点债"）、范围与验收标准。组织节奏建议：1) 日常用债务看板持续跟踪，债务进 backlog 与功能同台竞争；2) 定期（季度）做一次"债务评审"，更新利息、优先级、移除已还项；3) 偿债冲刺与业务冲刺交替，避免长期占用；4) 冲刺结束做回顾，验证还债效果（复杂度、缺陷率、周期时间变化）。如此，债务管理既有"持续的看板"又有"集中的冲刺"。

本题考察"债务管理的组织化"。核心是"看板做持续跟踪 + 冲刺做集中偿还 + 定期评审做节奏"。回答体现"看得见、可排期、有节奏"的闭环。

• 重构收益的验证维度
• 重构前后的对比度量
• 用数据确证重构价值

重构的收益不能只靠"感觉变好了"，要用数据验证。核心是对比重构前后的指标：1) 复杂度——用圈复杂度、可维护性指数、重复率等，重构后应显著下降；2) 变更失败率（CFR）——重构后该区域的部署/变更失败率应下降，说明稳定性提升；3) 周期时间（lead time / cycle time）——从需求到上线的时长，重构后该区域的交付应更快；4) 缺陷密度——重构后单位代码缺陷数应下降。验证方法：在重构前打基线（记录这些指标），重构后经过一段时间（排除首月波动）再测，用"前后对比"证明收益。同时量化"收益的货币化"——如周期时间缩短对应多少提速、缺陷率下降减少多少返工，用于向管理层证明还债 ROI。注意：指标变化受多种因素影响，需在相近条件下对比，避免用单一指标下结论。

本题考察"用数据闭环验证重构"。核心是"前后对比 + 多指标 + 货币化"。回答强调"打基线、对比、验证实际收益"，体现对"避免形式化重构"的支撑。

• SQALE 模型与 SonarQube 债务比的原理
• 量化模型在优先级排序中的作用
• 结合人工判断弥补模型局限

用量化模型驱动还债优先级排序，是把债务排序从"拍脑袋"变成"数据驱动"。方法：1) 用 SonarQube/SQALE 对所有模块做统一扫描，得到每模块的债务量（修复成本）与债务比，作为"债量"基线；2) 结合"热点"（修改频率 × 复杂度）与"变更失败率"等动态指标，识别"利率高"（利息累积快）的区域；3) 计算"利息/本金比"或"债务总量 × 利率"，作为排序分数——利息高、本金可控、债务占比大的模块优先；4) 对量化评分高的模块，人工复核其业务影响与架构重要性，形成最终优先级。这种"量化初筛 + 人工复核"的排序法，既利用了模型的客观性，又修正了模型"只覆盖静态可发现债"的局限（架构债、测试债需人工补充）。排序结果写入债务清单，进入 backlog 排期偿还。

本题考察"量化驱动的排序方法论"。核心是"量化初筛 + 人工复核"的双层结构。回答强调"量化识别债量与利率，人工补足架构与业务维度"，体现对模型优缺点的把握。

• 不应简单二选一，而是基于框架判断
• 判断框架：风险、成本、时效
• 用"权衡"而非"绝对"作答

"代码质量 vs 上线速度"是典型的工程权衡题，合格回答不是"永远质量优先"或"永远速度优先"，而是给出一个判断框架。常用框架从三个维度评估：1) 风险——这次改动或上线失败的风险有多大？影响核心路径吗？可回滚吗？风险高则质量优先；2) 成本——现在妥协质量会欠下多少债、利息多高？未来还债成本是否远大于现在多花的时间？还债成本高则质量优先；3) 时效——上线紧迫性的真实程度？是紧急安全/合规修复，还是普通的"想快点"？不同时效对应不同质量底线。综合判断：若风险低、可回滚、妥协成本小，可接受"先上线后补债"；若风险高、不可回滚、将欠下大额债，则宁可延期保质量。此外，质量与速度并非始终对立——好质量（足够测试、清晰结构）往往提升后续速度，短期"慢一点"可能换来长期"快很多"。回答时体现"分层权衡"（核心路径严、边缘路径宽）与"把决策显性化"（记录为何妥协）更佳。

本题考察"工程决策的成熟度"。核心是"用风险/成本/时效框架做权衡，而非情绪化二选一"。回答强调"分层、可回滚、显性化"，体现能把抽象的取舍题落到可操作的判断上。

• 为重构而重构的特征与危害
• 以业务价值与热点数据作为重构依据
• 个人审美与重构动机的区分

"为重构而重构"指为了追求代码"看起来更漂亮"或满足个人审美而进行的重构，它不解决实际业务问题，也不改善关键指标，反而消耗人力、引入风险。其危害是投入了时间却未带来可感知的收益，还可能因为"动了不该动的地方"引入缺陷。避免方法：1) 重构依据必须是"业务价值 + 热点数据"——优先重构那些修改频繁、复杂度高、变更失败率高、正在拖累交付的"热点"区域，因为还债 ROI 最高；2) 重构要能回答"为什么要现在重构、重构后谁受益"——若答不上来，说明动机不足；3) 重构结果要验证——用周期时间、缺陷率、变更失败率等确认收益；4) 在评审中质疑"审美驱动"的重构——除非它同时改善可维护性并带来可度量收益。个人审美可以作为"顺带"的修饰，但不应作为重构的"主动机"。

本题考察"重构动机的正当性"。核心是"用业务价值与热点数据驱动，而非个人喜好"。回答强调"能说清收益的重构才有意义"，体现对"避免形式化"的坚持。

• 重写 vs 偿还的取舍
• 判断"破产"的边界条件
• 重写的风险与前置条件

技术债的"破产"边界，指当债务的偿还成本已超过重写成本、且继续偿还难以挽回时，重写（rewrite）而非"打补丁式偿还"成为更优选择。判断何时重写优于偿还的边界条件：1) 债务过于庞大且盘根错节，逐块偿还几乎不可能，利息仍持续累积；2) 现有系统已无法满足新需求（技术栈过时、架构无法扩展），纯偿还无法解决本质问题；3) 重写可大幅降低长期维护成本，且重写的时间窗口与风险可控；4) 业务允许一段"重写期"而不中断服务。但重写风险极高（遗留系统重写常失败，所谓"第二系统效应"），因此重写前须：明确新系统需求边界、用表征测试固化关键行为、灰度/并行运行逐步迁移、保留旧系统作为回退。真正的"破产"是少数情形，多数情况"逐步偿还 + 迁移"比"推倒重来"更安全。判断时用"剩余本金 + 利息现值 vs 重写成本 + 迁移风险"对比。

本题考察"重写 vs 偿还"的边界判断。核心是"用成本对比 + 风险分析"决定，而非情绪化。回答强调"重写高风险、多数情况渐进偿还更稳妥"，体现审慎。

• 创业公司 vs 成熟公司的债务容忍度差异
• 差异的根源：生存 vs 稳定、速度 vs 规模
• 按公司阶段调整债务策略

创业公司与成熟公司对技术债的容忍度差异显著，根源在于两者的核心诉求不同：创业公司追求"活下去"与"找市场"，需要极快的迭代速度抢占先机，因此对技术债容忍度较高——愿意用"先上线、后补债"换取时间，因为"活下来"比"代码干净"更重要；成熟公司拥有稳定业务与庞大用户，更看重稳定、可维护与合规，对技术债容忍度低——因为一次事故可能造成巨大损失，且债务利息在规模下被放大。按阶段调整策略：创业期以"速度优先、债可接受"，但要有意识地控制"隐性债"、记录关键债，避免债务失控；成长期开始"有节奏还债"，把债务纳入 backlog；成熟期追求"稳定与可持续"，严格管理债务、设置质量门禁、定期还债。无论哪个阶段，"有意识地借债并显性化、有偿还计划"都适用，只是容忍度与节奏不同。

本题考察"按公司阶段调整工程策略"。核心是"承认债务容忍度的合理性，但强调显性化与偿还计划"。回答体现"阶段性策略 + 底线一致性"，显得成熟。

• 窗口期的概念与价值
• 版本冻结期、架构演进窗口的还债应用
• 与业务排期协商的方法

还债的"窗口期"是指业务相对空闲、变更风险可控的特殊时间段，适合集中处理大额债。典型窗口：1) 版本冻结期——发布后到下一迭代前的冻结期，功能不再新增，可集中还债、重构内部结构；2) 架构演进窗口——架构升级、技术栈替换的规划期，趁机把相关债务一并清理；3) 需求低谷期——业务需求少时，把人力转向还债。与业务排期协商的方法：1) 用"还债的收益"说服业务——说明还债能提升后续交付速度、降低风险，用数据（周期时间、缺陷率）支撑；2) 把还债打包成"可交付的成果"（如"重构后接口耗时下降 30%"），让业务看到价值；3) 选择"业务影响最小"的窗口（冻结期、低谷期），降低业务顾虑；4) 与业务建立"还债换速度"的契约——还债后承诺交付提速。窗口期是"双方共赢"的安排，而非单方面挤占业务时间。

本题考察"借时机还债 + 与业务协商"。核心是"选对窗口 + 讲清收益 + 实现共赢"。回答强调"用数据与可交付成果说服业务"，体现协作能力。

• 还债 PR 的拆分原则
• 灰度和回滚策略
• 用测试与评审降低还债风险

还债本身可能引入新缺陷，因此必须做风险控制。策略包括：1) PR 拆分——把大重构拆成小步、可独立验证的 PR，每步只改一个关注点、可单独审查与回滚，避免"巨型 PR"难以审查；2) 测试防护——还债前用表征测试固化行为，还债后跑全量测试 + 静态分析，确保行为一致；3) 灰度发布——还债改动用特性开关或灰度逐步放量，先小流量观察再全量，异常可立即关闭；4) 回滚策略——每次还债作为独立可回滚的提交，保留旧版本可快速 revert；监控变更失败率、缺陷率、错误率作为回滚触发条件；5) 代码评审——还债 PR 必须经过评审，重点检查"是否改变了行为""是否引入新的耦合"。通过"小步拆分 + 测试固化 + 灰度 + 可回滚 + 评审"的组合，把还债风险控制在可接受范围。

本题考察"还债的工程化风险控制"。核心是"小步拆分 + 行为固化 + 灰度回滚"。回答强调"还债也要像功能上线一样严谨"，体现对风险的敬畏。

• 还债文化的建设
• 激励与度量设计
• 避免一次性运动，形成持续习惯

让还债成为团队习惯而非一次性运动，需要文化建设与制度设计：1) 文化层面——把"还债"视为专业责任而非额外负担，让"随手清理"成为默认行为；领导以身作则，认可还债工作的价值；2) 机制层面——把还债纳入正常迭代流程（backlog、配额、专项冲刺），而不是"临时加班搞运动"；3) 激励设计——奖励"发现并登记债""还债并验证收益"的行为，而非只奖励"写新功能"；把还债成果纳入绩效与复盘；4) 度量设计——跟踪债务趋势（债务比、热点数、还债完成率）、还债收益（周期时间、缺陷率、变更失败率），让团队的还债成果"看得见"，形成正向反馈；5) 避免"运动式"——一次性大扫除后若无持续机制，债会快速回潮；应建立"日常小还 + 定期专项"的持续节奏。核心是让还债成为"日常的一部分"而非"偶尔的出击"。

本题考察"工程文化的建设"。核心是"机制化 + 激励 + 度量 + 持续节奏"。回答强调"把还债嵌入日常流程而非推到角落"，体现组织能力。

• 还债与新功能重构的边界
• 避免变更范围扩大
• 还债的验收标准

"还债"与"新功能重构"的边界在于"是否改变外部行为"：还债应该是"行为不变、结构改善"的改动——它不改变任何对外功能、接口或数据语义，只优化内部结构、降低复杂度；一旦重构改变了对外行为、新增了功能或改动接口，就滑向了"新功能开发"。边界判断的基准：还债的验收标准是"行为完全不变"（用表征测试、回归测试验证），而新功能重构则引入新的行为。避免借还债之名扩大变更范围的方法：1) 每笔还债 PR 明确"不改行为"的自述，用测试证明行为不变；2) 评审时审查"是否夹带了与还债无关的功能改动"；3) 若发现需要新功能，应拆成独立的需求单，而不是混入还债；4) 用"行为对照"（重构前后输入输出一致）作为验收。守住"还债不动行为"这条线，才能防止还债变成"顺手加需求"的失控重构。

本题考察"重构边界的纪律"。核心是"还债以行为不变为标志，新功能另立需求"。回答强调"用行为不变做验收 + 评审防夹带"，体现对变更范围的把控。

• 多准则决策的必要性
• 利息、依赖、变更热点的组合
• 避免单一指标排序

还债顺序若只按单一指标（如只按复杂度、只按本金）会失之偏颇，因此需多准则决策。常用准则：1) 利息高低——利息越高的债越优先还，因为持续代价大；2) 变更热点——修改频率 × 复杂度高的热点区域优先，因为还债 ROI 高；3) 依赖关系——优先还"被依赖方"或在依赖链上游的债，因为还它能解锁下游多个改动；4) 风险与影响——直接影响核心路径、稳定性的债优先；5) 偿还成本与时机——本金小、当前窗口期允许的债先还。组合方法：为各准则赋权后打分排序（如"利息 40% + 热点 30% + 依赖 20% + 风险 10%"），或用"必还优先（安全合规）→ 高 ROI（高利息×热点）→ 依赖解锁（上游）"的层级排序。多准则排序避免"只盯一个指标"的盲区，让还债资源投向综合价值最高的地方。

本题考察"多目标排序的决策能力"。核心是"多准则加权、组合而非单一指标"。回答强调"利息 + 热点 + 依赖 + 风险"的综合，体现系统性思维。

• 防复发的机制：规则、门禁、评审
• 已还债区域的持续守护
• 防止边还边欠

债务偿还后要防止"还了又坏"，需建立防复发机制：1) 规则——把还债时确立的约束固化为静态分析规则（如复杂度上限、禁止依赖方向、禁止重复代码），违反即告警；2) 门禁——在 CI 中设置质量门禁（如复杂度超标、覆盖率不足、新增违规则禁止合并），从源头拦截新债；3) 评审——代码评审中重点检查"已还债区域"是否被再次复杂化，把维护已还债区域作为评审关注点；4) 架构约束——用适应度函数（ArchUnit）守护已确立的模块边界与依赖方向；5) 度量跟踪——持续监控已还债区域的指标（复杂度、变更失败率），若反弹则及时干预。通过这些"规则 + 门禁 + 评审"的组合，把"已还债区域"变成"受保护区域"，防止债务在还清后再次累积恶化。

本题考察"偿还后的治理"。核心是"用自动化规则与门禁守护已还债区域"。回答强调"防复发 + 防边还边欠"，体现对债务管理的闭环思维。

• 技术债例会的组织
• 债务清单、利息与优先级的更新
• 避免例会流于形式

技术债例会（debt review）是定期评审债务清单、更新利息与优先级、保持债务管理鲜活的机制。组织方式：1) 频率——定期（如每两周或每月）短会，不宜过长；2) 议程——评审债务清单、更新每笔债的利息与优先级、认领新债、回顾已还债的收益、移除已完成的债；3) 参与——工程师 + 技术负责人 + 产品代表（用于对齐优先级）；4) 产出——每次例会更新债务清单、确定下一阶段还债计划。避免流于形式的关键：1) 例会必须有"可执行的产出"——更新清单、确定还债项、分配负责人，而非只"讨论讨论"；2) 用数据支撑——以债务趋势、热点、变更失败率等数据驱动讨论，避免空谈；3) 与 backlog、sprint 挂钩——例会的决策要落实到迭代计划，否则就是空谈；4) 控制会时与频次，保持价值感；5) 定期回顾"还债是否带来收益"，让例会体现价值。让例会"有产出、有数据、有落地"，才不会沦为形式。

本题考察"债务管理的常态化机制"。核心是"例会要有产出、有数据、有落地"。回答强调"与 backlog 挂钩 + 避免空谈"，体现组织与执行能力。

• 新增债的登记与限制
• 边还边欠的防治
• 准入门槛与评审把关

还债期间若放任新功能继续引入债，就会"边还边欠"、债务不减反增。控制新增债的方法：1) 登记——新功能中出现的任何妥协，都必须显式登记为债务卡（含类型、影响、估算、期限），使其进入 backlog 而非隐性沉淀；2) 限制——设定"新增债配额"（如每迭代新增债不得超过 X 人天），超限则需停止并优先还债；3) 准入门槛——新功能代码必须满足质量门禁（复杂度、覆盖率、无违规），否则不能合并；4) 评审把关——代码评审中质疑"为赶进度而妥协"的写法，要求要么直接写对、要么登记债务；5) 平衡——用"还债 + 新增债"的净变化来衡量（债务净额下降才算健康），而非只看还了多少。通过"登记 + 配额 + 门禁 + 评审"，让新增债受控、可追踪，避免"还的快、欠的更多"。

本题考察"债务收支平衡"。核心是"既要还债，也要控制新增债，看净额"。回答强调"登记 + 配额 + 门禁 + 净额度量"，体现对债务"收支"的全面管理。