“债务就像陷阱，进去容易，想要脱身却很难。”

—— Josh Billings，美国著名的幽默作家

技术债务是科技行业最令人头疼的问题，就像生活中一提到债务就会让人感到压力重重。摆脱债务是一件苦差事。

特别是在软件工程中，技术债务通常指的是颇有年头且会占用大量工程师宝贵时间的系统。技术债务必须得到妥善地管理和维护，且应最小化。技术债务往往坐落在积压事项的最底部，管理不善就会拖垮你。

然而，凡是技术债务就一定是这个样子吗？

工程组织中越来越多的人认为，技术债务应该是所有软件开发人员工作的核心部分，积极管理技术债务不仅可以让团队免于被拖垮，而且还可以超越竞争对手。

什么是技术债务？

这个概念最初由计算机科学家Ward Cunningham于1992年提出，指的是技术系统因构建短期解决方案而引发的一系列权衡，这些欠下的债务将来必须以工程作业的形式偿还。

正如软件开发人员 Martin Fowler 在 2003 年所描述的那样：

这个比喻说明，选择快速的折中方案会导致我们背上技术债务，就好像金融债务一样。技术债务与金融债务一样也会产生利息，我们将不得不在未来的开发中付出额外的努力。

根据 Stripe 2018 年的开发人员指数报告，软件开发人员平均每周需要花费13个小时以上的时间来解决技术债务问题。现如今，随着应用程序变得越来越复杂，管理这些债务的重要性也达到了空前的高度。Stepsize 的首席执行官 Alexandre Omeyer表示：“所有你认为是负债的代码都是技术债务。”

技术债务的形式多种多样。InfoWorld 专栏作家 Isaac Sacolick 去年写道：“就应用程序架构体系的底层来说，技术债务可能是一小部分需要重构的代码、需要升级的库或者修复的单元测试；而从高层来看，技术债务包括重新设计复杂的单体应用程序、移植过时的 Web 服务协议、将多个平台整合成一个标准、清理数据债务问题、现代化基础设施、引入可观察性实践或自动化积压的手动测试用例。最糟糕的技术债务类型是‘着火的平台’，意思是说”平台经常突发影响业务的中断和意外。

虽然相较于与“着火的平台”苦苦纠缠，每个人更加希望发布闪亮的新功能，但只有团队持续付出积极的努力来解决技术债务，开发人员才能避免长时间的痛苦。

Sacolick曾表示：“解决技术债务常常会被忽视，因为这些工作无法解决紧急的业务需求，尤其是在不怎么紧急的情况下，投资回报率不明确，因此被认为是可以推迟的。凡是长期的维护工作都会面临这种遭遇，无论是代码还是房屋。”

窥探技术债务的深渊

Mik Kersten是《Project to Product》一书的作者，也是Tasktop 的创始人，他表示：“我们需要将技术债务视为首要问题，需要主动解决。然而不幸的是，对于很多人来说，这是一个新颖的概念。”

对于许多工程团队，尤其快速发展的组织中的团队来说，技术债务似乎与推出新功能之间似乎势同水火。但在Honeycomb的首席技术官与联合创始人Charity Majors来看，技术债务是“成功的标志，它意味着你还活着。”他表示，“千里之堤毁于蚁穴，我们必须妥善处理小问题。”

虽然说起来容易，但是要想认真地对待技术债务，整个组织都需要进行文化转变。

RedMonk 分析师 Rachel Stephens表示：“对于许多企业来说，能够按照优先级分配待办事项本身就是一个挑战，尤其是很多公司都会奖励推出新产品，但对于管理技术债务却没有任何特定的基于绩效的激励措施。”

Tasktop 的 Kersten也表示：“仅对推出新功能的工作提出奖励，就会将自己置于技术债务死亡的漩涡之中。”

如何承担技术债务

LaunchDarkly的首席技术官兼联合创始人John Kodumal早些时候曾表示，虽然“技术债务在软件开发中是不可避免的”，但主动减少债务总好过被堆积如山的债务压垮并影响到其他工作。

为了能够主动承担技术债务，你必须将技术债务视为正常敏捷流程中的一项工作。

Sacolick 表示：“维护应用程序、避免或延缓系统进入遗留状态的关键就在于，组织和团队如何管理技术债务。”我们必须积极主动，“制定政策、约定和流程，将减少技术债务的工作视为一项长期的成本。”

许多团队都会投入一定的人员和时间来解决技术债务，例如每个冲刺的20%。然而，Tasktop 的 Kersten 建议将项目的截止日期以及团队的能力考虑在内，采取一种更加灵活的方法。他说：“你应该衡量业务成果和技术债务的投资，并确保二者的平衡。将技术债务摆到眼前，这样你随时都能看到还有多少债务需要偿还。然后再设置一个目标交付百分比，当然这个比例必须随时间动态变化。”

对于云存储公司 Box 的首席技术官 Ben Kus 来说，偿还技术债务必须出现在所有工程团队的挤压工作列表中。“当然，技术债务的偿还会被推迟，但这是一项长期的任务，你必须持续投入时间和精力。”

但Kus不建议指派工程师专门解决技术债务，他表示：“千万别这么干，这会迫使某些员工离职。没有人愿意成天和技术债务、代码重构或类似的任务打交道。”

