技术团队如何合理配置“技术债务”？

编者按：“技术债务”这一概念是沃德·坎宁安在1992年提出的，指的是开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。如今，技术债务已经逐渐发展为软件开发领域的制胜之道。那么究竟什么是所谓的“技术债务”呢？我们又该如何应用这一概念？本文作者 Joe Xavier 在文中做了阐释。

不是所有的债务都是坏帐。战略性的债务规划可以优化公司是金融界的共识。这也同样适用于软件。在债务的使用（此情形一般为技术债务）方面具有战略眼光的公司可以更快地开发产品，并更快地推出产品，从而赢得市场。

这其中的关键是“战略性”。技术债务必须被合理配置 ，太少，你就会输掉比赛；太多，你就会陷进一个你永远也爬不出来的黑洞。

什么是技术债务？这个术语由最先提出维基概念的程序员--沃德·坎宁安在1992年所创造。坎宁安这样描述技术债务：“初次发布代码就像是开始举债。每当代码被收回重写时就会加速原本少量债务的发展。当债务无力偿还时就会发生危险。浪费在不完美的代码上的每一分钟都被作为债务的利息。”

理论上，你可以毫无限制地调整软件，不断地在开发项目上投入时间和资源，不断让它变得更好、更高效。然而在实践当中，没有一个开发团队能拥有无限的时间或资源，在某些时候，你需要做出决定停止重复劳动从而继续前进。这时就是技术债务开始累积的时刻。

学界为了工程债务的利益和风险而争论不休。这可能是源于人们想到软件时，就会自然而然地认为其应该有完美的设计、无暇的系统以及无缺陷的运行。但是无休止地追求一个可以运行无暇的完美系统，无疑会使你快速构建产品以及响应客户的能力受限。技术债务是一种能够让你跳出这一僵局去发布产品并打败你竞争对手的资产。

成功的秘诀在于弄清楚研发周期何处可以承受技术债务，以及何时开始偿还债务。你需要一个基于技术债务的思辨的框架去得到答案。

首先，识别你项目中无法承担任何技术债务的部分。

在大规模的事务系统中，每个数据都是至关重要的，你最好预先多花时间设计系统以期长久运行及易于维护 - 所以这不是一个累积债务的合适环节。可靠性和可用性要求十分高的关键任务系统也是如此。我们对关键系统的理念是优化，不断地优化直至达到一个绝对高的门槛。另一个评判标准是你在系统/代码库的某部分的更改频率。债务创造新的债务，所以如果一个组成部分变化起伏很大，它就会累积越来越多的债务...而一个组成部分变化极少的话，你通常可以积累一些债务并让它长时间保持原状。

现在让我们假设您要在现有产品中添加新的功能。您不确定这个功能是否真的会有效和受用户欢迎。您的目标是尽快推出以期收集反馈意见并进一步优化。这是一个您可以将研发速度优先于严格性的情形。在这里，由于您之后可以随时取回并清理代码，上市时间无疑比无暇的代码更有价值。其优点是，你用最少的时间来印证你的想法，并可以将省下的时间留给其他项目。

技术债务的另一关键是不断地了解需要花多少时间返工和偿还债务。如果事实证明您所构建的新功能是成功的并开始被采纳，您就必须迅速采取措施去偿还债务，以保持用户满意度并确保您的新功能不会导致系统崩溃。

不要忘记技术债务有一个文化因素。那就是大多数工程师都是完美主义者：“我们想要通过正确的方式进行研发，我们不喜欢走捷径等此类想法。”因此，一个研发团队不断地被迫积累技术债务并最快地将产品推向市场的做法可能会令其士气低落。

经常性地与研发团队公开谈论技术债务是关键所在。当我的工程师们在制定设计文稿时，我鼓励他们指明某个设计决策可能会成为我们累积技术债务的地方。这使得他们谈及技术债务时不再情绪化，也使这一问题不再是哲学思辨。这一方法还有助于调整希望快速推进的产品经理与想要正确构建的工程师的心态。最重要的是，它可以使我们现实地看待代码。

我们还制定了一个修复我们所承担技术债务的时间表。在我们的业务中总有新的挑战不断出现，这使我们很容易忘记之前的事情就着手去做新的，从而放任技术债务直至成为一个麻烦。我们通过创建特定的未来项目来回收和清理旧代码以此来降低此类风险。

技术债务的附带利益是提升新手工程师关于代码库方面的能力。一个新手工程师的升级方法之一就是让他们与有经验的开发人员合作，重构我们要求修复的部分代码库。这是一个能使新人快速上手的好方法。

总而言之，我们很容易去用非黑即白、非好即坏的眼光看待世界，但构筑软件要远比这微妙。如果你倾向于教条式的方法并认定技术债务不好，那你将永远不会看到你的产品快速地上市。如果你盲目认定技术债务总是好的，你也许会得到一个粗制滥造的研发环境和一个错误百出的代码库，从而成为你成功的绊脚石。但是，如果你能始终保持清晰的头脑掌握均衡之道，那么技术债务可以为你的团队带来巨大红利。

翻译来自：虫洞翻翻  译者ID：陆熠锴