技术债务的概念被高估了。- Victor Ronin - Medium

噢哦。我刚写了一篇文章，突然意识到大约1.5年前我就在写这个主题了... 请随意阅读之前（更加冷静的）版本在这里 (opens new window)或者继续阅读 😃

你加入任何一家公司的研发部门，立刻就会听到关于技术债务的说法：“哦...这太糟糕了。这个设计得很糟糕。我们在这里那里都做了很多捷径”，等等。工程师们很明显的结论是我们现在应该开始处理技术债务。而且通常，工程师们也确实会加入这个过程，修复一些问题。 研究人员暗示，一切都应该停下来，直到所有（或至少是大部分）技术债务都偿还完毕。（顺便说一句，我不想当伪君子，我也这样做过，并且我还在特定情况下谈论技术债务）。

我认为这些讨论在20年前非常有意义，当时商业和产品管理可能一无所知。你必须积极地向他们解释，抄近路就像欠债一样，如果你长时间不还清它，就会把你搞破产。

时代已经改变了。每个人都听说过技术债务。不仅如此，我认为产品经理/业务领导人对这些讨论已经感到厌烦，每次这种对话再次出现时，他们（心理上）都会翻白眼。

在深入探讨本文的主要观点之前，请允许我进行一个简短的迂回。

首先，我假设 在想象中，你写下了史上最好的代码。一切都构建得井井有条，代码完美无缺，所有东西都经过了文档化、优化和打磨。你（以及其他所有人）都认为这是有史以来写过的最好的代码，你是世界上最幸福的工程师。

所以你在一个迷人的草地上漫步，感受着自己的优越感，因为即使是一朵花的美丽相比你的代码都相形见绌。

然后一个想法突然袭击了你。天哪，有一种更好、更紧凑、更优雅的代码结构方式。它会更简单，更容易修改，甚至稍微提高性能。然而，这将需要对你的应用程序的一大部分进行重构。

你的心情逐渐变暗，在接下来的几个月里，你开始与人们讨论这种更好的方法。在谈论了数十次之后，你叹了口气，“哦...要是我有时间去重构就好了。” 当你终于大声说出来的那一天，你意识到了：“嗯，这个整个应用程序都不够理想。我们需要重新构建它，现在我们有了技术债务。”

是的...是的。我知道我夸大了（很多）。然而，请稍等片刻。好好考虑一下。

• 产品需求没有变化。
• 使用案例没有变化。
• 语言和框架没有变化。
• 代码没有变化。

唯一改变的是你的想法。

归根结底，技术债务是观察者的眼中之物。它完全取决于你现在所处的位置与你认为应该达到的位置之间的感知差异（为了效率、不注意到缺陷等等）。

一个人可以容忍一些拼凑而成的烂代码，而另一个人则会对手头上的完美代码感到压力（并在心中拥有更好的方法）。

（照片由Maksym Kaharlytskyi (opens new window)在[Unsplash](htt 我们（工程师）最终与技术债务产生了不健康的关系。每当我们看到不符合我们标准的任何东西，我们立即吹哨。代码重复、糟糕的变量命名、缺乏文档...

不要误会我。拥有所有这些东西都是好的。然而，有时候我觉得我们花费在讨论上的时间比它本身的价值还要多。

我来到这个地方，意识到这里很熟悉，然后我找到了我写的原始文章。因此，我将从这里开始使用项目符号。

有一种更健康的方式来思考/处理技术债务。

• 首先，并不是每一个不完美都是技术债务。最好看看这个问题是否符合多数人的标准，或者只是影响你个人。
• 其次，如果你碰到一个简单的问题，就修复它。没有必要讨论它。不需要吹哨。
• 如果你碰到一个中等规模的问题，试着采取 而真正重要的是顶级违规者（那些对多个人产生重大影响的事物）。这些事情需要优先安排并计划。与产品经理的对话不应该是关于抽象的技术债务，而应该是关于一个具体、明确定义的项目，其范围是清理问题（并提供受影响的示例以及影响的方式）。

顺便说一下，在你决定把我开除出技术债务战士教堂之前，请注意我并不反对偿还技术债务。我反对设定不现实的期望，认为技术债务可以（甚至应该）为零。关键是要找到短期业务需求和长期业务需求之间的平衡。因此，这应该是关于项目对话而不是情感上的呼吁，即“我们的代码很糟糕”。