技术债务（Technical Debt）

什么是技术债h2>

技术债务（也称为技术债务或代码债务）描述了当开发团队采取行动加快交付某个功能或稍后需要重构的项目时的结果。换句话说，这是将快速交付优先于完美代码的结果。

如果您在软件行业工作过一段时间，那么您很可能听说过“技术债务”这个词。也称为设计债务或代码债务，这个短语（或更准确地说，比喻）广泛用于技术领域。它被称为包罗万象的包罗万象，从错误到遗留代码，再到缺少的文档。但究竟什么是技术债务么我们这样称呼它p>

他当时并没有意识到，但他在软件界创造了一个新的流行词。后来，它成为无数学术研究、辩论和小组讨论的主题。

多年后，Cunningham 描述了他最初是如何提出技术债务隐喻的：

“有了借来的钱，您可以比其他方式更快地做某事，但在您还清这笔钱之前，您将支付利息。我认为借钱是个好主意，我认为将软件赶出门来获得一些经验是个好主意，但是当然，您最终会回去，并且当您了解有关该软件的知识时，您会偿还通过重构程序来反映你获得它时的经验。”

想要 了解更多可观看下面原文、视频：

根据软件工程研究所发表的论文“走向技术债务术语本体论”，有 13 种不同类型的技术债务和一组关键指标。

• 建筑债务
• 建立债务
• 代码债务
• 缺陷债
• 设计债务
• 文件债务
• 基础设施债务
• 人债
• 处理债务
• 需求债务
• 服务债务
• 测试自动化债务
• 测试债务

技术债务不好吗h2>

如果您想要一个简单的答案：技术债务既不好也不坏，它就是债务。就像金融债务一样，关于技术债务是好事还是坏事，有几种思想流派。因此，我们将在这里讨论一些不同的观点，而不是寻找一个客观的答案。

当今大多数软件公司都面临着来自市场和竞争力的压力，需要快速开发和发布。初创公司尤其感受到这种“船或沉”的压力。这种对速度的需求导致许多产品和软件开发团队在承担技术债务或稍后发布之间做出权衡。

这就是为什么大多数敏捷团队的普遍共识是技术债务本质上并不是坏事。事实上，大多数（如果不是全部）软件产品都有一定程度的技术债务。当您考虑团队每天发布多少代码时（尤其是在敏捷环境中，工作软件是进度的主要衡量标准），这并不奇怪。

另一方面，许多严格按照 Waterfall 软件开发方法和其他文档驱动框架工作的软件开发团队并不认同这种观点。

正如史蒂夫·麦康奈尔（Steve McConnell）所指出的，对技术债务的态度不仅因公司理念而异，而且因部门和角色而异。

“我发现，与技术人员相比，业务人员对技术债务的容忍度通常更高。业务主管倾向于了解所涉及的权衡，而一些技术人员似乎认为唯一正确的技术债务数量是零。” 麦康奈尔写道，他解释说，他将这种厌恶归因于技术债务，因为这将不可避免地产生沟通挑战。

他说，技术人员通常的任务是向业务人员解释技术债务，他们可能不会立即看到其中的含义。“主要问题似乎是，与金融债务不同，技术债务不太明显，因此人们更容易忽视它，”他建议道。

所以这里的要点是，在确定技术债务是好是坏时，背景很重要。一般来说，您可以像处理金融债务一样考虑技术债务：直到出现问题才成问题。

原文连接：https://www.productplan.com/glossary/technical-debt/