技术债务，到底应该怎么还？

几乎所有的技术团队，都会经历或多或少的技术债务。技术债务虽然是实现快速收益的一种捷径，但是为了修复那些为了快速收益而不得不为之的技术问题，企业往往需要花费大量的金钱、人力等。那么如何有效地避免技术债务，使得开发人员能把更多的精力投入在有效的工作，从而产生额外价值、提高企业的产品竞争力呢？

技术债务的产生有着很多原因，但其中更多的是由于要在短时间内匆忙完成原本耗时较长的工作，导致部分业务逻辑没有完整的设计等，使得产品在短时间内有效，但是长远来看，却是一颗不稳定的炸弹，一旦触发，对产品、对企业都有可能造成无法挽回的损失。总而言之，技术债务会带来很多麻烦，有些甚至是“致命”的。

什么是技术债务？

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code
debt），是编程及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复由于之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。
——摘自 维基百科

很多人将技术债务类比于金融债务，但是和金融债务不同的是，技术债务可能不会承担利息。例如当需要快速验证产品的某个特点的时候，带有一定技术债务的产品可能是个好的选择；当验证之后，无需该特点的时候，即可以直接移除等，此时可能不会承担债务利息。但是大多数时候，此类情况较少，就算仅仅是为了验证产品，也不建议使用技术债务的方式去实施。类似这样的技术债务可称为有意的技术债务，另一种更加危险的技术债务称为无意的技术债务，无意的技术债务就像是前文说到的隐藏在代码中的炸弹。

无论是那种技术债务，在未来的产品迭代过程中，都需要开发人员去界定债务边界，不能任由技术债务滋生，否则在迭代过程中，面临的困难会越来越多，甚至需要被迫承担更多的技术债务。基本上，你承担的债务越多，项目的进度就越慢，项目的后续阶段就会更加困难。

但是需要清楚的是，技术债务是无法消除的，你必须随时做好承担技术债务的准备。因为在有的项目场景中，一些解决方案可以针对性解决某些具体问题，但是该方案可能不是全局有效或最佳的，于是在系统的其他方面就形成了一个不可避免而必须承担的技术债务问题。一个好的工程师团队，应该是能够最小化技术债务影响，并对技术债务进行合理管理的团队。

上文提到，技术债务分为有意的技术债务和无意的技术债务，两种形式的技术债务形成的原因和带来的结果是不同的。在某些情况下，有意的技术债务相比无意的技术债务更好，有意的技术债务会让团队意识到问题，从而有意的去进行优化改进等；而无意的技术债务可能在项目中潜伏很长一段时间，可能导致严重的问题，然而，无意的技术债务在项目中是无法避免的，只能通过在工程师团队中强化编码规范、业务理解等来对技术债务进行管理或者减弱其出现的可能。

另外还可以将技术债务分类为鲁莽型技术债务和谨慎型技术债务。一些谨慎型的技术债务在项目进程中是可取的，但是不论是哪种技术债务，都需要每个人勇于承担。理想的情况下，承担的债务应当是那些有意的和谨慎的技术债务，而那些无意的和鲁莽的技术债务应当不惜一切代价去避免。

为什么要关心技术债务？

技术债务如何影响开发

在开发阶段，开发人员不可避免会遇到技术债务，应当直面技术债务，并积极处理技术债务问题。虽然处理技术债务可能会使得开发周期变长，但从长远来看，开发人员及时处理技术债务是有益的，一方面处理技术债务是一个技术经验积累的过程，另一方面及时的处理可以在之后的迭代中减少技术债务产生的可能等。每一个开发人员都应当有意的或者尽力地避免那些无意的和鲁莽的技术债务。

技术债务如何影响客户

虽然乍看起来，技术债务和客户并无联系，客户也不太关心产品的代码质量等，客户只需要在成本没有增加的情况下，产品能够按时交付使用。然而，一个背负无意或者鲁莽的技术债务的产品在开发过程中，往往需要花费更多的时间、精力和资源，导致成本增加而收益却减少的情况等。

技术债务如何影响用户

即使是间接的，用户也会受到技术债务的影响。他们可能不关心软件开发所需的工作量或资金，但他们确实关心它的可靠运行，以及快速添加的新功能，这两者都可能受到大量技术债务的影响。用户越快乐，客户越快乐，开发者越快乐。

技术债务最佳实践

解决技术债务的最大问题是，它无法真正被量化。这使得开发团队很难跟踪技术债务并让管理层向客户展示为什么要投入更多的资源和时间。

但是这里有一些事情是你可以做的：

保持最新状态

不言而喻，工具、框架和库应该始终保持最新状态。并不是每个人都能意识到这一点，所以这里再强调一下也无妨。

