本文最初发布于（yú） Kyle Brown 的个人（rén）博客（kè），经原作者（zhě）授权由 InfoQ 中文站翻译并分享。

让我们面对（duì）现实吧，2020 年是奇怪（guài）的一年。其中有一个奇（qí）怪的小（xiǎo）现象，自 2012 年以来，美（měi）国的个（gè）人储蓄率首（shǒu）次出现增长（zhǎng）（而且是以惊人的速度（dù）增长），而不是保持基本稳定 [1]。虽然这（zhè）其中大部分都与（yǔ）流行病有（yǒu）关，但这也许可以在一（yī）定程度（dù）上表明，消费者已经开始意（yì）识到，你不能一直借钱而不偿还你所欠下的债（zhài）务。我希（xī）望企业能（néng）够意识（shí）到，同样的原则也适用于技术债务，就像适用于（yú）金融债（zhài）务一样。这个类比可能会（huì）让一些人觉（jiào）得不太舒（shū）服，但这实际上是一个非常著名的思想，它（tā）最早是由 Ward Cunningham 在（zài） 15 年前提出 [2]，并（bìng）由 Joshua Kerievsky 在 2005 年进一步发展 [3]。

简单地说，当开发团队为了完成（chéng）其（qí）他（tā）活动而放（fàng）弃重要（yào）的软件开发（fā）活动（dòng）时（shí），就会产生技术债务。通（tōng）常，他（tā）们的想法是（shì），他们会（huì）“回过头（tóu）去”完成这（zhè）项（xiàng）活动，但意图往往不会转化为活（huó）动。这类活动（dòng）可能非（fēi）常简（jiǎn）单，如编写文档，但也可能是更（gèng）棘手的活动，比如（rú）修改一段（duàn）代码，让它更容易理解和维护，或者是更新因（yīn）为（wéi）代码变化而过（guò）时的设计文档。

我最近在处理（lǐ）几个客户（hù）的问题，我（wǒ）感（gǎn）觉自己就像（xiàng）一个消费者债务顾问，在（zài）和一对背负着巨额抵（dǐ）押贷款的夫妇谈话（huà），他们的信用卡余额（é）在（zài）不断（duàn）增（zēng）加，而且他们的孩子即（jí）将出生。在每一种情况下，我们（men）都快要被技术债务压垮了（le），我（wǒ）们必须找到一（yī）些（xiē）方法来减少债（zhài）务，同时继续开发新功能并继续前进。我提出（chū）了（le）一套实践（jiàn）方法，步骤和信贷顾问（wèn）给他们客户的建（jiàn）议类似（sì）。让我们看看这些步骤，看（kàn）看如何把他们应用于许多项目（mù）都面临的（de）技术（shù）债务（wù）状况。

这（zhè）一步最关（guān）键。一旦团队决（jué）定必须偿（cháng）还（hái）他们的技术债务（这不（bú）是一个容易的决定——而且必须（xū）与业务一起做出（chū）），他（tā）们就必须弄清（qīng）楚他（tā）们实际上（shàng）欠了（le）多少债务。我发现，最好的方法是进行自上而（ér）下的设（shè）计和代（dài）码（mǎ）审（shěn）查。

首先看看你（nǐ）的设（shè）计文档。它是最新的吗？它是否（fǒu）准确（què）地描述了设（shè）计中最重要（yào）的（de）点？然后，你可能想首先（xiān）审查下代（dài）码的哪些部分给你带来了最大的麻烦——哪些部分最难修改？哪些（xiē）地方出错率（lǜ）最高？那（nà）些部分对你的业务来说最重要？找出这些问题的答案，可以帮助（zhù）你（nǐ）对你需要做的事情进行排（pái）序，找出方法改善你的处（chù）境。

系（xì）统中并（bìng）不是只有代码（mǎ）和文档会导致技术债务（wù）。另一（yī）个（gè）需（xū）要考虑的关键因素是运营债务——例（lì）如，你是（shì）否运行在数据库或应用程序服务器等平台软件（jiàn）构成（chéng）的（de）后台上？你的（de）运营团队是否（fǒu）在手动执（zhí）行应该自动化（huà）完成的（de）任务，既浪费时间又浪费钱？你是否有适当（dāng）的监控，以便在问题导致站点宕机之前发（fā）现问题（tí），或者你是否把时间浪费在了事后分析上（shàng）？

通常，最好是（shì）请（qǐng）一个（gè）外（wài）部专家来帮助你评估项目状态。引入一名外部人员让你可以获得一份纯粹是基于解决方案技术优越性（xìng）的评估，而不受办（bàn）公室政治或个人对某些代码的情感所影响。

最终的评（píng）估需（xū）要描述需要（yào）更（gèng）改的内容，按照优先（xiān）级进行（háng）排序，并提出代码更改建议，以及列出的（de）每个更改的（de）估算成本。一旦你掌（zhǎng）握（wò）了这些事实，你就可以（yǐ）开始与（yǔ）业务所有者协商你要偿还哪些债务以及（jí）以什么顺序偿（cháng）还。

虽然上一步（bù）是（shì）整个计（jì）划中最重（chóng）要的一步，但第（dì）二步通常（cháng）会导致（zhì）与业务最针锋相对的讨论。其中最难（nán）的部分是（shì）学会组（zǔ）织（zhī）文化变革，这样你就不会让积累的债务（wù）超过合理的服务能力（lì）。就拿我们的金（jīn）融（róng）债（zhài）务来说（shuō），这也是一件非（fēi）常困难的（de）事情——改（gǎi）变你的消费习惯，只买你（nǐ）需要的东西，而（ér）不（bú）是用信用卡购买你想要（yào）的东西（xī），这是一件非常困难的事情。