在Box，他们会将开发的工作以及在冲刺的过程中、事后分析和值班期间涌现的问题，平均地分配给各个工程团队。“我们有一个严格的事后分析流程，我们会找出有待解决的问题，以防止同样的问题再次发生。虽然我们不会说放下手头的一切工作，专门解决某个问题，但我们会明确表示，如果问题再次发生，就会追究责任。如果同样的问题再次出现，那将是非常不愉快的经历。”

轮流值守的重要性

由于工程团队希望有效地挖掘和衡量导致团队开发速度减慢的技术债务，随时待命变得越来越重要。

Honeycomb的Majors支持让从事开发新功能的工程师定期轮流值守，专门负责修复bug、重构代码以及偿还技术债务等工作。他表示：“有一个主要负责小问题的工程师很重要。工程师不应在值班期间从事产品开发工作。这样可以增加系统开发的灵活性。”

Chris Evans 是 Incident.io 的创始人，该公司是一家专门从事应急响应的软件初创公司。Evans告诉我们：“跟踪并记录一切的意义是减少那些‘不言自明’的知识。在轮流值守期间，你需要处理自己不太擅长的工作。”

虽然听起来这项工作的压力很大，但我们不仅可以解决问题，而且还可以在事后的分析中强调出现的问题，这样解决技术债务的重要性也会变得更加明显。

Evans曾在博客文章中写道：“承担运营的工作可以帮助我们收紧发布新功能与运行系统之间的反馈循环。这有助于我们做出务实的工程决策，并在发布新功能和支持与改进现有功能之间保持健康的张力。”

例如，Incident.io最近遇到了这样一个问题：他们的一个数据库交互出了问题，导致工程团队的开发速度减慢。Evans说：“我们投入了一周的时间，建立了一种更好的与数据库交互的方式，这对我们将来构建每个功能都产生了一定的影响。”

类似于这样的改进值得庆祝，就像解决了某个重大问题或发布了某个新功能一样，“偿还技术债务的重要性不亚于赢得新客户。”

《金融时报》对于技术债务的重新思考

在过去六年中，《金融时报》一直在重塑其处理技术债务的方法。早在 2015 年，这家英国报纸网站由一款名为 Falcon 的“大而全”的应用程序搭建。2016 年，该公司的开发人员将 Falcon 转换成了一组微服务，总称为Next。他们的 332 个代码存储库由一组职责明确的团队长期负责，从应用程序、内容发现和广告到中央平台，他们只需要负责 72 个代码存储库。

《金融时报》的客户产品技术总监 Anna Shipman 在 4 月于伦敦举行的 QCon 会议上表示：“大约只过了一年，我们的系统就开始出问题了。”他们的技术团队搞不清楚整体的技术战略，以及哪些服务归谁管。这导致技术负债越来越多，甚至出现了“闹鬼的森林”——没有人愿意接管的孤立代码库，而且愿意轮流值守的工程师数量也不断减少。

Shipman的一位同事跟她说：“感觉这个系统不是我们的，我们根本驾驭不了。我们只是在不断往里塞东西。”

为了战胜这种困境，他们付出了巨大努力重建秩序，清除“闹鬼的森林”，接受复杂性，并有效地管理整个系统。只有明确技术栈的所有权，组织才能更有意识地对付技术债务和闹鬼的森林”。

Shipman表示：“这项工作不同于常规的功能交付，你需要留出适当的时间，并安排专人去解决。这项工作永无止境，不是说稍微整理一下就万事大吉。”

虽然他们没有统一决定分出20%的工程时间来清除“闹鬼的森林”和管理技术债务，但 Shipman 认为如今团队能够更好地平衡功能交付与技术债务了。

将正确的观点传达给高层

通过上述讨论，相信你已重新认识技术债务，而且也明白放慢开发的速度，持续解决技术债务的价值，但挑战没有到此结束。你必须将这些观点传达给高级管理层。

Honeycomb 的 Majors 说：“产品和工程经理所有的时间都花在增加业务价值上了，就好像更多的附加功能和点缀是唯一的价值，但有时只有整体得到提升才能获得最大价值。”

对于工程经理来说，追求业务目标是当务之急，而技术债务常常被忽视，他们必须改变这种观点。

eBay 的高级首席架构师 David Van Couvering 在今年早些时候的一篇博客文章中写道：“在与工程师交谈时，我最常听到的抱怨之一就是，他们必须不断地开发功能，而他们使用的软件和工具变得越来越容易出问题、缺乏统一性，非常令人沮丧，这导致完成工作的难度越来越大。”

为了将这些风险转化为业务，就需要及时解决技术债务，让工程师们能够更快地工作，并确保软件更安全。

Van Couvering表示：“为了你自己，为了你的团队，也为了避免整个公司被技术债务拖垮，你必须学会向高层传达正确的观点。”

避免风险

成功管理技术债务需要投入大量精力来改变根深蒂固的文化和工作方式，还需要改善工程团队与业务团队之间的沟通。公司应该推出相应的激励措施，鼓励开发人员做出改变，避免技术债务越累越高的风险。

RedMonk 分析师 Rachel Stephens 在 2017 年写道：“你必须帮助业务伙伴了解到今天的决策会导致未来风险增大，技术债务必须及时得到解决。你可以谈谈技术债务问题对项目造成的危害，并展示如今的妥协会对今后埋下何等祸根。”

虽然闪亮的新功能会让客户和高管喜笑颜开，但负债累累的系统会摧毁一切，相信灾后重建是任何人都不希望看到的局面。

原文地址：https://www.infoworld.com/article/3660632/you-re-thinking-about-technical-debt-all-wrong.html