作者 | Ryan Donovan
编译 | 徐杰承
当Ward Cunningham在“敏捷宣言”中首次提出“技术债”概念时，他表示需要用一种方式来讨论项目早期所做的决策，这些决策会在工程师后续的开发工作中困扰他们。一些企业为了将产品推向市场而在早期做出的技术决策可能并不适用于长期发展，除非修正这些决策，否则团队的生产力将会受到影响。
这里的一个例子是，Facebook最初是用PHP编写的。然而随着增加特性、复杂性和规模，PHP开始变得不再适用于新的需求，这便是PHP给Facebook带来的技术债。但值得注意的是，技术债并不一定意味着最初的选择是错误的。用PHP编写网站起初是一个明智的决定——问题并不出在语言，而是需求的改变。
事实上，不仅是语言，工具、框架、软件架构这些都有可能会产生技术债。这在当时可能是为了眼前的利益而做出的善意的编码决策，但这不意味着它们将一直适用。对企业而言，越早解决技术债问题越好，这将有利于企业的持续高速发展。但解决这些问题需要进一步挖掘技术债的本质，并准确量化你的工程团队到底背负了多少债务。
1、维护成本
虽然开发人员喜欢解决问题，但这并不总是意味着他们喜欢寻找技术债所带来的bug。技术领导需要更多的考虑为业务服务，因为业务通常关乎公司的利润和损失。因此，为了还清技术债，你首先需要从成本和收益的角度来考虑。
技术债的经济影响是真实的。根据Stripe在2018年的研究，他们发现，开发人员平均每周会因技术债带来的问题花费13.5小时，如果你用开发者的工资乘以这个数，那么你就可以基本判断技术债的成本。
图片
如同有人在Stack Overflow上所说，“由于复杂性，低质量的代码通常需要更长时间来维护，这将严重影响开发者所产生的价值。”大多数公司都已经使用了某些问题跟踪系统，因此评估花费在维护技术债上的时间其实并不困难。
而要确定特定领域债务的影响，则需要审查代码，跟踪哪些代码获得了最多的修改。进行这样的数据挖掘还可以让你识别出代码维护时的聚类，并将其与跟踪系统中的错误完成情况进行比较。
当然，你也可以直接询问团队。Stack Overflow的工程总监Roberta Arcoverde说，“这听起来可能很天真，但这背后确有实际依据，如果团队一致认为某个东西很重要，但这部分因为代码或其他问题导致维护困难，那么你就可以基本定位问题所在。”
2、机会成本
如果开发人员将大量时间花在技术债和糟糕的代码上，这意味着他们没有多余的精力创新。对于注重速度的软件行业来说，这是一件大事。你发布新功能的速度越快，就能越好地满足客户的需求，也能为产品增加更多的价值。相反，将功能和补丁推向市场花费的时间越多，你就越落后于竞争对手。
任何技术债几乎都会影响到编写你要交付的代码的时间，但从另一个角度看，解决技术债同样存在着不小的复杂性，这种复杂性本身也会成为一笔债务。因此，技术管理者需要决定到底该在哪个时候解决问题。
这需要权衡开发者的生产力与业务需求量。因为随着代码变得越来越难维护，新特性的发布时间也越来越长。而代码库中需要修改的地方越多，花费的时间就越多。
有时技术债来自过时的或基于以前版本软件的善意技术决策。更新这些可能需要大量的代码重写而不是简单的重构。虽然一些度量标准会有所帮助，但如果这与紧急的业务需求冲突，还是要根据实际情况进行决策。
当然如果条件允许，越早解决问题越好。随着技术债的增长，它会产生“利息”，支付利息将变得越来越繁重，甚至超越“本金”。在一个软件企业中，随着技术债务的增长，整体开发速度会越来越慢，交付给客户的新特性也会越来越少。
3、人力成本
详细的文档、流程以及代码库的可读性非常重要。所有人都知道在某个时候你会需要它，但很多企业在早期为了省事而跳过了它。这使得新员工必须四处打听，并占用高级工程师的时间，以便让自己能够开始工作。
一旦开发人员准备好开始工作，他们可能会因为发现自己面对堆积如山的杂乱代码而感到沮丧——他们不得不花大量时间试图弄清楚这段代码到底想要表达什么。
此外，过时或低效的工具和依赖也会让开发人员绝望。想象一下，当你在编写代码时发现一个令人困惑的古老漏洞。“我以为这个问题在Y版本中已经解决了？”“是的，但是我们仍然在使用X版本，升级尚未获得批准。”
而当开发者在工作中无法接触先进技术栈时，他们的技能会逐渐萎缩。在一份调查中显示，30%以上的人(取决于地区)表示，他们认为自己所在企业的技术栈有些过时，希望寻找使用新技术的新工作。
这些问题都会导致企业员工的流失。如果你的公司总是遭受频繁的人员流失，这会对企业带来很大的负面影响。如果这些债务让你失去了优秀的员工，那么你将很难在下一次竞争中取得先机。
4、清点技术债
技术债的概念如今已经受到了越来越多的关注，它将工程问题转化为商业语言。如果你想偿还这些债务，那么你需要用商业语言来说明。费用是多少？它是如何对企业带来影响的？对于任何商业决策来说，权衡都是最重要的。
像金融债务一样，当你花费越来越多的时间来解决它的影响时，未偿还的技术债务会困扰你。糟糕的代码会带来更多糟糕的代码，这类似利滚利的概念。你并不一定需要在某个时间彻底偿还债务，但你需要持续作出改变，削减技术债，你就有更多的空间来编写真正能够带来价值的代码。
原文链接：https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/
