在软件行业发明的所有流行语中，技术债务是最令人失望的。我知道这可能会引发争议，并且我已经能听到对干净架构的渴望。因此，我将解释我的想法。
什么是技术债务？
在采访中，问到“技术债务的定义是什么？”令人惊讶的是，所有候选人都有不同的回答。行业似乎没有达成共识。我将回答分为以下几类。
以下是与这些回答相关的一些问题。
- 例如，“旧代码”是什么？一年六个月……
- 回答侧重于症状而非根本原因。例如，“没有人想修复吗？”没有人想碰它的原因是什么？因为难以理解吗？因为知识的丧失或对业务至关重要的部分压力太大吗？
- 在问题不明确的地方回答。“代码慢”是问题吗？在数据库记录中，每月运行一次的维护脚本工作。运行需要3个小时。我不是SQL专家，确信脚本可以优化，但脚本完成了这项工作，没有人抱怨。
我并不是在谈论“别人写的代码”是技术债务的工程师的自我。
无论定义如何，每个公司都有技术债务。总是没有人想触碰那些需要优化或使用旧框架的东西。当我在2014年在亚马逊工作时，零售网站的一部分是用Perl编写的。Java是新的标准。这段代码已经9岁了，所有人总是害怕修改。没有人再懂Perl，但每天都有成千上万的客户在使用它。
一个共识
尽管有许多不同的定义，但有一些一致性。技术债务是坏的！这个概念有很多否定。当候选人问我“你有技术债务吗？”时。我坦诚地说时，他们非常担心。有些人甚至表示不想在有技术债务的公司工作。
技术债务是昂贵的
证明技术债务是坏的主要论点是价格。因此，我努力理解这个成本。然而，与合同中规定利率的贷款不同，技术债务很难衡量。我试图通过故事点来观察团队的速度。
我看到在单体上工作的团队的速度比在微服务架构上工作的速度慢。几个月后，我意识到技术债务并不是问题。问题在于需要维护的功能量。当我们达到3个微服务时，第二个团队的速度比单体慢。维护多个服务的负担成为了问题。
在移动团队中，我比较了Android和iOS团队的速度。即使不使用干净架构原则，iOS开发由于错误较少而更快。
公平地说，速度是一个糟糕的指标。它在团队中不一致，我学会了不依赖于它。如果你知道一个好的技术债务衡量标准，请告诉我。
尊重你面前的事物
关于技术债务的对话可以总结如下。我发现了这个推理。工程师抱怨这个团队基本上选择使用亚马逊内部键值存储“Beaver”，它是Dynamodb的祖先。他抱怨“Beaver”的SDK繁琐，授权系统没有足够的细分。这两个都是合理的抱怨。
他积极地问：“团队为什么决定使用这个垃圾而不是Dynamodb？”一位在公司工作了20年的工程师回答说：“Dynamodb是在2012年发布的，而这个项目是在2009年开始的。”
我学会了假设良好的意图。你可能有其他约束，但我知道他们在做什么。如果不理解选择，请询问决定的背景。那可能是当时唯一有效的选择。
技术债务真的那么糟糕吗？
技术债务与金融债务一样，起源于金融行业的隐喻，技术债务就像积累利息一样积累利息。也就是说，即使不解读，未来也会有很多工作需要解决。这是一个很好的方法来解释业务团队如何优先考虑维护操作而不是新功能。这在生态系统中是可怕的事情。
但是，债务是问题吗？为了买房，你需要抵押贷款并支付每月的利息和本金。因为一次性支付不起，所以这是积极的。利用债务可以实现目标。
创业需要初始资金。企业家在筹集资金时受到赞扬。越高越好，但从期望盈利的投资者那里借钱。债务使你能够实现目标。它并不是像工具那样糟糕。这就是经济运作的方式。软件开发也是如此。
我在2019年加入了一个由8名开发者组成的初创团队。两年后，新雇佣的开发者抱怨说，首个移动应用程序是使用React Native构建的，而不是使用iOS的Swift等基本技术。在拥有100多名工程师和6名专职移动开发者并扩展之前，初始移动应用程序是唯一的前端工程师构建的。我必须提醒他，由于他不懂母语，他在一个月内使用他所知道的东西发布了MVP。正是由于这个快速的MVP，公司吸引了数千名客户。通过这种销售牵引力，我们能够提高B轮融资，并用这笔钱雇佣专职移动开发者来构建基本应用程序。他的薪水实际上是通过技术债务所产生的金融债务支付的。
结论
让我们对技术债务给予一些爱。它是工具，既不好也不坏，取决于你如何使用它。如果你借了太多钱而不偿还利息，你会被过度标记。但是，如果为了投资而进行长期贷款，你可以购买时间，获得客户，解锁项目。这是有益的。因此，你应该尊重你面前的事物。