本（běn）文最初发布于 Kyle Brown 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享（xiǎng）。

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

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

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

这一步最关键。一旦团队决定必须偿还他们的技术债（zhài）务（这（zhè）不是一个容易的决定——而且必须与业务一起做出），他（tā）们（men）就必须（xū）弄清楚他们实（shí）际上（shàng）欠了多少债务。我发现，最好的方法是进行自上（shàng）而下的（de）设计和代码审查。

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

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

通常，最好（hǎo）是请一个外部专（zhuān）家来帮助（zhù）你评估（gū）项目状态。引入一名外部人员（yuán）让你可以获得一（yī）份纯粹（cuì）是基于解决方案技（jì）术优越性的（de）评估，而不受办公室政（zhèng）治（zhì）或个（gè）人对某些代码的情感所影响。

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

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

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

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

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

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

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

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

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

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