51 | 技术债务，有意或无意的选择？

替前人还债中，当那天不能带来我成长时，我会离开

现在项目组正在重构我们的核心项目，系统使用每天，不过业务运营比较费劲，特别是特殊时期时，重复操作重复验证工作比较多，我们重构后，希望能够减轻一些运营成本。

遇到产品快速迭代的时候，产品的需求在代码的实现来看就像是打补丁的实现，局部的快速迭代往往会会忽略整体性，当产品流程过长，后来的补丁对于前面的实现大都都像是债务的累积，或如果后面加进来的补丁没有考虑前面的实现，某一天债主就会找上门来了。这种算技术债务吗？

常常因为工期和变更的原因引入债务。 如果决策的人能明白这些债务的存在和代价，那真的要谢天谢地了^_^ 遇到的客户，那些不太懂软件的，反而觉得软件改起来简单，举起例子来一套一套的。。。

观后感： 所谓债务，归根结底是成本和收益的权衡。当初产生负债时，短期收益明显高于成本，故使用之。从长期来看，成本又大于收益，故需要及时偿还之。同时，负债除了本金外，还有利息，当利息越滚越大，甚至盈利无法覆盖时，系统就岌岌可危了。跟经济活动类似，当盈利连利息都无法覆盖时，就会爆发债务危机，进而经济危机。

为了加载数据更快，前人在provider进程当中实现了一个内存数据库，随着业务的增长，内存数据库越来越复杂，还出现了数据丢失和不一致的情况，这个债务已经还不起了

技术债务和现实中的债务一样，用得好了可以利用杠杆为业务提速，用得不好没控制住则会让技术破产

知道引入了哪些债务，多少债务，何时偿还是关键，更多情况下往往是债务危机爆发时才发觉。

这几年一直在维护一个老系统，当你盯着它看了很久后，多少还是会有一些想法和思路沉淀下来。能偿还一部分债务的

我们交付的系统既是资产也是债务。 不存在没有债务的系统。 资不抵债，会破产。 系统的资产与债务思想可以作为一个衡量标准，衡量一个团队是不是值得加入。 如果这个团队没有系统的资产与债务思维，那么他是看不到系统的债务的，就不会考虑还债，债务一直累积，直到破产。