显然确实存在技术债务

这可能取决于很多上下文，是技术债务，使用旧技术时你会遇到很多这样的情况： https://stackoverflow.com/questions/9318895/how-to-integrate... 当然，这个问题有一个答案，它有点繁琐，但不算太糟，这样做30次后，你就会有一个难以维护的灾难。 曾经流行过的技术也是一个危险信号，随着时间的推移，会越来越难招聘到人。资源和文档也会逐渐消失。

这是一个很好的例子。我见过（可能也做过）一些重构的PR，有人将旧系统拆分成新的概念模块。代码审查者进来后，发现新代码比之前的代码更难理解。当然，审查者之前已经了解旧代码，所以新代码对他们来说更难理解是很自然的事。

> 另外6：技术债务是另一种说法，即“我个人无法理解的代码”，或者“以不同于我写的方式编写的软件”。 有时候，对于很久以前由不再任职的人编写的代码，我更快地通过重新编写这部分代码，以我理解的方式，然后实现所需更改，而不是试图理解代码并以符合其方式实现更改。

显然，在重构、重写和新开发、维护以及长期支持之间存在脱节。 开发者们经常急于转向下一个新事物，但几年后他们是否会被追究责任？ 他们经常提出那些困难而无聊的“如果……会怎样”的问题吗？ 在这些决策中，同理心起到了多大的作用？

我认为我无法理解的代码确实是技术债务。不确定你这句话想表达什么，但听起来你似乎不同意这个说法。没人知道的未文档化的代码是一个严重的技术债务问题。应该花时间去阅读、理解并记录下来。

当框架A被构建和维护时，因此存在已知的未修补的安全缺陷，那么迁移到其他框架是关键的技术债务，需要优先处理。 在我的组织中，框架实际上是技术债务问题的最大来源。 例如：多年前有人选择了Angular 1.x，迁移至2+被视作“几乎是一次全面重写”而被推迟，因此现在我们必须重写为React或者其他当下的流行框架。Java、.NET和其他后端框架也发生了同样的情况。