技术债务

每个人都尽力从头开始编写优秀的代码。可能没有一个程序员会故意编写不干净的代码来损害项目。但是在什么情况下，干净的代码会变得不干净呢?

关于不干净代码的“技术债务”的比喻最初是由Ward Cunningham提出的。

如果你从银行贷款，这可以让你更快地购物。你要为加快这个过程支付额外的费用——你不仅要偿还本金，还要偿还贷款的额外利息。不用说，你甚至可以积累如此多的利息，利息的金额超过你的总收入，使全额还款成为不可能。

同样的事情也会发生在代码中。不为新特性编写测试可以暂时加快速度，但这将逐渐减缓您每天的进度，直到您最终通过编写测试来还清债务。

技术债务的原因

有时业务环境可能会迫使您在功能完全完成之前推出它们。在这种情况下，补丁和拼凑将出现在代码中，以隐藏项目未完成的部分。

有时候，你的雇主可能不理解技术债务是有“利息”的，因为它会随着债务的积累而减缓开发的速度。这使得将团队的时间投入到重构上变得非常困难，因为管理层看不到重构的价值。

在这种情况下，项目更像是一个整体，而不是各个模块的产物。在这种情况下，对项目一部分的任何更改都会影响到其他部分。团队开发变得更加困难，因为很难隔离单个成员的工作。

缺乏即时反馈鼓励了快速但有风险的变通方法或拼凑。在最坏的情况下，这些更改在没有任何事先测试的情况下被实现并部署到生产环境中。后果可能是灾难性的。例如，一个看似无害的修复程序可能会向成千上万的客户发送奇怪的测试电子邮件，甚至更糟糕的是，刷新或损坏整个数据库。

这减慢了向项目引入新人的速度，并且如果关键人员离开项目，可能会使开发陷于停顿。

如果知识库没有分布到整个公司，人们就会以对过程和项目信息的过时理解而结束工作。当初级开发人员被导师错误地培训时，这种情况可能会加剧。

这可能导致技术债务的积累，然后在合并更改时增加技术债务。单独进行的更改越多，技术债务总额就越大。

项目的需求是不断变化的，在某些时候，代码的某些部分可能会变得明显过时，变得麻烦，必须重新设计以满足新的需求。

另一方面，项目的程序员每天都在编写新的代码来处理过时的部分。因此，重构延迟的时间越长，将来需要重做的依赖代码就越多。

当每个参与项目的人都按照他们认为合适的方式编写代码时(即他们编写上一个项目的方式)，就会发生这种情况。

这是指开发人员不知道如何编写像样的代码。