大多数技术债务都是胡说八道
我对一位朋友随口说了一句关于技术债务的话，他打断了我的话，说：技术债务简直是胡说八道。根据他的经验，谈论技术债务的人大多试图：
将这些问题称为技术债务似乎是与这些问题保持距离的一种策略。这是逃避责任的好办法。把事情隐藏起来。
出于好奇，我决定更深入地研究一下技术债务的比喻，以便更好地理解其实际含义。
我立刻意识到自己对技术债务的理解是错误的。大多数人似乎将技术债务理解为：
现在就走捷径，捕捉短期商业价值(承担债务)，然后再清理(偿还债务)。
你知道，如果你想通过开发你不完全理解的软件来借此负债，你最好让那个软件尽可能地反映你的理解，这样当真的到了重构的时候，你写它的时候就会很清楚你在想什么，这样你就更容易把它重构成你现在的想法了，这是明智之举，因为这样你就可以更容易地把它重构成你现在的想法了，这样当你真的要重构的时候，你就可以清楚地知道你写它的时候在想什么，这样就更容易把它重构成你现在的想法了。
在某种意义上，这在我看来是原型的一种形式。尝试并测试设计/体系结构，看看它是否适合手头的问题空间。但它也包含了将来花费额外时间更改代码的意愿，以更好地反映当前对手头问题的理解。
..。如果我们不能使我们的计划与我们当时理解的思考财务对象的正确方式保持一致，那么我们就会不断地因这种分歧而跌跌撞撞，这将减缓我们的速度，就像支付贷款利息一样。
设计/体系结构和问题域的不一致造成了瓶颈，从而减慢了未来的开发。
这更多的是对未来的持续再投资。它可能会暂时停止特性工作，但从长远来看，它应该会带来更多的功能和特性。在我看来，这根本不是短期关注的问题。而且，您需要编写干净的代码并尽最大努力，因为您很可能需要重写其中的一部分。
在研读这个话题时，我注意到一件非常奇怪的事情。不知何故，所有阻碍软件开发的东西都变成了技术债务。
任何造成瓶颈的东西，都会突然被放入技术债务的篮子里。我开始有一种强烈的感觉，很多人不知何故在制造逻辑谬误。
如果你有技术债务，当你试图忽略它而只是继续前进时，你会遇到摩擦。技术债务造成了一个瓶颈。
但是，人们的推理是错误的：我注意到我的软件开发过程中存在一个瓶颈，所以我们有了技术债务。
然而，因为技术债务造成了瓶颈，它并不能由此得出每一个瓶颈都是技术债务的结论。
也许我在制造一个稻草人的论点，但我想我有一些例子表明，人们的想法是错误的。
如果我们看一下维基百科关于技术债务的页面，就会发现有一长串可能导致技术债务的原因。
请注意，这些问题之所以被称为技术债务，是因为它们可能会产生与技术债务类似的结果。它们可能会造成瓶颈。
这些问题不言而喻。称它们为技术债务不仅看起来不合适，而且只是混淆了这些问题的原因，也没有提供任何新的见解。即使在与外行的谈话中也是如此。
鲍勃叔叔的一篇同名博文也触及了这个问题，称许多问题被错误地贴上了技术债务的标签。
不幸的是，还有另一种情况，有时被称为“技术债务”，但这既不合理，也不明智。一团糟。
一团糟不是技术债务。一团糟就是一团糟。技术债务决策是基于真实的项目约束做出的。它们是有风险的，但也可能是有益的。搞得一团糟的决定从来都不是理性的，总是建立在懒惰和不专业的基础上，将来也没有机会付出代价。一团糟永远是一种损失。
坎宁安对技术债务的定义表明，这是一个非常有意识和深思熟虑的过程。制造混乱是不对的，称其为技术债务是完全不合适的。这里简直一团糟。
我认为这与维基百科早先的名单有很好的联系。只要说出事情的真实面目就行了。
在这篇博文中，Martin Fowler谈到了Bob叔叔的博文，并认为技术债务作为一种隐喻在与非技术人员交流时(仍然)非常有价值。
这个象限让我非常怀疑。因为在这个象限里，一切都是技术债务。他只是发明了不同口味的技术债务。它永远不会不是技术性债务。它的技术债务一路下降。
在我看来，马丁·福勒(Martin Fowler)将技术债务的比喻扭曲为永远不能伪造的东西，就像精神分析一样。
它不是错误的代码，不是设计缺陷，也不是一团糟，而是疏忽不计后果的技术债务。什么更能描述这个问题？
也许这只是我缺乏理解，但我看不出为什么把每一种瓶颈都称为技术债务有任何帮助。我再一次看不到这如何传达任何意义。
最后，Fowler所做的仅仅是指出软件开发中的瓶颈可能是由于能力的四个阶段造成的。
高频交易专家甚至辩称，技术债务并不真正存在，它不是真实的概念。
在经历了几十年的软件工程之后，我得出了专业的结论，即技术债务是不存在的。
他的论点归结为人们所说的技术债务实际上主要是维修。
因此，将对手头问题的更好理解重新结合到代码(设计)中被视为软件开发不可或缺的自然部分，这可以用挖掘的替代比喻来说明(在挖掘和加强之间交替进行)。至少我是这么理解的。
用一个比喻替换另一个比喻，这到底有多大用处呢？但在这种情况下，它至少不那么通用，更精确。
尽管坎宁安的本意是好的，但我认为技术债务的比喻开始有了自己的生命力。在某种程度上，不符合柏拉图理想的代码被称为技术债务4。
每一个错误、每一个不断变化的需求、每一个成为开发过程瓶颈的权衡都被贴上了技术债务的标签。我不认为这是有建设性的。
我认为我的朋友是对的：技术债务的概念已经变成了废话。它没有传达任何更好的洞察力或意思。相反，它似乎混淆了瓶颈的真正原因。
在这一点上，当人们谈论技术债务时，我会非常怀疑，并希望获得更多细节。技术债务实际上并不能解释我们为什么会有今天的成就。它已经变成了一种空洞的、手舞足蹈的解释。
恕我直言，由于坎宁安这个概念被广泛误解和滥用，最好是让它退休。
如果你不是在开发一项新功能，那么你就是在开发技术债务。--↩。
我认为鲍勃大叔在这篇文章中对技术债务的定义是不正确的。他还将其定义为为了短期利益而偷工减料。--↩
