通过不断改进代码的设计，我们使使用它变得越来越容易— Joshua Kerievsky，重构为模式
重构采用现有的，有效的代码，并使该代码更好。
好的，但是“更好”是什么意思？ 它意味着更好的结构，更好的构建，更易读和更易理解。
您的代码更易于使用，更容易添加新功能，更容易发现和修复错误，更易于扩展和维护，并且是阻止代码逐渐失去控制的一种方法。
什么是重构
如果您曾经看过一种方法，该方法变得太长了一点，并且发现其中的几行是在一起的，请将它们分成自己的方法。
然后将原始代码替换为对该新方法的调用。 好吧，这就是重构，那就是提取方法重构。
它是一些小型的独立 技术的集合 ，用于改进已经存在的代码。 该代码已经编写，并且已经可以使用。 我们没有改变它的作用。
这些单独的技术，每个都是一种重构技术，并且它们通常很小 ，并且每个都处理一个特定的常见问题 。
有一 组规则或一个特定的顺序 ，只是任何人都可以按照这样的事情。 但是有一组技术可以帮助您重构代码。
现在，如果您已经编写代码已有一段时间了，那么您几乎已经完成了其中的一些工作。 但是，使用正式的重构技术 ，可以使该决策更加自觉 。
它并不能取代您的直觉，但会给您带来更多问题 ：
- 如果您试图拆分一些代码，那么您真正要寻找的是什么？
- 当局部变量和非局部变量混合在一起时，您该怎么办？
- 有什么原因为什么您可能不将某些代码拆分为自己的方法？
—技术类别
思考重构技术的一种有用方法是了解重构技术可以根据它们所操作的代码的不同级别 分为几类 。
其中一些与单个方法本身有关，而不必担心类层次结构或设计模式。
然后，在重构过程中，我们会稍微高一些。 我们仍在研究方法，但现在对我们的类有了更多的了解 。 此方法在正确的类中吗？
而且，我们可以再上一个抽象层次，而不是将重点放在方法上，而是将重点放在不同类之间的通信上 。 除了使用类B的方法和属性外，类A似乎什么也没做吗？
我们甚至再上一层楼。 在面向对象的应用程序中确实有很多技巧。 是我们应该使用更多的继承和多态性，或者实际上应该使用更少的继承和多态性的线索？
您将看到几个重构，它们似乎是彼此完全相反的 。 一种重构技术的名称为“ Add Parameter”，而另一种名为“ Remove Parameter”。
毕竟，完全可以理解的是，您所需的技术有时与另一种相反。
什么重构不是
重构不是调试 。
您的代码已经需要工作。 这不是发现错误的方法，您应该在错误发生后立即修复。
因此，的确如此， 在重构过程中您可能会发现bug 。 但是，当您开始处理这一点时。 您已经停止了重构，并且已经开始进行错误修复 ，这是非常不同的思路。
重构不是性能 。
这是另一个非常普遍的误解，认为我们要清理代码，这将使其更快。
不，代码性能不是重构的目标，也不是期望。 但是，我们的表现是！ 。 我们将能够阅读代码并更快地理解它。 不仅是个别代码，而且是更大的应用程序。
重构未添加功能
如果在此过程中添加了新功能，则不再进行重构。 因为在重构过程中，我们不会更改代码的行为 。
我们可能在内部做很多事情，创建新类，将功能从一个地方移到另一个地方，重命名，重新组织。 但是重构过程的最终结果不会改变代码的可观察行为。
因此，任何以前使用我们的应用程序的最终用户都不知道我们做了任何事情。 我们没有修复错误，没有提高速度，没有添加功能。
为什么要使用重构
那么，为什么仍要进行重构？
好的，重构不是添加功能，重构不是发现错误，重构不是性能， 但是我们重构只是 因为我们想做这些事情 。
因为结构良好的代码将使添加新功能和新功能变得更加容易。 这将使开始分析性能变得更加容易。 因此，我们进行重构以摆脱未来的障碍。
我们之所以进行重构是有原因的。 如果没有理由进行重构，请不要这样做。
如果我们有很久以前编写并未修改过的应用程序。 它有效，足够快。 他们的任何其他系统都没有冲突，也不需要添加任何功能。
它可能是世界上最丑的代码，但是不需要重构。 因为这没有理由这样做。
在团队文化中 ，当团队的文化不属于团队文化时 ，通常很难获得批准以花时间进行重构，因为好处并没有立即显现出来。
是的，我们没有添加功能，我们没有提高性能，我们没有修复错误， 那么为什么要打扰呢？ 我们很麻烦，所以我们可以更轻松地做这些事情。
何时使用重构
重构是 不是一个独立的阶段。
当您第一次学习重构时，听起来就像您在独立阶段所做的一样。 您编写了一个应用程序，后来又对其进行了重构。
好吧，如果您现有的代码很混乱，则可能需要不时地执行此操作，但是这样做的目的是您始终开始执行此操作。
在编写代码时，即可以重构 。 您编写一个新类或一些新方法，进行检查和测试，然后花几分钟进行扫描，以确保可以将其重构。
在团队环境中，学习重构的一种好方法是使用代码审查或配对编程 。
使多组眼睛进入同一代码。 您会发现不同的人发现了不同的重构机会。
而且，如果您是一个单独的开发人员 ，则需要多加注意应用个体技术，尤其是那些您不会自然想到的技术。
如何重构
⚠…
我们不会深入研究每种重构技术，它试图解决的问题以及如何将其应用到代码中。 它们中的大多数都很容易理解，您可以在下面的“下一步去哪里”部分中找到它们。从常见的低级技术开始，一直到更高的级别。
- 步骤
首先， 您不需要了解所有重构，只需开始使用它们即可 。
实际上，要很好地学习它们，选择一些技巧并开始积极应用这些技巧更为实用。
在学习了其中的几种重构技术后，您会发现自己自然地编写了更多的模块化代码，更好的面向对象的代码，知道了放置功能或数据的正确位置。
那么，如何开始呢？ 从底层开始，从较低层次开始，基本重构，一直到最高。
重命名和提取方法，缩短参数列表，最大程度地减少无用的临时工等条件，使您的条件更易于阅读。
因此，当您查看代码的一部分时， 只需将其扫描两次即可 。
您所不需要的是可以在其中应用X重构技术的地方 。
您正在寻找的东西会引起您的注意 。 使此代码闻起来很糟的东西。 并且我们将其用作指标可以改进。 这就是 代码气味。
因此，重复的代码，较长的方法，较长的参数列表，过多的注释，并且该列表继续存在 。
但是，有些代码的气味不是来自扫描的 ，因此需要密切注意 。 诸如数据块之类的地方或下推或上推方法或字段的地方。
许多最常见的编程IDE（例如Visual Studio，Xcode和Eclipse）实际上将帮助您完成许多重构技术。
—自动化测试
我们正在更改代码，这带来了风险 。
证明您在重构时所做的更改 仅能满足 您预期的唯一最佳方法是，拥有一套可以在代码前后运行的自动化单元测试 。
可以使用Java中的Jnit之类的测试框架来完成自动测试。
一直进行自动化测试以测试驱动的开发或行为驱动的开发策略是重构的极好补充。
接下来要去哪里
如果您对一系列重构感到满意，并且想进一步进行探索，那么您的资源应该绝对包括Martin Fowler撰写的 “ 重构以改进现有代码的设计 ” 。
不打算从头到尾阅读这本书。 其中大部分是重构目录。 因此，它不仅仅是教程，而是参考。
的 refactoring.com （与Martin Fowler的书相关）和refactoring.guru 网站有简短的摘要，并提供了代码示例。
并且，随着您变得更加舒适，您可能还希望在平台或环境中寻找重构资源。 原理完全相同。 但是，通常有特定于平台的提示和技巧 。
谢谢阅读！ 如果您喜欢这篇文章，是否可以通过单击????按钮给我一些鼓掌？ 这很有帮助！
From: https://hackernoon.com/refactoring-the-hygienic-habit-b2ee0f5528ba