技术债务

每个人都尽最大努力从头开始写出优秀的代码。可能没有程序员会故意编写不干净的代码来损害项目。但是什么时候干净的代码会变得不干净呢？

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

如果您从银行获得贷款，这使您可以更快地进行购买。您需要为加快流程支付额外费用 - 您不仅还清了本金，还还还清了贷款的额外利息。毋庸置疑，您甚至可以累积如此多的利息，以至于利息金额超过您的总收入，从而使无法全额还款。

代码也会发生同样的事情。你可以在不为新功能编写测试的情况下暂时加快速度，但这会逐渐减慢你每天的进度，直到你最终通过编写测试还清债务。

技术债务的原因

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

有时，您的雇主可能不明白技术债务具有“利息”，因为随着债务的积累，技术债务会减慢发展速度。这会使团队将时间用于重构变得太困难，因为管理层看不到它的价值。

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

缺乏即时反馈会鼓励快速但有风险的解决方法或混乱。在最坏的情况下，这些更改是在没有任何事先测试的情况下实施和部署到生产中的。后果可能是灾难性的。例如，一个看起来无辜的修补程序可能会向成千上万的客户发送一封奇怪的测试电子邮件，甚至更糟的是，刷新或损坏整个数据库。

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

如果知识库不分布在整个公司，人们最终将对有关项目的流程和信息有过时的理解。当初级开发人员被他们的导师错误地培训时，这种情况可能会加剧。

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

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

另一方面，该项目的程序员每天都在编写与过时部分一起使用的新代码。因此，重构延迟的时间越长，将来必须返工的代码就越多。

当每个从事项目的人都按照他们认为合适的方式编写代码时（即他们编写上一个项目的方式相同），就会发生这种情况。

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