“债务就像任何陷阱一样，很容易进入，但很难摆脱。”——乔什·比林斯(美国幽默作家)
技术债务是科技界最讨厌的术语之一。就像在生活中一样，一提到债务就会让人感到压力重重。因为摆脱债务是一件苦差事。
具体来说，在软件工程中，技术债务通常指的是耗尽工程师大量宝贵时间维护的老化系统。技术债务需要管理、维护和最小化。因为技术债务可能是压倒骆驼的最后一根稻草，最终将会让企业不堪重负。
但一定要这样吗?越来越多的行业领先的工程组织认为，技术债务应该是所有软件开发人员工作的核心部分，通过主动管理和清除技术债务，不仅可以避免失败，而且实际上可以超越竞争对手。
什么是技术债务?
技术债务这一术语最初由计算机科学家Ward Cunningham于1992年提出，技术债务是指为技术系统构建短期解决方案会带来一系列权衡，从而导致未来的债务必须以工程工作的形式偿还。
正如软件开发人员Martin F owler在2003年所描述的那样：一些快速的做事方式给企业带来了技术债务，这类似于金融债务。与金融债务一样，技术债务也会产生利息，这是企业在未来发展中必须付出的额外努力。
根据Stripe公司在2018年发布的开发人员系数报告，软件开发人员每周平均花费13个小时以上来解决技术债务问题。现在，随着应用程序变得越来越复杂，管理这些技术债务从未像现在这样重要。Stepsize公司首席执行官Alexandre Omeyer说：“任何认为是负债的代码都是技术债务。”
技术债务有多种形式。行业专家Isaac Sacolick说，“在低端，它可能是需要重构的一小部分代码、需要升级的库或需要修复的单元测试。而在高端，技术债务包括重新设计复杂的单一应用程序、移植过时的Web服务协议、将多个平台整合到一个标准、清理数据债务问题、基础设施的现代化、引入可观察性实践或自动化积压的人工测试用例。最糟糕的技术债务类型是一种‘燃烧的平台’，这意味着平台经常出现影响业务的中断和事件。”
尽管开发任何被称为“燃烧的平台”似乎都不如推出新功能那么吸引人，但只有通过以积极和持续的方式作为一个团队来解决技术债务，开发人员才能避免长期的痛苦。
Sacolick写道：“解决技术债务往往被忽视，因为这样做很少能解决紧急的业务需求，尤其是对于非紧急情况，投资回报率不明确，因此被认为是可以推迟的。对于涉及维护的任何事情，无论是代码还是房屋，这都是一个经典问题。”
窥探技术债务的深渊
《产品到项目》一书的作者兼Tasktop公司创始人Mik Kersten说，“技术债务需要成为主动解决的首要问题。不幸的是，在许多情况下，这是一个新颖的概念。”
对于许多工程团队，尤其是那些在快速发展的组织中的工程团队来说，技术债务可能会让人觉得它与推出新功能的重要工作之间存在紧张关系。但对于Honeycomb公司首席技术官和联合创始人Charity Majors来说，技术债务本身就是成功的标志，它意味着企业还活着。
Majors表示，只有确保小事得到妥善处理，才能确保不会积少成多变得难以处理。
虽然这说起来容易，但整个组织都需要进行文化转变但企业都需要进行文化转变，以确保认真对待技术债务。
Red Monk公司分析师Rachel Stephens说，“对于许多企业来说，能够有一个真正的优先待办事项是一个挑战，尤其是那些有动力推出新产品但没有特定的基于绩效的激励措施的企业。这些企业同时还要管理他们的技术债务。”RedMonk分析师RachelStephens告诉InfoWorld。
或者，正如Tasktop公司的Kersten所说，“仅通过激励功能，企业就会将自己置于技术债务死亡漩涡中。”
如何管理技术债务
Launch Darkly公司首席技术官兼联合创始人John Kodumal指出，虽然技术债务在软件开发中是不可避免的，但随着时间的推移，主动减少债务比停止其他工作并试图摆脱堆积如山的债务要好得多。
这种应对技术债务的主动方法涉及将企业可能认为是技术债务的任何事情视为要包含在正常敏捷过程中的另一项功能工作。
行业专家Sacolick表示，维护应用程序和避免或至少延迟遗留状态的秘诀在于企业和团队如何管理技术债务。关键是积极主动，这意味着需要制定政策、惯例和流程，并随着时间的推移分摊减少债务的成本。
许多团队会倾向于投入一定的能力来解决技术债务，例如每个sprint的20%。然而，Tasktop公司的Kersten建议采取一种更加动态的方法，考虑即将到来的截止日期或团队能力的背景。
Kersten说。“你应该衡量业务成果和对技术债务的投资，并确保这些平衡。让技术债务可见，这样始终知道自己有了多少技术债务。一旦可见，设置目标交付百分比，该百分比必须随时间动态变化。”
对于云存储提供商Box公司的首席技术官Ben Kus来说，偿还技术债务是所有工程团队都需要在其工作中包含的内容。他说，“当然这会被推迟，但应该有一种持续的感觉，那就是一直在处理这些事情。”
不过，Kus并不建议指派某些工程师专注于技术债务。他说：“这可能是人才流失的根源。没有人愿意从事技术债务或重构之类的工作。”
Box公司希望在sprint过程中、事后分析和待命时平均分配工程团队的工作和表面问题。Kus说，“我们有一个严格的事后分析流程，我们会确定要解决的问题，以防止同样的问题再次发生。我们并不是那么想当然地说‘放弃一切来解决问题’，但我们明确表示，如果问题再次发生，这将成为一个责任问题。如果再次发生，那将非常令人不快。”
待命轮换的重要性
随着工程团队希望有效地挖掘和衡量拖慢他们前进速度的技术债务，这种随叫随到的元素变得越来越重要。
像Honeycomb公司的Majors这样的工程经理支持定期将工程师从特性工作中脱离出来，以便随时待命，专注于修复、重构和自动化债务。
Majors说，“有一个主要负责小事的工程师很重要。作为待命的一部分，应该积极劝阻他们不要从事产品工作。这将弹性引入了一个通常很少使用的系统中。”
Chris Evans是Incident.io公司的创始人，该公司是一家专门从事事件响应的软件初创公司。他说，“跟踪事物的全部意义在于清除那些隐性知识，员工会被要求完成他不擅长处理的事情。”
虽然一开始这听起来很可怕，但问题会得到解决，然后，通过强调在事件后清理或事后分析中出了什么问题，解决技术债务的重要性会变得更加明显。
Evans在去年12月发表的一篇博客文章中写道，“通过对我们所做的工作承担运营责任，我们加快了反馈循环。这有助于做出务实的工程决策，并在发布新代码与支持和改进我们现有的代码之间保持健康的张力。”
例如，该公司工程师最近因与其中一个数据库的交互而减慢了速度。Evans说，“通过一周的努力，我们认为可以建立一种与数据库交互的更好方式，这将对我们未来如何构建每个功能产生复合影响。”
这些成功应该像解决一个重大事件一样重要，或者开发出色的新功能一样值得庆祝，而消除大量技术债务，就像获得新客户一样重要。
英国《金融时报》对技术债务的反思
英国《金融时报》在过去六年中一直在重塑其处理技术债务的方法。早在2015年，这家英国报纸的网站就由一款名为Falcon的单一应用程序提供支持。2016年，该公司的开发人员将Falcon转换为一组微服务，现在其名称为Next。由此产生的332个代码存储库由一组具有明确职责的持久团队管理，从应用程序、内容发现和广告到中央平台，仅负责72个存储库。
英国《金融时报》客户产品技术总监Anna Shipman在4月于伦敦举行的QCon会议上表示。在大约一年之内，事情开始变得不太顺利。其开发团队忽略了整体技术战略以及谁拥有哪些服务。这导致了越来越多的技术债务，没有人愿意使用孤立代码库，以及愿意在数小时内随叫随到的工程师越来越少。
正如Shipman的一位同事告诉她的那样：“感觉不像我们拥有或指导这个系统。我们只是向里面塞进一些东西。”
企业需要清除那些技术债务并接受复杂性，以便更有效地管理它。只有当团队对他们的技术堆栈拥有明确的所有权时，企业才能开始更有意识地清理那些技术债务。
Shipman说，“这不是与常规功能交付一起做的事情，而是需要适当地留出时间并安排时间去做的事情，这并不是一劳永逸的事情。”
虽然没有中央授权将所有工程时间的20%分配给清除和管理技术债务，但Shipman认为其团队现在能够更好地平衡功能交付与技术债务。
说服高管
一旦重新评估了与跨工程技术债务的关系，开发人员将了解放慢速度以持续解决技术债务的价值，但挑战并没有就此结束，仍然必须向企业高管传达这种价值观。
Honeycomb公司的Majors说，“产品和工程经理将他们的时间分配给增加业务价值，好像华而不实的功能是唯一的价值。”
解决技术债务可能是在追求业务目标时优先考虑的第一件事，但工程经理必须改变这种说法。
eBay公司高级首席架构师David Van Couvering在今年早些时候的一篇博客文章中写道。 “当我与工程师沟通时，我听到的最常见的抱怨之一是，他们觉得自己必须不断地开发功能，而他们使用的软件和工具变得更加脆弱、不一致和令人沮丧，他们完成工作变得越来越困难。”
而让不同部门的人员了解这些脆弱系统的风险，通过强调现在清除技术债务可以使工程在未来更快地发展，确保软件更安全。
Van Couvering写道，“当清除技术债务时，企业、团队和员工都会受益。因为它们避免了工程工作堆积可能带来的失败。”
金融时报的Shipman建议道，“其他工程师会明白这项工作的重要性。企业需要真正与业务指标联系起来，例如周转时间、性能和质量。”
不要冒险
成功管理技术债务需要付出大量努力来改变根深蒂固的企业文化和工作方式，以及改善工程团队与业务团队之间的沟通。开发商采取的激励措施可能需要改变，但忽视不断增长的技术债务的风险可能存在。
RedMonk公司分析师Rachel Stephens说，“如果企业专注于帮助业务伙伴了解当今的决策如何增加未来风险，那么反对技术债务的论点将会得到加强。可以展示项目中可预测性的丧失，面临的问题将导致以后的性能下降。”
开发出新功能会让客户和高管们感到很高兴，但技术债务沉重的系统会让一切都停顿下来，因此企业需要尽力避免技术债务。
