你的技术债还了吗？

什么是技术债？

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

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

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

紧急任务分为两种情况

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

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

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

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

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

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

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

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

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

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

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

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

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

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