软件开发项目中一个常见的争论是，是花时间提高软件质量，还是专注于发布更有价值的功能。通常，交付功能的压力主导着讨论，导致许多开发人员抱怨他们没有时间处理架构和代码质量。这种争论是基于一个假设，即提高质量也会增加成本，这是我们的共同经验。但与直觉相反的现实是，内部软件质量消除了减缓新功能开发的障碍，从而降低了增强软件的成本。

代码异味是一种表面迹象，通常对应于系统中更深层次的问题。这个词最初是由 Kent Beck 在帮我写 重构 这本书时创造的。

在每个正常规模的团队中，将任何一类技术的备选方案限制为三种。它们是：当前合理的默认方案、我们正在试验的方案，以及我们讨厌并希望淘汰的方案。

在设计耐力假说中，设计收益线是指在该功能量以下，可以用设计质量换取上市时间。

精心设计软件值得付出努力吗？

（这是对你的词典的补充。）

不可测试（形容词）：不可测试的软件。

技术债务是一个非常有用的概念，但它提出了一个问题，即如何衡量它？遗憾的是，技术债务不像金融债务，因此很难说你欠了多少债务（尽管我们最近似乎在衡量金融债务方面遇到了一些麻烦）。

软件系统容易积累障碍——内部质量的缺陷，使得修改和扩展系统变得比理想情况下更加困难。技术债务是由 Ward Cunningham 创造的一个比喻，它构建了如何处理这种障碍的思路，将其视为一种金融债务。添加新功能所需的额外努力就是偿还债务的利息。

在过去的几个月里，有一些关于技术债务的帖子提出了一个问题，即哪些类型的设计缺陷应该或不应该被归类为技术债务。