定义和处理技术债务

我们都熟悉债务，对吧？它指的是一个人（借款人）欠另一个人（贷款人）的金额。我们通常用它来描述财务状况。例如，我从银行借钱。我现在欠他们借款的金额（加上利息！），他们期望我偿还。

债务并不总是与金钱有关。事实上，作为前端开发者，我们经常遇到它，甚至可能没有意识到。我们将这个术语称为**技术债务**，并且将在本文中探讨其含义。

定义技术债务

我可以快速地将您链接到维基百科关于技术债务的条目供您自己阅读，但我认为它比那里描述的要复杂一些。

技术债务是在开发过程中编写代码时做出的妥协的总和。您甚至可以认为您编写的每一行代码都对技术债务有所贡献。这是因为存在：代码本身、代码的结果，以及代码如何与其他代码交互。当需要进行更改时，债务的后果就会出现。协调更改与预期结果以及其他代码对该结果的影响的难度与技术债务的程度相关。

每次我们编写代码（特别是如果它违反了最佳实践）时，我们都会开始在最终交付的产品中看到后果。就像金钱一样，我们在代码中做出的妥协是可以并且经常需要偿还的，因为如果不偿还，债务可能会导致我们破产，表现为难以进行更改。

从维基百科条目中值得注意的一点是，并非所有技术债务都是平等的。事实上，有四种类型的债务需要考虑。让我们看看每一种。

鲁莽债务

这些是我们有意且不考虑其可能产生的后果而在代码中做出的妥协。这相当于办了几张新的信用卡，并且透支了它们，而没有打算偿还余额。当然，我对此没有任何经验，也不以任何方式赞同这种行为。

想想您使用!important覆盖CSS属性的次数。几乎总是有办法避免使用它，并且通常最好这样做。尽管如此，我们中有多少人在偶尔会偷偷使用它，因为重构代码的麻烦在当时显得过于艰巨？这是我们做出的妥协，并且可能在将来某个时间点再次遇到样式层叠失效时不得不处理。

有时我们意识到自己鲁莽，有时我们没有意识到。命名是一个经典的例子，很容易忽视鲁莽行为。有时我们选择的名称（对于函数、类名等）起初看起来完全没问题，但在将来却以意想不到的方式发生冲突。这里的鲁莽行为是缺乏或不遵循命名策略。

谨慎债务

这些是我们明知故犯的妥协，并且着眼于未来。您是否曾经借钱投资一些将来（希望）会带来回报的东西？这与之相同。事实上，谨慎通常被认为是一种美德，并以对未来的仔细思考和重视为特征。

我们如何对代码做出谨慎的妥协？想想您编写过哪些当时无关紧要，但将来会变得有意义的东西。我想起了几年前的CSS3特性。还记得当圆角在许多浏览器中仍然不受支持，但我们都知道它们很快就会得到支持的时候吗？将带有前缀和不带前缀的属性一起使用是产生谨慎债务的一个很好的例子。

.rounded-corners {
   -webkit-border-radius: 5px;
    -khtml-border-radius: 5px;
      -moz-border-radius: 5px;
           border-radius: 5px;
}

为了支持一个小的设计元素，需要编写很多代码，但我们知道，随着浏览器在未来版本中采用规范，它将与浏览器很好地配合。在那时，我们可以通过删除供应商前缀来自由地偿还我们的债务。

（现在，当然，我们有像Autoprefixer这样的工具来帮助处理供应商前缀之类的事情。）

这种类型的操作仍然是债务。规划和编码需要思考和努力，并会产生更多代码。也许事情不会完全按照您想象的那样发展。

故意债务

有时我们会故意对代码做出妥协，这反过来会导致债务。您永远不会做这样的事情，对吧？好吧，考虑一下您可能这样做的一些原因。

• 预算限制
• 截止日期
• 最高权力者（HiPPOs）

我知道最后一个至少让我吃过几次亏。关键是，在某些情况下，我们做出的妥协超出了我们的控制范围，这会导致产生技术债务，尽管我们有最好的意图。

无意债务

这有点像是不知道自己不知道什么的结果。这些是我们因为不知道而做出的妥协。并不是我们有意为之。我们只是在不知情的情况下做到了这一点。

命名在这里也很重要。例如，我们决定元素上使用的类名以及我们命名的方式可能会对代码的其他部分如何工作产生不利影响。这就是为什么我们现在看到开发命名约定（例如BEM）的更大趋势。

其他例子可能包括…

• 您忘记考虑函数可以接受的一些极端情况
• 您修复了一个特定浏览器的問題，但没有意识到它破坏了另一个浏览器
• 您没有意识到正在使用的库有一个方法可以执行某个操作，因此您自己手动编写了一个，结果发现您编写的那个效果不太好
• 您的测试省略了某些可能的用户状态

技术债务的后果

我从未听说过用“债务”这个词来描述积极的事情。相反，它似乎是带来负面后果的东西。对于代码来说，这些后果可能是毁灭性的，表现为不稳定的代码库，以及可能令人丧失动力的代码库。

然后是“利息”的隐喻。利息是指根据我们欠款的金额计算出的利率，除了借款之外，我们还需偿还利息。我们拥有的金钱（我们编写的代码）越多，我们等待的时间越长，利息就越高。一次妥协可能会导致另一次妥协，并且滚雪球效应可能会产生过高的利息，以至于无法以维护、性能或截止日期等形式偿还。

处理技术债务

技术债务非常类似于财务债务，因为我们可能希望尽可能避免它。除了处理我们可能存在的任何债务之外，以下是一些我们可以做到这一点的方法。

记录一切

在代码中做笔记通常是一个好习惯，但它也可以帮助我们摆脱困境。如果您发现自己需要做出妥协，请在代码中以注释的形式记录下来。在这些注释中，解释您做了什么，可能产生的影响以及将来如何解决。未来的您会感谢您的。

注释在不仅解释代码的功能，而且解释以下内容时特别有用：

• 为什么它这样做

• 与之相关的奇特之处
• 其他与之相关的代码所在位置

编码风格指南

保持一份编码风格指南并认真遵循它。风格指南将为您的团队或项目提供标准，并且通常有助于您做出艰难的决策，例如命名约定或代码格式。

需要风格指南方面的帮助吗？Chris 撰写了一篇关于风格指南如何融入开发流程的文章，此外还有这个 Sass 风格指南示例。

一个得到良好遵循的风格指南可以减少您在推理最近没有接触过的代码时产生的认知负担。

代码审查

尽早并经常审查您的代码。这本身可能就是一个主题。哦，它已经有了。

在这些审查期间要对您的代码严格。在查看代码的可维护性、性能或可访问性等方面，您是否可以做出更好的决策？代码编写者可能不是所有这些方面最好的评判者。

羞愧文件

这是我最喜欢的建议之一。Harry Roberts 提出这个想法作为一种跟踪我们故意产生的技术债务的方法。将所有已知的妥协措施都保留在这个文件中，并将其用作需要偿还的债务的任务列表。而且，就像一张巨额信用卡账单一样，努力至少清偿当月的最低还款额。

创建一个技术债务池似乎是一个坏主意。但这是已知的技术债务——您可以将其视为比分散的、未记录的、隐蔽的技术债务成本更低。

总结

我们在本文中介绍了技术债务的概念，并且经常用金钱来描述它。您认为技术债务存在吗？如果是，您在哪里积累了最多的债务以及您如何处理它？如果不是，技术债务（以及财务隐喻）是否有点过分？在评论中分享您的想法。

其他资源

• DevMag.io：什么是技术债务？
• 技术债务简史
• 技术债务 101
• 管理技术债务