什么是技术债？

技术债是由沃德·坎宁安在1992年提出，指我们在软件架构或代码编写过程中有意无意地做了错误的决策。随着时间的累积，这种错误会越来越多，就像背负了很多债务一样。

技术债的危害

技术债同财务债一样，是有利息的，还债的时间拖的越长，就需要支付更多的利息。很多临时性的代码、不合理的架构最终都会造成严重的后果，比如：

• 一个小的功能优化，可能会引发大面积的代码修改，大大提高了开发成本和测试成本，还很容易引入新的问题

• 在客户的生产环境上，数据量提升一个数量级时，会出现严重性能问题，就像是一个隐形炸弹，不知道什么时候会爆掉

• 历史代码都不敢修改和维护，最终代码越来越臃肿，无效代码越来越多

技术债的形成

以我们现在的产品代码来看，技术债的主要是以下几个原因造成：

紧急任务

紧急任务分为两种情况

1、有时需要有一些演示性的功能需要提前上线使用，主要用于售前
2、客户的交付时间压的很紧

上面的两种情况都将使我们放弃原本好的设计方案，为了能更快速地交付，而采用一些临时的方式去进行架构或代码等编写，并且要求在代码改动的地方写上 //TODO： 标记，表示此处是临时代码，最终是需要回来进行代码重构的。

实际情况是，代码中的 TODO 会越来越多，就像开发经常喜欢说的一句话一样：“暂时先这样，后面有时间再来进行优化”，然后就没有然后了。

缺少沟通

一个初级程序员在修改历史代码的时候，如果在没搞清楚代码逻辑和业务逻辑的情况下，不和团队成员进行沟通，就擅自修改代码，会产生两种结果：

1、出现的问题会被自动化测试或测试人员检查出来，当然，这是一种较好的情况
2、修改后有隐藏的问题没有被检查出来就发布到生产环境，这种是非常危险的

KPI考核

从8月开始，团队开始了 KPI 考核，目的是提高每个人的积极性，但如果每个人只是关注考核指标，就会出现「事不关己，高高挂起」的问题。长此下去，每个人的绩效可能都还不错，但产品代码中的坏味道会越来越多。

所以我鼓励团队中的每个人，只要嗅到坏味道，可以提出重构申请，写出自己的思路和方案，通过后会有额外的奖励。

技术债要避免吗？

上面说到技术债的种种危害，那么技术债一定要去避免吗？其实不一定，例如为了售前演示而快速推出的功能，这种债是必须的，因为可以快速交付，也许就是因为速度快而得到了一个商机。

但因为沟通原因而欠下的债是需要避免的，在团队协作中，任何时候，沟通都是要排在第一位的。

技术债的偿还

出来混，迟早是要还的，欠债也是一样，欠债并不可怕，只要定期偿还，也会是一个良性循环。就像我们按揭买房，每个月得按时还款。

目前能想到的一些偿还的方式：

1、代码提测前的Code Review是后面准备要做的，可以在很大程度上避免一些不必要技术债的产生
2、定期以任务的形式来解决产品代码中的 TODO 问题
3、沟通非常的重要，需要形成一种团队文化，充分的沟通也可以避免一些技术债的产生

总结

正确的看待技术债，正向的技术债不可避免，但需要定期偿还；负向的技术债需要尽量地减少。所以说技术债是需要合理的规划和管理的，这也是一个技术管理者需要修炼的技能。

你们的项目或产品中有技术债吗？

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com