技术债务不存在

在经历了几十年的软件工程之后，我得出了专业的结论，即技术债务是不存在的。

哦，我见过无数次在技术债务的幌子下重写软件，这并不意味着有技术债务，除非“技术债务”被定义为“任何现有的代码”。

软件的独特之处在于，它的下一个继承人将无情地重写(#重构)编写的所有内容。

它非常明显，而且一开始你的第一个项目，每个加入现有代码库的实习生和年轻毕业生都会立即感觉到重写它的冲动。这是业界的必经之路，宣称现有的是狗屎，唯一合理的做法就是重写它！代号为“技术债务”。

这是字面意思。读取现有代码是困难的-比编写代码更困难-因此，开发人员真正了解到，丢弃一切从头开始比继续现有代码“更容易”。[因此，这对于非小型项目是有缺陷的，因为在开发商的任期内，新的开发项目永远不会赶上现有的项目。]。

人们如何看待软件有一个类比，那就是矿井。每一行代码都在深入挖掘。

最终，软件开发人员回过头来看这个项目时，只会对他(为自己)挖的大坑感到恐惧。

那他就会辞职逃离这个地狱之洞…。只是开始在附近挖一个新的，很快就会变得一样的。

越大越好。虽然规模本身不是目标，但它与活动是分不开的。你可以回顾一下，估算一下到目前为止已经完成了多少工作。

如果它是一个金字塔项目，你肯定不会认为它太大了，只是觉得它很了不起。作为参考，构建Microsoft Windows7比构建大金字塔需要更多的工作。

矿业了解它的意义所在。这项工作的很大一部分是理所当然地维持矿井的运营条件-维护和扩大基础-以便开采更多的矿物，并从更深的地方开采。

世界瞬息万变，可能有很多维护工作要做。是真的。

Python3改变了所有字符串的处理方式，必须做出调整。建造太慢了，应该会让它更快。在一个库中发现安全漏洞，是时候更新库了。用户已经转向使用手机而不是台式机，应该调整网站以使其具有可读性。发送到Gmail地址的电子邮件将是垃圾邮件，请注意这一点。

这是一个永远的维护流，来自环境、客户和构建软件的每个组件。有无休止的调整要做。我以前写过关于软件生命周期或产品最终被关闭的原因的文章。

没有技术债务这回事。有工作要做，我们可以达成一致，但这不是偿还债务。

如果构建不起作用，并且软件没有经过很好的测试(…)，该怎么办？

那么让软件在现在的GCC上编译，加上测试也算是维护。就开发周期而言，这是一件非常正常的事情。绝对不是技术性债务的情况。

事实上，当源代码(以及项目周围的一切)丢失时，维护软件可能是一件具有挑战性的事情。这听起来更像是丢失了，或者根本就没有做过，而不是技术债务。绝对与债务无关。[半开玩笑地说，债务意味着被给予并必须偿还，如果你从未拥有过任何东西，你就很难负债：d]。

这是现实世界的必然结果。确实有一些项目的源代码从一开始就没有存储，没有文档，没有构建脚本，什么都没有。你要找的词是“一次性项目”，因为它本来是要扔掉的(在合同中很常见)。只有一件事，不要把矛头指向你的前任，这需要各方共同努力，公司既不关心收集任何可交付成果或进行源代码控制，也不关心开发人员提交任何工作或设置源代码控制。

再打个比方，8万公里后，当你把车开到修理工那里更换刹车时，他不会继续警告说，之前的修理工已经到处都是欠债的刹车垫，并质疑此人的资格。这真的是定期维护。[然而，如果没有刹车，机械师可能会问为什么没有刹车，并希望你没有全额支付汽车的费用-汽车显然是不完整和不起作用的？-，那仍然是维护，不管怎么说，必须(重新)做刹车。]