你必须确定发布日期。您需要更多时间来正确构建模块的结构，但您没有。赶上发布日期比清理代码更重要，因此您推迟清理以赶上截止日期。您同意承担技术债务，您以后必须偿还这些债务。现在加快发布日期将使您更慢地发布下一个发布日期。如果你不小心，随着时间的推移，开发速度会变得缓慢，每个功能都需要数周而不是数天。
为了避免开发僵局，我们需要充分理解技术债务。否则，我们会毁掉我们的软件。关于技术债务管理的一些问题是：
- 技术债务到底是什么（什么不是）？
- 技术债从何而来？
- 什么时候可以创造技术债务？
- 技术债务如何损害发展？
- 技术债务管理：我如何衡量技术债务？
- 我怎样才能减少技术债务？
- 我怎样才能避免技术债务？
技术债务到底是什么（什么不是）？
根据 ward Cunningham 的说法，技术债务 描述了 延迟的、必要的工作 ：
技术债务包括那些你现在选择不做，但如果不做就会阻碍未来发展的内部事情。这包括延迟重构。
技术债务不包括延期功能，除非可能在边缘情况下交付的功能对客户来说“足够好”，但不满足某些标准（例如，不完全符合某些 ui 标准的 ui 元素） .
进一步描述 技术债务，福勒 写道 ：
您有一项功能需要添加到您的系统中。你看到了两种方法，一种是快速但很混乱——你确信它会让未来的进一步改变变得更加困难。另一个导致更简洁的设计，但需要更长的时间才能到位。
鲍勃叔叔提醒我们 ，一团糟不是技术债务：
一团糟不是技术债务。一团糟就是一团糟。技术债务决策是根据实际项目约束做出的。它们是有风险的，但它们可能是有益的。把事情弄得一团糟的决定从来都不是理性的，总是基于懒惰和不专业，而且在未来没有任何回报的机会。一团糟总是一种损失。
如果您的代码很乱，那它总是不好的——如果您推迟必要的工作，这可能是一个明智的商业决策。不幸的是，随着时间的推移，制造混乱和承担技术债务都会导致类似的问题。
让我们看一些例子，看看什么 是 技术债务，什么不是。
在代码中招致技术债务的一个典型例子是每个开发人员都害怕接触的巨大源文件。团队中的每个人都知道它需要被分解成更易于管理的部分，但这会使即将推出的功能至少延迟两周。在不重构的情况下接触这个模块会增加你产品的技术债务。每一次这样的改变都会使最终的重构变得更加困难，因此需要在以后偿还——连同利息。您必须支付的利息是您添加的每个更改所增加的复杂性。该模块随着每次添加代码而增长，这使得它的重构（甚至是重构的决定）变得更加困难。
运营方面的技术债务的一个例子是，即使您对正常运行时间有苛刻的要求，也只能在数据中心的一个可用区中部署您的应用程序。设置一个覆盖多个可用性区域的拆分环境需要更多的工作。可能有必要推迟这项额外的工作，以便能够向您的客户提供关键功能。在这种情况下，技术债务不会增加复杂性，但会增加停机风险。为了立即避免必要的工作，您引入了单点故障，这最终会降低您的正常运行时间。
那么，什么不是技术债务？
不必要的复杂性、肮脏的黑客攻击和不可读的代码 都不是 技术债务。首先没有充分的理由引入这样的混乱。如果开发人员觉得他们没有时间编写简单、可维护的代码，那么他们显然缺乏经验和专业精神。
“单脑技术”是另一种经常被描述为技术债务的现象。但是依赖一个人来维护或运行应用程序的关键部分并不是技术债务——它是对您的业务的致命威胁。你可能会争辩说，因为那个人需要交付关键特性而不分享技术诀窍是技术债务，但我不同意。如果没有第二双眼睛仔细检查，任何一行代码都不应上线。结对编程或代码审查之类的事情是很好的专业实践，不应该为了更高的交付速度而交换。
读到这里，您现在应该清楚了解什么 是 技术债务，什么 不是 。我们将在以后的文章中讨论其他问题。