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

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

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

什么是技术债务？

技术负债（英语：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/technical-debt）
  

做者：Gábor Zöld

编译：TalkingData Robin

​

其余参考资料：

• 技术负债（https://zh.wikipedia.org/wiki/%E6%8A%80%E6%9C%AF%E8%B4%9F%E5%80%BA）
  

• 技术债治理的四条原则（https://insights.thoughtworks.cn/managing-technical-debt/）
  

• 解析技术债务（https://www.infoq.cn/article/2009/10/dissecting-technical-debt
  

​