Technical debt (技术负债 / 技术债)

Technical debt (技术负债 / 技术债)

In software development, or any other IT field (e.g., Infrastructure, Networking, etc.) technical debt (also known as design debt or code debt) is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.
在程序设计及软件工程中，技术负债 / 技术债 / 设计负债 / 代码负债是指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，虽然眼前看起来可以得到好处，但在未来必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

1. Introduction

Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

1992 年，Ward Cunningham 首次对技术复杂性和债务进行了比较：
交付第一次代码就像欠债一样。只要通过重写及时偿还，一点点债务会加速开发。当债务没有偿还时，危险就会发生。在不完全正确的代码上花费的每一分钟都算作该债务的利息。整个工程组织可能会因为未整合的实施 (无论是面向对象的实施还是其他实施) 的债务负担而陷入停滞状态。

In his 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as “design debt”.
Joshua Kerievsky 在其 2004 年的文章 Refactoring to Patterns 中提出了一个类似的论点，涉及与架构疏忽相关的成本，他将其描述为设计债务。

Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn’t shared around the organization and code that is too confusing to be modified easily.
可能被推迟的活动包括文档、编写测试、关注 TODO 注释以及处理编译器和静态代码分析警告。技术债务的其他实例包括组织内未共享的知识以及过于混乱而难以轻松修改的代码。

In open source software, postponing sending local changes to the upstream project is a form of technical debt.
在开源软件中，推迟向上游项目发送本地更改是一种技术债务。

2. Causes

band-aid：n. 急救带，急救绷带 adj. 急忙拼凑的

Common causes of technical debt include:

• Ongoing development, long series of project enhancements over time renders old solutions sub-optimal.
  Insufficient up-front definition, where requirements are still being defined during development, development starts before any design takes place. This is done to save time but often has to be reworked later.
  不充足的事前定义，在开发过程中仍在定义需求，开发在任何设计发生之前就开始了。这样做是为了节省时间，但通常需要稍后返工。
• Business pressures, where the business considers getting something released sooner before the necessary changes are complete, builds up technical debt involving those uncompleted changes.
  业务压力，即企业考虑在必要的更改完成之前尽早发布某些内容，会积累涉及那些未完成的更改的技术债务。
• Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.
  缺少流程或理解，从而商务上对技术债务不了解，不考虑后果就做出决策。
• Tightly coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.
  组件紧密耦合，功能不是模块化的，软件不够灵活，无法适应业务需求的变化。
• Lack of a test suite, which encourages quick and risky band-aid bug fixes.
  缺乏测试套件，这刺激了快速高风险凑活式的修复 bug。
• Lack of software documentation, where code is created without supporting documentation.
  缺少文档，写代码但没有必要的支撑性文档。
• Lack of collaboration, where knowledge isn’t shared around the organization and business efficiency suffers, or junior developers are not properly mentored.
  缺乏合作。知识没有得到共享，对新手缺乏监督辅导。
• Parallel development on multiple branches accrues technical debt because of the work required to merge the changes into a single source base. The more changes done in isolation, the more debt.
  在两个或多个分支上平行开发而累积了技术债务。由于工作最终需要合并两个分支的代码，拖延越晚，需要工作代价越大。
• Deferred refactoring; As the requirements for a project evolve, it may become clear that parts of the code have become inefficient or difficult to edit and must be refactored in order to support future requirements. The longer refactoring is delayed, and the more code is added, the bigger the debt.
  推迟重构。随着项目需求的发展，可能会发现部分代码变得效率低下或难以编辑，必须进行重构才能支持未来的需求。重构拖延的时间越长，添加的代码越多，债务就越大。
• Lack of alignment to standards, where industry standard features, frameworks, and technologies are ignored. Eventually integration with standards will come and doing so sooner will cost less (similar to “delayed refactoring”).
  缺乏与标准的一致性，行业标准功能、框架和技术被忽视。最终与标准的集成将会到来，而且越早这样做成本就会更低 (类似于延迟重构)。
• Lack of knowledge, when the developer doesn’t know how to write elegant code.
  缺少知识，开发者并不知道如何写精致的代码。
• Lack of ownership, when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.
  缺少所有权，外包的软件最终要让自己的工程师去重构或重写源代码。
• Poor technological leadership, where poorly thought out commands are handed down the chain of command.
  技术领导力差，未深思熟虑的命令传达下来，增加了技术债务，而不是减少它。
• Last minute specification changes. These have potential to percolate throughout a project, but there is insufficient time or budget to document and test the changes.
  最后一分钟规范变更。这些有可能渗透到整个项目中，但没有足够的时间或预算来记录和测试这些更改。

Kenny Rubin uses the following status categories:

• Happened-upon technical debt - debt that the development team was unaware existed until it was exposed during the normal course of performing work on the product.
  发生的技术债务 - 开发团队不知道债务的存在，直到在产品的正常工作过程中暴露出来。
• Known technical debt - debt that is known to the development team and has been made visible using one of many approaches.
  已知技术债务 - 开发团队已知的债务，并且已使用多种方法之一使其可见。
• Targeted technical debt - debt that is known and has been targeted for servicing by the development team.
  有针对性的技术债务 - 已知的债务，并且已成为开发团队要偿还的债务。

3. Technical debt quadrant

技术债务的四象限分类：

References

https://yongqiang.blog.csdn.net/
https://en.wikipedia.org/wiki/Technical_debt
Technical Debt Quadrant，https://martinfowler.com/bliki/TechnicalDebtQuadrant.html