技术债务是一种自然现象，看到它的出现可能表明人们正在发现您的软件有用

每个工程经理和CTO都会想到技术债务。通过快速而肮脏的方式从未来“借”时间可能会在以后引起巨大的问题。我们采访了Liran Haimovitch，讨论了什么是技术债务，如何将其与传统代码区分开来等等。

JAXenter：“技术债务是一个浪漫的隐喻，用来掩盖开发人员的愚蠢行为。” 您是否同意这个想法？

Liran Haimovitch：我的想法是这样的：技术债务是真实的事情，并且可能由错误的设计决策或匆忙的开发引起。真正的技术债务是我们应该设法减少的东西。但是，我们所谓的技术债务很多根本不是技术债务。这只是我们开发人员不了解的东西。

问题在于，当开发人员或团队不想做某事或不知道如何使用现有的旧代码执行操作时，“技术债务”已成为最终的借口。遗留代码与技术债务不同。传统代码可以快速，稳定且安静地运行数年，即使编写它的开发人员已经离开很久了。好的代码并不会因为没有人理解而成为真正的技术债务。随着软件组织的成熟，他们不仅需要应对真实的技术债务，而且还需要保持对代码的理解，以避免这种虚假的技术债务。

JAXenter：为什么技术债务对DevOps如此重要？

Liran Haimovitch： DevOps最终将致力于以快速且可持续的速度提供高质量的软件。承担技术债务有点像借贷：从未来的自我中借钱可以帮助您更快地交付软件，但它并不总是可持续的。如果您借入的贷款利率过高而又没有迅速偿还债务，则还款可能会失控。

但是，将一段复杂的代码称为“技术债务”有时可以成为避免理解他人工作的借口。一些开发人员宁愿花时间和精力来重建从头开始起作用的东西，以“消除技术债务”，而不是学习现有代码的工作原理。

这可能是一个问题，尤其是在公司中，开发人员的绩效是根据他们编写的新代码的多少来衡量的。对旧的现有代码进行试验很难衡量或向管理人员证明。由研发负责人证明，理解现有代码库具有价值，而替换现有代码库并非总是正确的选择。

贾克森特（JAXenter）： 有人争论说技术债务也可以帮助项目。您对此有何看法？

Liran Haimovitch：科技债务本身并没有帮助，但它的存在可以证明您做对了事。

技术债务是一种自然现象，看到它的出现可能表明人们正在发现您的软件有用。毕竟，如果不使用某些东西，那就没有任何债务了。仅当您要添加功能或改进功能时，技术债务才变得重要。

假冒技术债务也是产品和公司日趋成熟的积极信号。随着功能性代码进入第二个十年，我们不应该感到惊讶，原始的开发者已经走了很长时间，而当前的一代却很难理解古代人的智慧。同样，这应该与真正的技术债务区分开

贾克森特（JAXenter）： 您有什么要做的事情要分享？如何补救技术债务问题或将其用于我们的利益？

丽兰·海莫维奇（Liran Haimovitch）：首先，学会区分真正的技术债务和您根本不了解的东西。如果项目使用的框架已过时，随着时间的推移变得越来越难以维护，或者项目速度缓慢或占用大量内存，那么这些都是您正在处理实际技术债务的一些线索。通常，这些系统需要持续的维护和TLC，因此开发人员实际上非常了解它们。

另一方面，如果一段代码悄悄有效地完成了工作，那么它*可能*不是技术债务。也许没人知道它是如何工作的，因为距它需要任何修复已经有十年了！当您确实需要进行更改时，可能会更难，但这不是原始开发人员的错。补救这种虚假的技术债务的关键是让开发人员了解代码的工作原理。

理想情况下，这可以通过良好的内部文档来实现，但实际上，内部文档通常很差或得不到维护–有时称为“文档债务”，这本身就是一个问题。

可观察性对于学习代码的工作方式至关重要。APM工具（如Datadog或AppDynamics）和异常管理器（如Sentry）有助于提供良好的概述。火焰图可以提供视觉帮助，跟踪解决方案可以帮助显示应用程序流程。

另一个选择是调试。我们的一位开发人员喜欢通过添加大量断点来查看遗留代码，并查看击中了哪些分支，直到他了解所有分支的工作方式为止。Rookout的不间断断点使您可以在代码运行时进行实验，而不会增加任何开销，从而使其成为进行此类探索的好工具。

一些真正的技术债务是不可避免的。您可以通过制定良好的设计决策来将其最小化，但是随着代码的老化，即使是最好的决策也可能会变成需要替换的负担。牢记持续的维护和未来的需求可以帮助您掌握技术问题，但您永远无法真正知道软件的未来。

遇到看似技术债务的问题时，请问“如果我理解代码，我还会感到吗？” 如果答案是“否”，那不是技术债务；而是 这是知识的不足，也是学习的机会。