为了修（xiū）复发现的问题，你必须花（huā）时间来实（shí）现修复，这意味（wèi）着你在纠正（zhèng）问（wèn）题时（shí）会搁置新的（de）开发。关于这一点，没（méi）有什么完美（měi）的方法（fǎ），无论你采（cǎi）取什么方法，你都需要与业务协商如何平（píng）衡技（jì）术债（zhài）务（wù）偿还和新功（gōng）能开发。下面是一些我们认为有效的策略。

在用户故事（shì）中包含债务偿还（hái）活（huó）动。如果（guǒ）前面的（de）步骤已经形成了（le）一组按大小分类并排好序的活（huó）动（dòng），那么你可以与业（yè）务（wù）合作，确保在（zài）每个开发周期中都包含其中（zhōng）一部分活动。比较难的是（shì）平衡债务偿（cháng）还活动（dòng）和涉及同一代码区域的新功能开发。例如，如果你正在开发一个电（diàn）子商务网站，并且你发现大（dà）多数（shù）问（wèn）题都是发生（shēng）在（zài）结帐时（shí），你可能想要把涉及这一部（bù）分（fèn）的（de）新功（gōng）能开发推迟到（dào）你（nǐ）偿还该（gāi）部（bù）分的技（jì）术债务时（shí）（例（lì）如（rú），重构代码或更新文档）。在这种情况下，在更改的过程中添（tiān）加新的促（cù）销活（huó）动或更改产品（pǐn）页（yè）面（miàn）将（jiāng）是（shì）合理（lǐ）的选择。

采用贝塔（tǎ）测（cè）试。如果你构建（jiàn）的基础设施（shī）可以支（zhī）撑两个网站（一个是主网站，另（lìng）一个是“测试（shì）”网站（zhàn）），那么你可以在重构（gòu）主代码流的同（tóng）时继续在测试网站上开发新功能（néng）。这（zhè）样（yàng）做的好处是不会减慢任何新功能开发的速度，但代价是（shì），当对测试（shì）站点的更改必须重（chóng）新集成到主站点时，集成难度会增加。

在这种情况下，我们可（kě）以和信用卡（kǎ）债务偿还策略（luè）做个对比，考虑两（liǎng）种不同的确定债务偿还优先级的方（fāng）法（fǎ）。第一种可能的（de）策略是“最高利率优（yōu）先”。在信贷领域，这种策略是先偿还利率最（zuì）高的信（xìn）用卡，因为这类信用卡（kǎ）支付的利息最高。在技术领域，这意味（wèi）着你可以首先考虑承担影响最大的任务。如果你解决了（le）这些问题，通常就可（kě）以为其他更改扫清障（zhàng）碍（ài），并且可能在性能、可维护性（xìng）等方面获得（dé）最大的回报。

另一种可能的策略是“最低余额优先”策略。用信（xìn）用（yòng）卡的术语（yǔ）来说，这意味着（zhe）先还（hái）清余额最低（dī）的信用卡——事情（qíng）很快就（jiù）完（wán）成了，这会让你立即获得一种成（chéng）就（jiù）感（gǎn）。对于技术（shù）债务，一个类似（sì）的策略是（shì）首先处理（lǐ）最小的修复（fù），如果你（nǐ）必须（xū）说服业务（wù）或管理人员偿还技（jì）术（shù）债务，或者（zhě）如果你所在的公司非常注重（chóng）结果导向（xiàng），只有快速取得进（jìn）展才能为更大的工作争（zhēng）取到资金（jīn）支持，这会（huì）特别有用（yòng）。

这里的关键（jiàn）是（shì），让（ràng）偿还债务成为你（nǐ）长期活动的一部分。这不是一次（cì）性交易；对（duì）于“重构”[4] 这类术（shù）语，人（rén）们不再（zài）像几年前它开（kāi）始流行时那（nà）样抱有幻想，因为他们希望最好（hǎo）是（shì）可（kě）以从长期投资中获得（dé）短期结果。你总（zǒng）是会（huì）招（zhāo）致新的债务；关键是（shì）确保你能在（zài）合（hé）理的（de）时间内偿还，而不是（shì）让（ràng）它越积越多。

最后，你需要能够报告你在债务偿（cháng）还活动中取得的进展。采（cǎi）集（jí）一些指标，用于向管理和业（yè）务证明，花费（fèi）在这些活动（dòng）中的时（shí）间是值得（dé）的，这点特别重要。例如（rú），很（hěn）多时（shí）候你需要（yào）重构代码（mǎ）来提高性能，这时，手上有正确的统（tǒng）计（jì）数据来显示（shì）用户体验的改进是很重（chóng）要的（de）。同（tóng）样，当你（nǐ）在（zài）改进一个简单的代码（mǎ）库时，添加新特性的速度是（shì）另一个向业（yè）务证明价值的（de）重要（yào）指标。

遵（zūn）循这些步骤并不能解（jiě）决技术债务相关的所有问题，但它们至（zhì）少可以让（ràng）你系统性地确定（dìng）需要做什么，可（kě）以（yǐ）为开发过（guò）程带来什么价值，以（yǐ）及变更在多大程度上解决了问题。如（rú）果（guǒ）你（nǐ）坚持这样（yàng）做，那么这应该可以使（shǐ）你的开（kāi）发（fā）工件（jiàn）更容易维护，并且应该可以（yǐ）减（jiǎn）少你（nǐ）的开发压力。