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

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

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

什么是技术债务？

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

摘自维基百科框架

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

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

可是须要清楚的是，技术债务是没法消除的，你必须随时作好承担技术债务的准备。由于在一些项目场景中，一些具体问题的解决方案自己是能够解决问题的，可是该方案可能不是全局有效或最佳的，在系统的其余方面，就造成了一个不可避免而必须承担的技术债务问题。一个好的工程师团队应该是最小化技术债务影响，并对技术债务进行合理管理的团队。测试

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

另外还能够将技术债务分类为鲁莽型技术债务和谨慎型技术债务 。一些谨慎型的技术债务在项目的进度中是可取的，可是不管是那种技术债务，都须要每一个人用于去承担，二者是共同工做的。理想的状况下，承担的债务应当是哪些有意的和谨慎的技术债务，而哪些无心的和鲁莽的技术债务应当不惜一切代价避免。编码

为何要关心技术债务？

! spa

技术债务如何影响开发

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

技术债务如何影响客户

虽然乍看起来，技术债务和客户并没有联系，客户也不太关心产品的代码质量等，客户只须要在成本没有增长的状况下，产品按时交付使用。然而，一个携带无心或者鲁莽的技术债务的产品在开发过程当中，每每须要花费更多的时间、精力和资源，致使成本增长，可是收益却减小的状况等。

技术债务如何影响用户

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

技术债务最佳实践

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

可是这里有一些你能够作的事情：

保持最新状态

不言而喻，工具，框架和库应该始终保持最新状态，可能你还未意识到这个问题所带来的影响，那只是你还没意识到而已。

文档

记录须要修复或更新的全部内容是确保实际修复和更新的最重要步骤。

若是存在技术债务，最好了解它并确保团队或将来的开发人员也知道。文档减小了定位和修复任何问题所需的工做量，若是债务记录良好，甚至可能在业务层面上可见，将可能致使客户认可并提供额外资源。

代码评审

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

可是，代码审查也有其缺点。开发人员每每太忙，没法深刻挖掘他人的代码，所以他们只会发现明显的错误，而挑剔可能会致使团队内部紧张。所以，它能够成为减小技术债务的有力工具，但应该谨慎应用。

自动化测试

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

敏捷架构

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

有效地复盘

若是出现问题，应该用于面对，当问题解决后，须要进行有效地复盘。可是要注意的是复盘是为了提升工做效率，毫不应该是找人责备。复盘的重点应放在了解问题及其产生的缘由上，以便团队能够采起必要措施防止一样的问题再次发生。

管理技术债务的最佳作法

即便你作了以上全部事情，并尽量避免堆积技术债务，你仍然须要处理一些问题。这是没法避免的，所以您应该实施实践和流程以防止技术债务陷入困境。

高息技术债务优先

并不是全部技术债务都是平等的，所以您应该优先考虑在特定时间解决的问题以及不解决的问题。对于常用和更改的代码而言，比在几乎没有使用或更改过的部分的重要性要重要得多。

高息债务每每是那些在项目中起重要作的核心部分，一般围绕它进行了不少工做并以此为基础。若是此部分的技术债务保持不变，就会妨碍全部的工做，并可能迫使更多的技术债务被添加到代码的其余部分。所以，若是有可能，首先应优先考虑这些问题，从长远来看，使一切变得更加顺畅。

童子军规则

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

固然，它不能没有边界，不然它多是一直消耗。可是，若是你在每一个sprint中留出必定比例的时间专门用于修复开发人员可能发现的任何技术债务，那么它能够在很大程度上保持产品尽量无债务。

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

在项目的整个冲刺阶段，用于修复技术债务不是一个好主意。一方面，客户每每不喜欢延期，对他们来讲，看起来你彷佛花了他们的时间和金钱来解决你作错的事情。另外一方面，它也代表你已经作了大量的技术债务工做，因此你可能已经支付了更高的债务利息。

你最好指定在每一个冲刺中偿还技术债务所花费的时间，并用它来解决高优先级或发生过的问题。让客户满意，并使技术债务处于可控水平。

忽略

一样重要的是要注意技术债务不该该老是获得偿还。当产品接近其使用寿命时，若是它是短时间制造的，或者它是一次性原型，技术债务不是主要问题。这些实例不多见，可是当它们出现时你能够节省一些时间和精力。

结论

技术债务是伴随着项目的，没法避免，可是如何保持其在可控范围以内，是咱们应该思考的问题。技术债务的避免和消除都须要好的优秀的开发人员，人始终是软件开发中最重要的因素。做为一名普通的码农，不断地提高本身是很是必要的。