“欠债还钱，天经地义“ 这是一个自古不变的道理，在现实生活中大家都明白这么一个道理，遵循着这样的游戏规则，俗话说,好借好还再借不难。如果你不还的话，那么债主一定会盯着你要，会通过各种手段、方法提醒你该还钱了。

在系统世界中我们做系统开发时也会有各种各样的原因，产生所谓的“技术债“。

系统的技术债就非常的隐晦了，不像现实生活中能够很清晰的感知到。现实生活中我向你借了100块，那么就是欠了100块债务，债权关系清楚明了。但是在系统开发中，有的时候你可能都不知道你已经欠了债。

“欠债还钱”这条法则在系统世界中同样适用，只不过它不会像现实世界中的债主追到你的门口，告诉你该还钱了，让你感觉非常强烈。系统技术债的债主也就是系统本身会用他自己独特的方式告诉你，“该还债了”。

最近我隐约的感觉到收到了这种通知，表现症状是最近一个周以来，平均每天都要处理1~2个线上的事故问题。

事故为什么会频繁找上门，这是系统对你追债的一种表达方式。他在提醒你再不处理技术债，后面可能就不仅仅是还点利息的问题了。。。

那么什么是技术债？为什么会产生技术债呢？

提到互联网，大家都会想到“天下武功唯快不破”。也就是说开发过程越快越好，越快越有竞争力。在现实世界中确实也有很多这方面成功的案例。所以在实际系统开发过程中，有的时候往往为了快而选择走了各种捷径。

走捷径的好处是表面上看起来确实达到了效果。很短的时间内系统功能就开发实现了，但是往往会存在根基不稳的隐患。这种隐患越到后面就会越明显的体现出来。

那么简单来说，技术债就是在开发产品新功能的过程中，没有使用最佳的实践方法而引入的技术问题，通常的表现形式就是临时方案。

技术债，最主要是由两方面因素导致的。

1.主动引入。也就是开发人员知道某一事件会产生技术债，但仍然采用这样的方式去实现。最常见的情况就是由于业务产品的压力，要在时间和资源受限的情况下，不得不做出质量的牺牲。

最常见的场景就是产品经理找到开发说：”这个需求下个星期就要上，对公司有着重大的意义。”这个时候开发人员没有别的选择，只能想办法尽快实现这个功能。

做任何一个项目都会涉及到时间、成本、范围、质量这4个要素。就是我们常说的“多、快、好、省”，现实中这4样想同时占着，那是不可能的，最多只能选两样。

在上面的例子中，时间已经被确定（下周必须上线），范围也明确（产品提出的具体新功能），成本在短时间内很难有大的变化（有的时候即使通过加人短时间内也无法快速上手新业务，只能通过现有的人力进行支持），那么最终牺牲的只能是质量。这里说的不是用户体验的质量，而是代码的质量，这时候一个技术债就这样产生了。

2.被动引入。就是不是开发人员主动引入的，这种情况一般分为以下两种。

一种是产品不断的演化，技术不断的发展，原来的设计落伍了。这是一种比较难避免的情况。很难有人能够设计出一个能够满足未来5年或10年业务发展的一个系统，因为首先就很难预测5年或10年之后业务会发展成什么样子。

第二是开发团队的能力和水平有限，没有采用好的方法和实践。导致在做项目的时候埋了很多坑。

通过上面两点的分析不难看出在实际工作中很难避免技术债的产生，那么下一个问题就是我们应该如何处理技术债的问题。

在谈解决方案之前，我们要先搞清楚技术债会有哪些影响的问题。如果影响不大，其实我们也没必要去处理的。如果影响很大，后果很严重，那么我们就要提高优先级投入资源快速地去解决它。

我们可以把技术债对应着金融领域的经济债务来类比。跟经济债务一样，技术债也需要偿还，并且也会产生利息，而且是利滚利。

技术债的“利息”，就是在后面对系统做修改的时候，需要额外的时间成本。

举个例子，一个维护良好的架构，在添加一个新的功能可能只需要2天时间，但是随着项目不断维护，因为各种原因而走了很多的“捷径”，那么这个时候再开发一个同样复杂度的功能可能就需要3天了。这多出来的1天，就是技术债造成的利息。因为你需要时间去处理臃肿的代码，找到合适的位置去添加代码。修改后的代码可能还导致原有系统不稳定，还需要额外的时间去修复系统不稳定的问题，从而进入了这样一个恶性循环。一切都是源于最初的那个“捷径”。

但其实技术债也不完全都是坏处。我们都知道经济债务最明显的好处在于可以帮助我们完成本来不可能完成的任务，比如贷款买房。企业经营过程中也会不可避免的有一定的债务。通过引入一定债务的方式来引入足够的资金，帮助企业在短时间内能够快速发展。相应的，技术债也可以在短时间内帮我们快速完成业务开发，满足业务用户的需求。这种场景往往适用于新的业务线。新的业务线就是要能够快速的上线，快速的试错。这个时候就可以大胆的举债前进，如果业务做好了，后面可以再慢慢还债。如果业务没做起来，那么直接相当于破产，欠的债也不用还了，这条线直接就下掉了。

那么搞清楚了技术债的影响之后，应该如何处理呢？

是不是要把所有的技术债全部清零消灭掉？我的看法是不需要，并且实际上也很难做到。

处理技术债，我觉得做好下面两点就可以了。

第一点是要利用好技术债的好处，在必要的时候要大胆举债前行。

技术最终还是为业务服务的，只有业务做好技术才有存在的价值。像上面提到的新业务新场景那么就可以放心大胆的快速实现，先不用太关心技术债的问题。

第二点是要控制技术债的比例。类似企业的资产负债表一样，要严格控制负债的比例，将风险控制在一个合理的阈值内。这个阈值要各个系统领域的负责人心理有一杆秤，要清楚的知道当前系统的技术债情况，判断合适的还债时机。

但实际情况往往是大家忽略了技术债的管控，等到系统提醒我们的时候，可能就已经晚了，损失以及事故已经发生了。

所以总结下来就是，技术债一定会在系统中长期存在，但是要控制好比例，要能够有手段去识别技术债，并找到可能的解决方案。

如何识别技术债？

如果你的系统已经出现开发迭代周期越来越慢，并且越来越难以维护，线上的问题越来越多，那么这个时候就有必要停下来反思一下是否存在技术债了？是不是该还债的时候到了？

对于研发人员主动引入的技术债，我们自己要有一个小本本记录下来，要明确的知道自己欠了哪些债，清楚的知道自己系统的负债情况，才能够做还债的计划以及方案。

对于被动引入的技术债，这个只能要想办法提升团队的整体技术水平，从而发现之前设计的不合理的地方。

最后引用李善友教授的一句话作为结尾。“如果你现在不觉得一年前自己是个蠢货，那么说明你这一年什么也没有学到。”