重构不必谈之色变。

它也不是洪水猛兽，而是开发过程中持续进行的优化过程。让我们开始学习这个主题，重新认识它的价值。

🌟整洁代码

重构的主要目的是消除技术债务。它将混乱变成整洁的代码和简单的设计。

• 对于其他程序员来说，整洁的代码是显而易见的。

我并不是在谈论超级复杂的算法。糟糕的变量命名、臃肿的类和方法、魔法数字 - 等等，所有这些都会让代码变得混乱和难以理解。

• 整洁的代码不包含重复。

每次你需要对重复的代码进行更改时，你都必须记住对每个实例进行相同的更改。这会增加认知负担并减慢进度。

• 整洁的代码包含最少数量的类和其他活动部件。

代码越少，脑子里需要记住的东西就越少。代码越少，维护工作就越少。代码越少，错误就越少。代码就是责任，保持代码简短。

• 整洁的代码通过所有测试。

如果只有 95% 的测试通过，你就知道代码不整洁。如果测试覆盖率为 0%，你就知道你完蛋了。

• 整洁的代码维护成本低！

🗑️技术债（What）

每个人都尽最大努力从头开始编写出色的代码。可能没有程序员会故意编写不干净的代码，从而损害项目。但是干净的代码在什么时候会变得不干净呢？技术债产生的原因

• 业务压力

有时，业务情况可能会迫使您在功能尚未完全完成时就推出它们。在这种情况下，代码中会出现补丁和临时解决方案，以隐藏项目未完成的部分。

• 缺乏对技术债务后果的了解

有时你的雇主可能不理解技术债务是有“利息”的，因为债务越积越多，开发速度就越慢。这会让团队很难抽出时间进行重构，因为管理层看不到重构的价值。

• 无法对抗组件的严格一致性

当项目看起来更像是一个整体，而不是由多个模块组成的产品时，这种情况就会发生。在这种情况下，对项目某一部分的任何更改都会影响其他部分。团队开发变得更加困难，因为很难将各个成员的工作区分开来。

• 缺乏测试

缺乏即时反馈会促使人们采取快速但风险很大的临时解决办法或临时解决方案。最糟糕的情况是，这些更改未经任何事先测试就直接实施并部署到生产中。后果可能是灾难性的。例如，一个看似无害的修补程序可能会向数千名客户发送一封奇怪的测试电子邮件，甚至更糟的是，刷新或破坏整个数据库。

• 缺乏文档

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

• 团队成员之间缺乏互动

如果知识库没有在整个公司内传播，人们最终将以过时的流程和项目信息理解工作。当初级开发人员接受导师的错误培训时，这种情况可能会加剧。

• 多个分支长期同步发展

这会导致技术债务的积累，而当变更合并时，技术债务会进一步增加。单独进行的变更越多，总技术债务就越大。

• 推迟重构

项目的需求在不断变化，在某些时候可能会发现部分代码已经过时、变得繁琐，必须重新设计才能满足新的要求。另一方面，项目的程序员每天都在编写与过时部分兼容的新代码。因此，重构推迟的时间越长，将来需要重新编写的依赖代码就越多。

• 缺乏规范监控

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

• 水平参差不齐

这是因为开发人员不知道如何编写合适的代码。

查看原文：https://refactoringguru.cn/refactoring/technical-debt

📅何时重构（When）

三条规

1. 当你第一次做某事时，优先完成。
2. 当你第二次做类似的事情时，你会因为必须重复而感到畏缩，但无论如何都要做同样的事情。
3. 当你第三次做某件事时，开始重构。

添加功能时

1. 重构有助于理解其他人的代码。如果必须处理其他人的混乱代码，请先尝试重构它。整洁的代码更容易掌握。你不仅可以为自己改进它，还可以为那些在你之后使用它的人改进它。
2. 重构使添加新功能变得更容易。在干净的代码中进行更改变得容易得多。

修复错误时

1. 代码中的错误就像现实生活中的错误一样：它们存在于代码中最黑暗、最肮脏的地方。清理代码，错误几乎会自行发现。
2. 老板很欣赏主动重构，因为它消除了以后进行特殊重构任务的需要。

在代码Review期间

1. 代码审查可能是在代码向公众发布之前整理代码的最后机会。
2. 最好与作者一起进行此类评审。这样，你可以快速修复简单问题，并估算修复较困难问题的时间。

查看原文：https://refactoringguru.cn/refactoring/when

📋如何重构（How）

重构应该作为一系列小的改变来完成，每个改变都会使现有的代码稍微好一些，同时仍然保持程序的正常运行。

完成重构好：清单

• 代码应该变得更清晰。

如果代码在重构后仍然不干净……那么，对不起，但您已经浪费了一个小时的时间。尝试找出原因。当你放弃小改动的重构，而是将一大堆重构混入一个大改动中时，这种情况经常发生。所以很容易失去理智，特别是如果你有时间限制。但当代码非常粗糙时，这种情况也可能发生。无论你如何改进，整个代码仍然是一场灾难。在这种情况下，值得考虑完全重写部分代码。但在此之前，您应该编写测试并留出大量时间。否则，您最终会得到我们在第一段中讨论的结果。

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

不要将重构和直接开发新功能放在一起，比如单个 git 提交仅包含新功能或仅包含重构。

• 重构后，所有现有测试必须通过。

重构过程中犯了一个错误。这个很简单：继续修复错误。测试代码粒度非常细。此时可以重构测试本身，也可以编写一组全新的高级测试。避免这种情况的一个好方法是编写BDD 风格的测试。

查看原文：https://refactoringguru.cn/refactoring/how-to