技术债是一个借用了财务债的绝妙隐喻（极限编程XP的实践之一），表示当我们为了短期利益（如按时完成开发），而在技术上对软件的长期质量进行的妥协。它一般用于项目管理，但其实也广泛地存在于各个地方，比如每个人的身上。

项目的技术债

技术债的起源和后果、解决方式等，网上一搜一大把，我这里就不再赘述了。这里总结一点常见的误区：

• 技术债是邪恶的：这里借用维基百科的一小段话：“第一次发布代码，就好比借了一笔钱。只要通过不断重写来偿还债务，小额负债可以加速开发。但久未偿还债务会引发危险。复用马马虎虎的代码，类似于负债的利息”。健康的债务是好事，谁买房子不贷款（土豪请随意）？
• 技术债必须偿还：有时候你写一段小程序，只希望尽快跑起来看看，然后将之抛弃。程序由于没有重构，而充斥着各种反模式（它们都是技术债！）。我自己就写了不少，用毕即弃。这里面的债……反正我自己是没有兴趣也没有时间偿还。有些项目的代码，你知道永远也不会有人会动（当然这个很主观，并且取决于你的经验），或者是很快就要完蛋的，我也倾向于先不还这个债，真的到了出现万一的时候，那就再还吧。还债是有成本的，如果感觉还债成本将要上升，也许就应该还这个债了。有没有一种lazy的感觉？
• 开发新功能优先于偿还技术债：这是一个it depends的问题，谁高谁低取决于对债和利息的判断及不同角色间的博弈。如果利息趋近于零，当然可以先不考虑还债；如果新功能的投资预期带来大把的收益，当然可以先开发新功能。
• 技术债可以避免：如果这样的话，只要没有新功能，就永远不必发新版本了。没有完美的人，没有完美的程序。别想躲开它，想想怎么处理它。

个人的技术债

Martin Fowler把技术债分为四个象限，如下图所示：

项目在不断前进，做项目的人也是不断前进的。项目需要还债来让自己运转良好，人不也一样需要还债让自己进步吗？参考上图，我也画了张个人的技术债四象限，如下图所示：

这四个象限不都是技术债的源头吗？下面我们来具体分析一下每一个象限：

有意的－慎重的：清理。例如，我知道项目上需要用到drools，它对未来的项目可能会很有用，可惜当时没条件深入学习。又或者项目上用到了JJTree，它有些过时了，以后也基本用不上，不需要浪费时间在这上面。这是两个不同的例子，因为你是有意地做出了选择，所以凭你的经验来决定吧，是否应该把它放到你的个人技术债上。
有意的－草率的：思考。例如，当时工作太忙，虽然知道docker能够解决这个问题，但没时间去学，至于项目嘛，凑合能用就好了。现在回头想想，还能凑合吗？因为草率，所以需要思考；因为有意，所以还要选择。是否放入你的个人技术债，你自己决定吧。
无心的－慎重的：复盘。例如，当时不知道其实AWS可以满足项目的需求，但是现在知道了，很可能用AWS可以节省一大部分的开发和运维成本，但也可能有坑。在这种情况下，我们可以做一次复盘，如果项目再来一遍应该怎样？把收获到的经验用到下一个项目中吧。
无心的－草率的：求知。例如，我并不知道前端技术大爆炸有那么多的框架可选，现在我也不太了解，反正有活儿我就上JQuery。用一句绕口的话总结就是：不知道自己不知道什么。如果是这样，那么就应该先高层次地了解一下背景知识，起码让自己不至于抓瞎吧。之后再慢慢将自己的知识体系建立起来。

接下来就该给你的债排优先级，用时间“四象限”法，XY轴分别是重要性和紧急性。重要又紧急的债先还；重要不紧急的债可以制定计划；紧急但不重要的，不值得投入大把的时间，够用就好；不重要不紧急的就尽量放弃吧，除非这个债是你的兴趣爱好之所在。

2017年已经远离，是不是在收获了许多成果的同时，也留下了一些遗憾？2018年的余额也已充值完毕，去年（说不定去了好几年呢）欠下的债，该考虑怎么还一还了吧？