错误是技术债务的一部分吗？

我们的Scrum Master一直将错误称为技术债务。他说得对吗，在敏捷世界中，虫子被视为技术债吗？

我认为这里的答案很简单-技术债务的关键特征是它是我们选择产生的。

我们选择做出我们期望会在以后引起问题的架构，设计或实施决策，以便更快地实现特定目标。

错误不是我们选择在代码中包含的东西-因此，事实上不包含技术债务。

当然，对于发现后做出的选择，人们可以提出各种有趣的（可能是有效的）论点，但是从根本上（尤其是在问题的上下文中）不，错误不是技术上的负担-听起来更像是对流行语宾果游戏的滥用。

作为后记-我不同意这样的说法，即技术债务将导致自身错误，因为这对选择的性质做出了许多假设。例如，您可以编写出结构良好，结构良好，经过测试的代码，这些代码仍然会（例如）在架构方面做出妥协，以实现早期交付。同样，您可以选择不自动执行您的部署过程，这不会导致错误，但可能会导致很多压力和痛苦。当然，如果所欠的债项是您编写的代码不是SOLID（或其他），则可以……但是，绝非总是如此。

是。

技术债务（也称为设计债务或代码债务）是一种神经病的隐喻，是指代码库中软件体系结构和软件开发不佳或不断发展的最终结果。

资料来源：维基百科

通过更好的工作流程（例如，在跳转到编码之前进行正确的体系结构设计，执行TDD等），更好的编码实践等可以避免的技术债务。

通过进行额外的审查或使用更正式的方法，可以避免大多数错误。通过尽一切努力避免一开始就没有错误，可以降低项目的短期/短期成本，但会增加技术负担。

阅读了BЈовић的答案后，我发现它可能不像我想的那么容易。

• 例如，错误是技术债务的一部分吗？文章声称，只有您知道但没有解决的错误才属于技术债务的一部分。

• 另一个例子，克里斯托弗（Christopher）的“技术债务思想”将缺陷归结为技术债务的结果，而不是技术债务的一部分。话虽这么说，但许多列出的结果（例如“实现新功能的成本”）都受到错误数量的影响。

• 最后，在创建技术债务的ABCDE-T模型时，我将错误作为六个因素之一，但对它们的考虑却有所不同。重点不是错误本身，而是错误的收集，优先级和解决方法。错误本身是由于技术债务而出现的（就像前面的示例一样），但从来没有将它们本身视为技术债务的因素。

话虽如此，我仍然倾向于回答错误-任何错误-是技术债务的一部分。

第一个论点：

阅读Jeff Atwood的报价，大多数错误的资格如下：

快速而肮脏的设计选择，使我们在未来的开发中需要付出额外的努力

在业务应用程序中，几乎每个错误都来自快速而肮脏的设计选择或错误的做法（可能是缺乏测试，开发人员对技术的了解不足，缺乏沟通，对领域缺乏了解，等等），这意味着“通过将快速，肮脏的设计重构为更好的设计”并采用更好的实践，企业可以解决大多数错误。

第二个论点：

如果我们将公司出售给另一公司时要考虑的重要普通债务与技术债务（将项目出售给另一公司或给定给某公司的考虑在内）同样重要，对于另一个团队，我们很容易看到错误是技术负担的一部分，因为新团队将：

• 在开发新功能之前，要么必须处理这些错误（Joel Test的第5点：您是否在编写新代码之前修复了错误？）

• 或者保留漏洞，以这种方式保存/增加技术债务。

杰夫·阿特伍德（Jeff Atwood）在他的文章《偿还技术债务》中对什么是技术债务给出了很好的答案：

技术债务会产生利息支出，这是由于快速而肮脏的设计选择，我们在未来的开发中必须付出额外的努力。我们可以选择继续支付利息，也可以通过将快速而肮脏的设计重构为更好的设计来偿还本金。尽管偿还本金需要付出成本，但未来我们会减少利息支出，从而获得收益。

严格地说，如果错误不会减慢软件开发的速度（更改功能，添加新功能等），则它们不属于技术负担。它们是软件缺陷。

但是，如果修复错误的成本太高，或者迫使您解决它（并引入更多的技术债务），那么它将成为技术债务的一部分。

错误不是技术债务。技术债务正在追求质量，而不是缺乏质量。首先，软件不应该包含错误。您知道，整个工作软件都超过了综合文档。

技术债务的最大违法者是“临时错误修复”，您知道要通过测试并接受故事的人，您曾承诺自己会在以后重构，但以后再也不会重构。随着这些临时修复程序，补丁程序和其他内容的累积，代码变得不必要地混乱，难以更新和测试，并且通常是一场噩梦，但它仍然可以正常工作。

为了支持这种观点，我直接去了沃德·坎宁安（Ward Cunningham）。关于这一点，沃德前不久与Capers Jones进行了很好的访谈，值得一看。

与Ward Cunningham＆Capers Jones进行的技术债务辩论

另一本值得一读的文章是马丁·福勒（Martin Fowler）

马丁·福勒（Martin Fowler）谈技术债务

在Martin的文章中，请找到指向OOPSLA92的Ward Cunningham最初提到的技术债务的链接：

WyCash投资组合管理系统

以上文章的引文：

尽管不成熟的代码可以很好地工作并完全为客户所接受，但是过多的代码将使程序无法控制，从而导致程序员的专业化程度极高，最终导致产品不够灵活。交付第一次代码就像陷入债务。

最后，技术债务可能已经包含一些人的错误，我想这很好。我只是不认为这是初衷。

严格来说，您的问题的答案是“否”。

技术债务可能（并且可能会）导致错误，但是断定任何错误都是技术债务的结果，这可以在两个事实之间进行解释：存在错误并且存在技术债务（假定可以得出结论）。

如果您的Scrum Master“作为理论”指出错误是技术债务的结果，那么他在偷工减料。如果他对不断出现的特定错误说这话，那可能是对的-我们从这里看不到代码质量;-)

他可能还会不断抱怨人们没有听他讲技术债，因此将每个错误都标记为技术债，但现在我正在猜测。

在我看来，您是否认为错误是技术债务的一部分...还是没有关系。

显而易见的事实是，现有的错误代表着将来可能需要执行的额外工作，以进行修复或解决。

技术债务（通常使用标签）也代表将来可能需要执行的额外工作……一种或另一种方式。

因此，无论您说已知（或未知）错误是技术债务，还是不是技术债务，实际上只是定义的问题。而且，由于没有关于“技术债务”的权威性定义¹，因此整个讨论都是毫无意义的。

正如刘易斯·卡洛尔（Lewis Carroll）写道：

“当我使用一个词时，”矮胖子用一种轻蔑的语气说，“它的意思就是我所选择的意思-既不多也少。” 。

这实际上就是自然语言的工作方式。话是人们所认为的意思。词典定义等仅记录了单词的使用方式，而不一定是准确的记录。如果您的Scrum Master希望将已知的bug称为技术债务，那么谁又说他是“错误的”呢？

^{1-引用Ward Cummingham和Caper Jones之类的人也无济于事。充其量可以告诉我们他们使用（使用）该短语时的意思（或意思）。他们没有“拥有”这句话。尽管他们无疑是这些问题的权威，但这仍然只是他们的意见。}