首次听到技术债这个名词，是在2021年末，那时我刚入职新单位，头儿让我负责DevOps的推广工作。尽管，在此之前我没有接触过DevOps，但工作已经分配下来，我只能硬着头皮开始自学DevOps的相关知识，在学习过程中，我第一次接触到了“技术债”这个词，其中“债”这个字眼，让我瞬间对其产生了兴趣。这里不得不简单说明一下，16-18年期间，我在上一家公司负责信贷类科技产品的研发和售前工作，对于信贷业务非常熟悉，而人们通常将信贷简单的理解为“债”。我很清楚资金方面的债是什么，但什么是技术债？它为什么有这样一个名字？它是怎么产生的？它有什么特点？它带来了怎样的影响？这些问题瞬间就出现在我的脑子里，并且在我推广DevOps的工作中不断展现它的身影，让我对它的认识逐渐加深。而另一方面，我在跟同行交流中发现，大家对技术债的理解不尽相同，有的时候甚至会南辕北辙，也经常会从有利于自己的工作的角度去定义技术债，去决定如何面对和解决技术债，而效果往往差强人意。所以，为了帮助大家更好的了解技术债，我将我个人的理解、研究汇总成文，来跟大家谈谈技术债。

　　本文将会从以下七个方面来对技术债进行探讨，囿于篇幅所限，文章会按章节分开发

　　技术债的概念技术债的根因分析技术债的特点、要素和类型技术债带来的影响如何看待技术债如何解决技术债技术债不是什么

　　本文内容为作者个人一家之言，并非放之四海而皆准，欢迎交流探讨，也欢迎各位看官老爷提出宝贵意见。

　　1、技术债的概念

　　研究问题，总要先弄清楚问题是什么，所以我们需要先知道如何定义技术债。大家百度百科一下，就会看到下面这段文字：

　　技术债（Technicaldebt），也称为设计负债（designdebt）、代码负债（codedebt），是编程及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。

　　沃德·坎宁安

　　上述概念是沃德·坎宁安在1992年首次提出的，wiki的概念也是这哥们提出的。这也是比较传统的技术债的概念。他认为：第一次发布代码，就好比借了一笔钱。只要通过不断重写来偿还债务，小额负债便可以加速开发。但久未偿还债务会引发危险。复用马马虎虎的代码，类似于负债的利息。整个部门有可能因为松散的实现，不完全的面向对象的设计或其他诸如此类的负债而陷入窘境。

　　随着软件工程的不断发展，新的软件工程理论和实践不断涌现，技术债这个概念也在不断的扩充，架构、性能、规范、管理等更多类型的问题不断被纳入到技术债的范畴中，传统的技术债概念已经没法很好的解释日趋复杂的软件工程问题。

　　我个人认为，技术债是研发人员/团队/组织在特定条件下，为了满足交付时限而主动做出的妥协的总和。如果从我这个技术债概念出发，会带来几个问题，特定条件都是什么条件？都会做出哪些妥协？带着这些问题，我们下一篇继续。