文档

记录需要修复或更新的所有内容，这是确保实际修复和更新的最重要步骤。

如果存在技术债务，最好了解它并确保团队或未来的开发人员也了解。文档减少了定位和修复问题所需的工作量，如果债务记录良好，甚至能在业务层面上可见，将有助于获得客户承认并提供额外资源。

代码审查

另一个强大的工具是在sprint期间定期审查代码。代码审查可以捕捉到可能导致问题的隐患，并找到解决方案。代码审查确实需要一些时间，但在整个项目的背景下肯定是值得的。

但是，代码审查也有其缺点。开发人员往往太忙，无法深入挖掘他人的代码，因此他们只会发现明显的错误，而吹毛求疵可能会导致团队内部紧张。因此，它可以成为减少技术债务的有力工具，但应该谨慎应用。

自动化测试

自动化测试是一种非常强大的工具，但是经常被忽视。自动化测试被忽略后，可能会无法察觉出代码中的隐藏问题，往往导致产品发布后需要投入不成比例的人力和时间来应对，使得成本变高甚至不可控。在开发阶段，有必要实施测试驱动开发，编写完善的测试用例，以清除代码中的许多不易察觉的问题等。

敏捷架构

敏捷架构具有很多优点，在构建软件的过程中对更改更加开放，这基本会发生在任何项目上。但是，它确实要求代码具有灵活性和可维护性，因此敏捷方法自然会使开发人员保持良好的代码，这有助于防止技术债务的大量积累。

有效地复盘

如果出现问题，应该勇于面对，当问题解决后，需要进行有效地复盘。但是要注意的是，复盘是为了提高工作效率，而不是为了找人背锅。复盘的重点应放在了解问题及产生问题的原因上，以便团队可以采取必要措施防止同样的问题再次发生。

管理技术债务的最佳做法

即使你做了以上所有事情，并尽可能避免技术债务的堆积，仍然会有一些债务需要去处理。这是无法避免的，因此应该执行最佳实践和流程以防止技术债务失控。

高利息（高代价）技术债务优先

并非所有技术债务都是平等的，因此应该优先考虑在特定时间内要解决的问题以及先不解决的问题。存在于经常使用和更改的部分代码中的“垃圾”，就比在几乎没有使用或更改过的部分代码中的“垃圾”要严重得多。

高息债务往往是那些在项目中起重要作用的核心部分，通常围绕它进行了很多工作并以此为基础。如果此部分的技术债务没有解决，就会妨碍所有的工作，并可能迫使其他部分的代码背上更多的技术债务。因此，如果有可能，首先应优先考虑这些问题，并在后续使一切变得更加顺畅。

童子军规则

“要始终保持营地比你发现它的时候更清洁”也是适用于软件开发的：“提交的代码要比检出的更好”。鼓励团队成员，以积极减少技术债务 ; 例如，当他们发现了为了功能增加或错误修复的代码时，激励他们重构这部分代码。

当然，它不能没有边界，否则它可能会无止境的消耗时间。但是，如果你在每个sprint中留出一定比例的时间，专门用于修复开发人员发现的任何技术债务，那么它可以在很大程度上保持产品尽可能无债务。

在履行有价值的客户工作时偿还债务

在项目的整个sprint阶段修复技术债务不是一个好主意。一方面，客户往往不喜欢延期，对他们来说，看起来你似乎花了他们的时间和金钱来解决你的错误。另一方面，它也表明你已经因技术债务所累而做了大量工作，所以你可能已经为了债务付出了超出必要的代价。

最好限制在每个sprint中偿还技术债务所花费的时间，并用它来解决高优先级或突然遇到的问题。让客户满意，并使技术债务处于可控水平。

忽略

同样重要的是，要注意并不是所有技术债务都应该偿还。当产品接近其使用寿命时，如果它是短期使用或者只是一次性原型时，技术债务不是主要问题。这些实例很少见，但是当它们出现时你可以节省一些时间和精力。

结论

技术债务是伴随着项目出现而且无法避免，但是如何保持其在可控范围之内，是我们应该思考的问题。技术债务的避免和消除都需要优秀的开发人员，人始终是软件开发中最重要的因素。作为一名普通的码农，不断地提升自己是非常必要的。

---

本文主要译自：

TECHNICAL DEBT: EVERYTHING YOU NEED TO KNOW, AND HOW TO MANAGE IT （https://codingsans.com/blog/t...）

作者：Gábor Zöld
编译：TalkingData Robin

其他参考资料：

技术负债（https://zh.wikipedia.org/wiki...）

技术债治理的四条原则（https://insights.thoughtworks...）

解析技术债务（https://www.infoq.cn/article/...