refactoring.guru--重构--技术债务

技术债务

每个人都尽最大的努力从头开始编写出色的代码。项目中一般不存在故意写垃圾代码来损害项目的程序员。那么整洁代码变得杂乱无章的原因是什么呢？

Ward CunningHam最初突出了关于不干净代码是技术债务的隐喻。

如果你从一个银行里贷款，这样会让你购物更快。在加快处理进程的时候你付出了额外的费用。你不仅支付本金，而且也支付了贷款额外的利息。更不用说，如果你可能会累计太多利息导致利息金额超过你的总收入，以至于无法全额还款。

这些事情同样发生在编码中。在开发新特性的时候你可以不写测试来短暂加快开发进度，但是它每天会渐渐的减慢你的进度直到你最终通过编写测试来消除债务。

技术债务产生的原因。

一、商业压力

有时商业情况会强迫你在特性还没开发完毕之前推出新的特性。这种情况下，项目未完成的地方会隐藏补丁和污点即bug。

二、缺乏对技术债务后果的理解

有时候，你的boss或者领导并不能理解技术债务时产生的。当技术债务累积时会减慢开发的节奏。因为管理者看不到重构的价值所以不会让团队花时间在重构上。

三、无法处理组件严格的一致性（项目耦合太严重，没有拆分）

当项目是整体而不是由部分模块组成的时候。这种情况下，对项目任何一个地方的修改都会影响其他部分。团队开发会更困难，因为很难隔离各个成员的工作。

四、缺乏测试

缺乏及时反馈会导致快速但由风险的解决方法或污点。最坏的情况下，无需任何事先测试就将这些变更实施部署到生产环境中。这样的后果可能是灾难性的。例如，看起来无害的修补程序可能会给成千上万的顾客发送奇怪的测试邮件，甚至更糟，刷新或者损坏整个数据库。

五、缺乏说明文档

缺少说明文档会让新加入项目的人难以理解项目，并且如果开发的关键人物离开了，会使项目陷入停顿。

六、团队成员缺乏互动

如果团队不积极开展知识分享活动，大部分人对项目的流程和信息的理解可能会过时。当新成员受到导师的错误培训时，情况会加剧。

七、不同分支长期的同步开发

合并分支的时候会导致技术债务积累，独立的修改越多，技术债务总额越大。

八、延迟重构

项目需要不断变化和更新，某些时候，有些代码已经很明显过时了变得繁琐，必须重新设计以满足新的要求。

另一方面，该项目的程序员每天都在编写和老代码一起工作的新代码。因此，重构的延迟时间越长，未来需要重做更多的依赖代码

九、缺乏编码规范

这种情况发生在缺少编码规范，每个在项目上工作的人都有自己一样的编码方式的

十、能力不够

这种i情况发生在开发人员不知道如何去编写像样的代码