English
Technical debt describes design or implementation choices that make future work more costly than an attainable alternative. The useful question is what extra cost a particular choice creates: repeated edits, difficult testing, slow recovery, or a migration that becomes harder to postpone. Calling code “debt” without identifying such consequences does not explain why changing it is worthwhile.
Debt can arise from an intentional compromise or from learning. A reservation system might initially store one price per booking. Later it needs partial refunds and item-level discounts, revealing that the original model cannot express the required distinctions. The initial design may have been reasonable for what was known. Improving it incorporates new understanding rather than simply correcting careless work.
The financial metaphor highlights costs over time, but software debt does not have a universal interest rate or repayment deadline. Some awkward code remains cheap to keep; a rarely edited component can still be costly through outages or an unsupported dependency. Compare the likely future costs of keeping, improving, or replacing a component over the period that matters to the product.
Prerequisites: Programming (§2.1), architectural boundaries (§7.1), and testing (§7.2). Work on an existing small application is especially useful because the behavior and the costs of changing it are visible.
From Borrowed Simplicity to the Economics of Software Evolution
Cunningham’s 1992 report on the WyCash portfolio management system described incremental development and the need to consolidate an implementation as understanding improved. The work was carried out at Wyatt Software. His debt analogy explained why working code might still need internal revision before continued growth became difficult. It was not a recommendation to deliberately write bad code and hope to repair it later.
Fowler’s technical-debt quadrant separates two questions: was the choice deliberate or inadvertent, and was it prudent or reckless? These form four combinations, not a moral ranking of programmers. A team can make a thoughtful decision and later discover a better model. The distinction helps explain how a problem arose; current cost and risk still determine what to do next.
Refactoring developed as a discipline of behavior-preserving structural change, supported by research and programming tools as well as practitioner experience. Fowler’s 1999 book organized a catalog that gave common transformations names, such as extracting a function or moving a responsibility. A shared vocabulary made small transformations easier to discuss and review. The later edition uses different examples while retaining the emphasis on controlled steps.
Feathers’s Working Effectively with Legacy Code addressed a frequent obstacle: a system must be changed, but dependencies make relevant behavior hard to test. Characterization tests record observed behavior; seams provide places to substitute or separate a dependency. An observation is not automatically a requirement, so unexpected behavior should be investigated before being preserved indefinitely.
Lehman’s studies of software evolution described recurring patterns in systems embedded in changing real-world activities. Such systems face pressure to adapt, and changes can add complexity unless work is done to control it. These observations have a scope; they do not mean every fixed program deteriorates with age or that well-managed software must eventually be rewritten.
Static analysis, version history, and operational records provide evidence about where improvement may matter. A file that changes often, causes defects, and requires several teams to coordinate deserves investigation. A large complexity number or a tool’s estimate of “debt hours” is a model-dependent signal, not an invoice for the work the team must perform.
The Economics of Code, Refactoring as Practice, and When to Rewrite
The Cost Model of Technical Debt
For a proposed improvement, distinguish the one-time cost from recurring costs avoided. Include investigation, test preparation, implementation, rollout, and the chance of introducing defects. Benefits may include faster changes, fewer incidents, or an option to add a capability that the current design makes difficult. These categories need estimates and evidence, not one universal scoring formula.
Suppose an awkward module adds half an engineer-day to each relevant change, and four such changes are expected per month. Its estimated extra change cost is 2 engineer-days per month. If improving it takes 6 engineer-days and removes that entire overhead, the simple break-even time is 3 months. Over a 2-month horizon the estimated saving is smaller than the cost; over 6 months it exceeds the cost by 6 days. These calculations assume the workload and saving actually occur and ignore other effects. Vary the assumptions before treating the result as a decision.
Change frequency matters because repeated work repeats its overhead, but it is not the only factor. A rarely changed component can have a severe recovery problem, prevent a required upgrade, or carry a vulnerable dependency. Conversely, a frequently edited file may be easy to change correctly. Use history to locate candidates and then investigate the actual mechanism of cost.
Record an actionable debt item: the observed problem, affected work, proposed remedy, estimated cost, uncertainty, and a trigger for reconsideration. “Move all code to a newer framework” is too broad without a concrete benefit. “Separate tax rules from invoice formatting so that monthly rule updates do not require changes in three renderers” identifies a repeated dependency and an outcome to check.
Prioritization compares alternatives for the same limited capacity. Small local refactoring can be part of feature work; a cross-system data migration may need dedicated planning and ownership. Neither approach makes the cost disappear. After an improvement, check whether the expected work became easier or the failure rate changed, rather than counting only lines removed.
Refactoring: The Practice of Controlled Change
Refactoring aims to change internal structure while preserving relevant observable behavior. Define that behavior at the boundary: return values, errors, persistent effects, externally visible calls, and any timing guarantees that belong to the contract. The fact that a change is intended as refactoring does not prove that it preserves these properties.
Start with a small behavior you can observe. Add focused tests where they are missing, identify a seam around a dependency, and make one understandable transformation at a time. Review the change and run the checks that exercise its consequences. Characterization tests can establish a baseline, while specification examples help avoid preserving an existing bug as if it were intended.
Even an apparently algebraic rearrangement can change a program. In ordinary binary64 arithmetic, (10¹⁶ + (−10¹⁶)) + 1 evaluates to 1, while 10¹⁶ + ((−10¹⁶) + 1) evaluates to 0 because the inner addition rounds. Reordering calls can similarly change side effects or exception timing. An automated refactoring tool has assumptions about language semantics and program structure; inspect its scope rather than treating automation as proof.
Separating structural change from a behavior change makes review more informative. First extract a refund-policy function without changing the rule; then change the rule in a separate step with tests describing the new requirement. A database redesign can contain behavior-preserving steps and deliberate behavior changes. Its size alone does not determine whether each step is refactoring.
Prefer an abstraction that captures a demonstrated common responsibility. Similar-looking code may implement rules that evolve independently, so combining it can create unwanted coupling. The goal is to make expected changes easier to reason about, not to minimize every duplication or maximize the number of named functions. AI-generated changes and tests need the same checks for preserved semantics.
The Rewrite Question
Compare continued maintenance, targeted restructuring, incremental replacement, and a full rewrite. Each has transition costs as well as a desired final state. Existing software often contains important behavior that is poorly documented: input tolerances, migration history, external integrations, and responses to failures. A replacement needs a way to discover which of these behaviors users still depend on.
Incremental replacement routes a chosen capability to a new implementation while the old system continues to provide the rest. This is often called the strangler fig pattern. Choose the routing boundary, data owner, and compatibility contract explicitly. The pattern reduces the size of each cutover, but temporary duplication and integration work can be substantial.
For example, compare old and new report outputs on the same snapshot before switching readers. Read-only shadow execution can reveal discrepancies without changing user data. Duplicating writes is harder: two systems can diverge after a partial failure, and replaying a payment request may have an external effect. A migration needs reconciliation and a clearly designated source of truth, not just two implementations running side by side.
A full rewrite can be justified when the required change is sufficiently fundamental and an incremental route is more costly or infeasible. Estimate feature parity, data migration, parallel maintenance, rollout, and decommissioning, not just the new code. Define checkpoints and stop conditions while comparing the replacement with improvements to the existing system. Spolsky’s warning about lost accumulated knowledge is a useful challenge to a plan, not a proof that every rewrite is wrong.
What Studying This Changes
You can turn a general complaint about code quality into an engineering proposal. State the repeated difficulty, show an example change or incident, identify a plausible remedy, and compare its cost with leaving the problem in place. This makes improvement work discussable alongside feature work.
Choose a small module with a known behavior. Record how a representative change is currently made, add a relevant check, and perform one structural improvement. Repeat the change exercise or inspect the dependency it removed. The result should explain what became easier, not merely that the code looks shorter.
You also learn when to leave code alone. A low-cost inconvenience in a retiring component may not justify restructuring, while an urgent support or recovery problem can matter despite low code churn. Debt management is selecting and checking improvements over time, rather than trying to make an entire codebase conform to one aesthetic ideal.
Resources
Books and Texts
Fowler’s Refactoring develops small structural transformations; Feathers’s Working Effectively with Legacy Code explains how to make existing behavior accessible to tests. Beck connects refactoring with a short testing cycle. Tornhill’s Software Design X-Rays uses development history to locate investigation candidates. Read these with one existing module in view so that a proposed improvement has an observable purpose.
| Book | Role | Type |
|---|---|---|
| Fowler, Refactoring (2nd ed.) | Foundational refactoring text | Depth |
| Feathers, Working Effectively with Legacy Code | Legacy code improvement | Depth |
| Refactoring-loop reference: Beck, Test-Driven Development: By Example | Red-green-refactor discipline | Depth |
| McConnell, Code Complete (2nd ed.) | Construction quality foundations | Depth |
| Richardson, Microservices Patterns | Monolith decomposition patterns | Depth |
| Tornhill, Software Design X-Rays | Behavioral code analysis and hotspot-based debt management | Depth |
Courses, Papers, and Current Sources
Read Cunningham’s WyCash report for the debt metaphor’s original setting and Fowler’s quadrant for the distinction between intent and judgment. The refactoring catalog gives named transformations. Compare arguments about replacement with the actual data, compatibility, and transition costs of a system you know.
| Resource | Platform | Type |
|---|---|---|
| Cunningham, c2.com technical debt pages (free) | c2.com | Depth |
| Fowler, “Technical Debt Quadrant” (free) | martinfowler.com | Reference |
| Fowler, “Strangler Fig Application” (free) | martinfowler.com | Reference |
| Spolsky, “Things You Should Never Do” (free) | joelonsoftware.com | Depth |
| Fowler, online refactoring catalog | refactoring.com/catalog | Reference |
Practice, Tools, and Current Sources
Start with version history, defect records, and an actual change task. Static-analysis tools can help locate complexity or duplication; automated rewrite tools and IDEs can apply selected transformations. Check their assumptions and the resulting behavior. Dependency-update automation supplies proposed changes, not evidence that every update is compatible.
| Resource | Platform | Type |
|---|---|---|
| SonarQube Community Build | docs.sonarsource.com | Practice |
| Git history and issue records | Local repository and project tracker | Practice |
| CodeScene (commercial; free trial/options may vary) | codescene.io | Practice |
| OpenRewrite (free; Moderne platform paid) | openrewrite.org / GitHub | Practice |
| Renovate (open source; hosted options may be paid) | docs.renovatebot.com | Practice |
| refactoring.guru (free) | refactoring.guru | Reference |
| IDE refactoring tools (built-in) | IntelliJ / VS Code / Eclipse | Practice |
Traps
| Trap | Why it misleads | Better response |
|---|---|---|
| Labeling every disliked design as debt | The label does not identify a future cost or a better feasible alternative. | Describe the repeated difficulty and evidence for its cost. |
| Assuming every debt must be repaid | The remaining lifetime and future workload may make repayment uneconomic. | Compare options over a stated horizon, including operational risks. |
| Treating tests as proof that refactoring is safe | Tests observe selected cases and may preserve a mistaken expectation. | Use small steps, relevant checks, and review of semantic changes. |
| Measuring improvement by deleted lines or complexity scores | A smaller representation can hide rather than remove difficulty. | Check whether expected changes and recovery actually became easier. |
| Estimating a rewrite only from new implementation work | Parity, data migration, parallel operation, and retirement can dominate cost. | Plan and validate the transition as well as the target design. |
中文
技术债描述某些设计或实现选择：与可以达到的替代方案相比，它们使未来工作更加昂贵。有用的问题是某个选择具体增加了什么成本，例如重复修改、测试困难、恢复缓慢，或越来越难推迟的迁移。只把代码称为“债务”，却不说明这些后果，无法解释为什么值得修改。
债务既可能来自有意取舍，也可能来自新的认识。预约系统最初可能只为每笔预约存一个价格；后来需要部分退款和逐项折扣，才发现原模型无法表达这些区别。根据当时的信息，最初设计可能是合理的。改进是在吸收新认识，而不只是纠正草率工作。
财务比喻突出了随时间发生的成本，但软件债务没有统一利率或还款期限。有些别扭的代码保留起来成本很低；很少修改的组件，也可能因为故障或停止维护的依赖产生高成本。应在与产品有关的时间范围内，比较保留、改进或替换组件的预期成本。
前置知识：编程（§2.1）、架构边界（§7.1）和测试（§7.2）。修改已有小型应用尤其有帮助，因为既有行为与修改成本都能直接观察。
从借来的简单性到软件演化经济学
Cunningham 在 1992 年介绍 WyCash 投资组合管理系统的报告中，描述了增量开发，以及随着理解加深而整理实现的需要。这项工作发生在 Wyatt Software。债务比喻解释了为什么已经能工作的代码仍可能需要内部修订，以免后续增长变得困难。它不是建议故意写坏代码，再希望日后修好。
Fowler 的技术债四象限区分两个问题：选择是有意还是无意，判断是审慎还是鲁莽。两条轴构成四种组合，而不是对程序员作道德排序。团队可以作出经过思考的决定，后来才发现更好的模型。这种区分帮助解释问题怎样形成，但下一步怎样处理仍取决于当前成本和风险。
重构逐渐发展为保持行为的结构调整方法，既得到研究和编程工具支持，也来自实践经验。Fowler 在 1999 年的书中整理了操作目录，为提取函数、移动职责等常见变换命名。共享术语使小步修改更容易讨论与审查。后来的版本更换了示例，但保留了受控步骤的重点。
Feathers 的《Working Effectively with Legacy Code》处理一个常见障碍：系统必须修改，依赖关系却让相关行为难以测试。特征测试记录观察到的行为；接缝提供替换或分离依赖的位置。观察结果不会自动成为需求，因此应先调查意外行为，而不是无限期地保留它。
Lehman 的软件演化研究描述了嵌入现实活动、随现实变化的系统中反复出现的模式。这类系统承受适应变化的压力，修改也可能增加复杂性，因此需要主动控制。这些观察有适用范围；它们不意味着所有固定程序都会因年老而退化，也不意味着管理良好的软件最终必然重写。
静态分析、版本历史和运行记录可以提供证据，帮助判断哪里值得改进。如果一个文件经常修改、产生缺陷，并要求几个团队共同协调，就值得调查。很高的复杂度数值，或工具估算的“债务小时”，只是依赖模型的信号，不是团队必须支付的工作账单。
代码经济学、Refactoring 实践与何时重写
Technical Debt 的成本模型
评估一项改进时，应区分一次性成本与能够避免的持续成本。成本包括调查、测试准备、实现、推出，以及引入缺陷的可能性。收益可能是修改更快、事故更少，或获得当前设计难以支持的新能力。这些类别需要估计和证据，不能靠一个通用评分公式解决。
假设一个难改的模块让每次相关修改多花半个人天，预计每月有四次这样的修改，那么额外修改成本约为每月 2 个人天。如果改进需要 6 个人天，并能完全消除这部分开销，简单的回本时间就是 3 个月。在 2 个月范围内，预计节省小于成本；在 6 个月范围内，节省比成本多 6 个人天。这些计算假设工作量与节省确实发生，并忽略其他影响。把结果用于决定之前，应改变假设，检查结论是否仍然成立。
修改频率很重要，因为反复工作会反复支付开销，但它不是唯一因素。很少修改的组件可能有严重恢复问题、阻碍必要升级，或依赖有漏洞的软件。反过来，经常修改的文件也可能很容易正确修改。用历史寻找候选对象，再调查实际成本怎样产生。
把债务记录成可行动的事项：观察到的问题、受影响的工作、拟议补救、估计成本、不确定性，以及重新评估的触发条件。“把全部代码迁到新框架”如果没有具体收益，就太宽泛；“把税务规则与发票排版分开，使每月规则更新不必改三个渲染器”，则指出了重复依赖和可检查的结果。
优先级比较的是怎样使用同一份有限能力。小范围重构可以伴随功能开发；跨系统数据迁移则可能需要专门计划与负责人。两种方式都不会使成本消失。改进后应检查相关工作是否真的更容易、故障是否变化，而不只统计删掉了多少行代码。
Refactoring：受控变化的实践
重构旨在调整内部结构，同时保持相关的可观察行为。需要在边界上明确这些行为：返回值、错误、持久化影响、外部可见调用，以及契约包含的时间保证。把一次修改称为重构，只说明意图，不能证明这些性质确实被保留。
从能够观察的小块行为开始。缺少测试时补充针对性检查，围绕依赖找出接缝，每次只做一个能理解的变换。审查修改，并运行能够覆盖其后果的检查。特征测试可以建立基线；规范示例则帮助避免把已有缺陷当成预期行为保留下来。
看似代数等价的调整也可能改变程序。在常见的 binary64 浮点运算中，(10¹⁶ + (−10¹⁶)) + 1 得到 1，而 10¹⁶ + ((−10¹⁶) + 1) 得到 0，因为内部加法发生了舍入。重排调用也可能改变副作用或异常出现的时间。自动重构工具对语言语义和程序结构有自己的假设，应检查适用范围，而不是把自动化当成证明。
把结构调整与行为变化分开，会使审查更有信息量。例如，先提取退款策略函数而不改变规则，再单独修改规则，并用测试说明新需求。数据库重设计可以同时包含保持行为的步骤和有意改变行为的步骤。仅凭规模，不能判断其中每一步是否属于重构。
抽象应当对应已经确认的共同职责。外观相似的代码可能实现分别演化的规则，强行合并会产生不需要的耦合。目标是让预期修改更容易推理，而不是消除每一处重复，或尽量增加具名函数。AI 生成的修改和测试也需要同样的语义检查。
Rewrite 问题
应比较继续维护、针对性调整、增量替换和整体重写。每种方案除了期望的最终状态，都有过渡成本。已有软件常包含记录不足但重要的行为：输入容忍方式、历史数据迁移、外部集成，以及失败后的响应。替代方案需要设法发现用户仍然依赖哪些行为。
增量替换把选定能力路由到新实现，同时让旧系统继续承担其余功能，这通常称为绞杀者榕模式。应明确路由边界、数据归属和兼容契约。这种方式缩小了每次切换的范围，但临时重复和集成工作仍可能很大。
例如，在切换报表读取之前，可以使用同一个数据快照比较新旧输出。只读影子执行可以发现差异，而不改变用户数据。重复写入则更困难：部分失败后两个系统可能分歧，重放支付请求还可能产生外部影响。迁移需要核对与修复机制，并明确哪一方是权威数据来源，而不只是让两个实现并排运行。
当需要的改变足够根本，且增量路径更贵或不可行时，整体重写可能合理。应估计功能覆盖、数据迁移、并行维护、推出和旧系统退出的成本，而不只估计新代码。设定检查点和停止条件，同时与改进既有系统比较。Spolsky 关于丢失积累知识的提醒，可以用来质疑计划，但不能证明所有重写都错误。
学习这一部分会改变什么
你能够把笼统的代码质量抱怨转化为工程提案：说明反复遇到的困难，展示一次修改或事故，指出可行补救，并比较修改成本与保留问题的成本。这样，改进工作就能与功能开发一起讨论。
选择一个行为已知的小模块，记录当前怎样完成一次有代表性的修改，补充相关检查，再做一项结构改进。重新完成修改练习，或检查被消除的依赖。结果应解释什么变得容易了，而不只是代码看起来更短。
你也会学习何时不动代码。即将退出使用的组件里，成本很低的不便未必值得调整；迫切的维护或恢复问题，则可能在代码修改频率很低时仍然重要。管理技术债是持续选择和检查改进，而不是让整个代码库符合某一种审美理想。
资源
书籍与文本
Fowler 的《Refactoring》讲解小步结构变换；Feathers 的《Working Effectively with Legacy Code》解释怎样使既有行为能够测试；Beck 把重构与短测试循环联系起来；Tornhill 的《Software Design X-Rays》利用开发历史寻找调查对象。结合一个现有模块阅读，可以让改进建议具有可观察的目的。
| 书籍 | 作用 | 类型 |
|---|---|---|
| Fowler, Refactoring（第 2 版） | Refactoring 奠基文本 | 深入 |
| Feathers, Working Effectively with Legacy Code | Legacy code 改善 | 深入 |
| Refactoring-loop reference: Beck, Test-Driven Development: By Example | Red-green-refactor 纪律 | 深入 |
| McConnell, Code Complete（第 2 版） | Construction quality 基础 | 深入 |
| Richardson, Microservices Patterns | Monolith decomposition patterns | 深入 |
| Tornhill, Software Design X-Rays | Behavioral code analysis 与 hotspot-based debt management | 深入 |
课程、论文与当前资料
阅读 Cunningham 的 WyCash 报告，理解债务比喻的原始情境；用 Fowler 的四象限 区分意图与判断。重构目录 提供具名变换。讨论替换方案时，应结合熟悉系统的数据、兼容性和过渡成本。
| 资源 | 平台 | 类型 |
|---|---|---|
| Cunningham, c2.com technical debt pages（免费） | c2.com | 深入 |
| Fowler, “Technical Debt Quadrant”（免费） | martinfowler.com | 参考 |
| Fowler, “Strangler Fig Application”（免费） | martinfowler.com | 参考 |
| Spolsky, “Things You Should Never Do”（免费） | joelonsoftware.com | 深入 |
| Fowler，在线重构目录 | refactoring.com/catalog | 参考 |
实践、工具与当前资料
从版本历史、缺陷记录和一次真实修改任务开始。静态分析工具可以帮助寻找复杂结构或重复；自动改写工具与 IDE 可以执行选定变换。需要检查工具假设及修改后的行为。依赖更新自动化提供的是变更提案，不能证明每次升级都兼容。
| 资源 | 平台 | 类型 |
|---|---|---|
| SonarQube Community Build | docs.sonarsource.com | 实践 |
| Git 历史与问题记录 | 本地仓库与项目跟踪工具 | 实践 |
| CodeScene（商业；free trial/options may vary） | codescene.io | 实践 |
| OpenRewrite（免费；Moderne platform 付费） | openrewrite.org / GitHub | 实践 |
| Renovate（开源；hosted options 可能付费） | docs.renovatebot.com | 实践 |
| refactoring.guru（免费） | refactoring.guru | 参考 |
| IDE refactoring tools（内置） | IntelliJ / VS Code / Eclipse | 实践 |
陷阱
| 误区 | 为什么会误导 | 更好的做法 |
|---|---|---|
| 把所有不喜欢的设计都叫债务 | 名称没有说明未来成本或更好的可行方案。 | 描述重复出现的困难及其成本证据。 |
| 认为所有债务都必须偿还 | 剩余寿命与未来工作量可能使修复不划算。 | 在明确时间范围内比较方案，并纳入运行风险。 |
| 把测试当成重构安全的证明 | 测试只观察选定情况，还可能保留错误预期。 | 小步修改，结合相关检查与语义审查。 |
| 用删行数或复杂度分数衡量改进 | 更短的表示可能隐藏困难，而不是消除困难。 | 检查预期修改与恢复是否真的更容易。 |
| 只按新实现工作估计重写 | 行为覆盖、数据迁移、并行运行与退出成本可能占大头。 | 同时规划和验证过渡过程与目标设计。 |