代码重构一（概述）

代码重构—概述

一.技术债务（重构的重要原因）

  关于“技术债务”的比喻最初是由Ward Cunningham提出的，如果您从银行获得贷款，这可以让您更快地购物，您需要为加快流程支付额外费用，不仅需要还清本金，还需要支付额外的贷款利息，甚至利息金额超过您的总收入，以至于无法全额偿还。代码也会发生同样的事情。您可以暂时加速而无需为新功能编写测试，但这会逐渐减慢您的进度，直到您最终通过编写测试来偿还债务。

技术债务的原因

1.交互压力大

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

2. 缺乏对技术债务后果的理解

有时候，你的上司可能不会理解技术债务的“利益”，因为随着债务积累，它会减缓发展速度。这可能会让团队的时间专注于重构太困难，因为管理层没有看到它的价值。

3. 未能对抗组件的严格连贯性

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

4. 缺乏测试

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

5. 缺乏文档

这减慢了新人员进入项目的速度，并且如果关键人员离开项目，可能会使开发停滞不前。

6. 团队成员之间缺乏沟通

如果知识库没有在整个公司内分享，那么人们最终会对过程和项目信息的过时理解。

7. 多个分支长期同步发展

这可能导致技术债务的累积，然后在合并变非常困难。每个分支变化越多，技术债务总额就越大。

8. 延迟重构

项目的要求在不断变化，在某些时候，部分代码可能已经过时，变得繁琐，必须重新设计以满足新的要求，另一方面，该项目的程序员每天都在编写与过时部分一起使用的新代码。因此，延迟重构的时间越长，将来必须重新编写更依赖的代码。

9. 缺乏合理的监管

当项目中的每个人都按照自己认为合适的方式编写代码时，就会发生这种情况。

10. 开发人员技术水平

这是开发人员不知道如何编写体面的代码。

二.何时重构

1.添加功能时

重构有助于您了解其他人的代码。如果你必须处理其他人的脏代码，请先尝试重构它。清洁代码更容易掌握。你不仅要为自己而且为那些在你之后使用它的人改进它。重构可以更轻松地添加新功能。在清洁代码中进行更改要容易得多。

2.修复bug时

代码中的错误与现实生活中的错误一样：它们生活在代码中最黑暗，最脏的地方。

3.在代码审查期间

代码审查可能是在代码公开之前整理代码的最后机会。最好与作者一起进行此类评论。通过这种方式，可以快速解决简单问题并确定修复更困难问题的时间。

三.如何重构

1.每次重构只该一小部分

重构应该作为一系列小的更改来完成，每个更改使现有代码略微更好，同时仍然使程序保持正常工作。

2.重构期间不应创建新功能。

不要混合重构和直接开发新功能。尝试至少在各个提交的范围内分离这些过程。

3.所有已有测试必须在重构后能通过。