代码重构是DevOps软件开发方法中使用的过程，该过程涉及编辑和清除以前编写的软件代码，而不更改代码的功能。
代码重构的基本目的是使代码更加有效和可维护。这是降低技术成本的关键，因为现在清理代码比错误(Error)已然发生要好得多。
代码重构提高了可读性，使质量保证和调试过程更加顺畅。 虽然它不能消除错误，但肯定可以在将来防止它们发生。
这就是为什么需要例行代码重构的原因。
如果要避免可怕的代码腐烂，代码重构很重要。 代码重复是由重复的代码，无数的补丁，错误的分类和其他编程差异引起的。 由不同开发人员组成的旋转门以他们自己的风格编写也可能导致代码腐烂，因为整个编码脚本没有凝聚力。
您何时应该考虑软件重构？考虑重构的最佳时间是在向现有代码添加任何更新或新功能之前。 在添加新的功能(Feature)之前返回并清理当前代码，不仅会提高产品本身的质量，还将使将来的开发人员更容易在原始代码的基础上进行构建。
在您将产品投放市场后，就该考虑一下重构了。 是的，这听起来很荒谬。 您终于推出了您使用了数月甚至数年的产品，现在您又要回到开始了吗？ 实际上，这是进行一些代码整理的最佳时间，因为开发人员现在有更多的闲暇时间可以在进行下一步工作之前进行重构。
如何执行代码重构：主要技术如前所述，重构的最佳方法是分步骤进行。 在向解决方案添加任何新功能之前，也必须这样做。 代码重构不应改变产品的功能。
话虽这么说，代码重构有许多不同的方法和技术。 一些最受欢迎的产品包括：
红绿重构用于代码重构的最广泛使用的技术之一是敏捷测试驱动开发中使用的红/绿过程。 应用Red-Green-Refactor方法，开发人员将重构分为三个不同的步骤：
停下来考虑需要开发什么。 [红色]代码开发以通过基本测试。 [绿色]实施改进。 [REFACTOR]通过抽象重构通过抽象分支是主要在需要进行大量重构的情况下使用的一种方法。 抽象涉及类的继承，层次结构和提取。 抽象的目的是减少软件代码中不必要的重复。
抽象的一个示例是上拉/下推(Pull-Up/Push-Down)方法。 这是涉及类的两种相反的重构形式。 Pull-Up方法将代码部分拉入超类，以消除代码重复。 下推将其从超类中获取并将其下移到子类中。
组成方法(Composing Method)
编写涉及简化代码以减少重复。 这是通过各种过程完成的，包括提取和内联方法。
提取包括将代码分解为较小的块，以查找和“提取”碎片。 然后，将分段的代码移到一个单独的方法中，并替换为对此新方法的调用。 除了该方法之外，提取还可以涉及类，接口和局部变量。
内联重构是在简化代码的同时减少不必要方法数量的一种方法。 通过找到对方法的所有调用并将其替换为方法的内容，可以删除该方法。
简化方法(Simplifying Methods)代码越老，它的混乱和复杂性就越大。 因此，进入并简化许多逻辑是有意义的。 这可以通过多种方式完成，包括条件片段和表达式的合并以及用多态性替换条件。
简化方法调用涉及调整类之间的交互。 添加，删除和引入新参数，以及使用显式方法和方法调用替换参数都是简化的所有方面。
在对象之间移动功能(Feature)此方法涉及创建新类以及在新旧类之间移动功能。 当一个类中的功能过多时，是时候将其中一些代码移到另一个类了。 或者，从另一方面来说，如果一个类并没有做那么多，您可以将其功能移至另一个类并完全删除。
准备重构马丁·福勒（Martin Fowler）在他的《重构：改进现有代码的设计》( Improving the Design of Existing Code)一书中谈到了预备重构的过程。 当开发人员在添加新功能时注意到需要重构时，便完成了此操作，因此它实际上是软件更新的一部分，而不是单独的重构过程。 通过注意到此时需要更新代码，开发人员正在尽自己的职责来减少未来的技术债务。
软件开发人员杰西卡·克尔（Jessica Kerr）为准备式重构提供了一个很好的说明性解释：
“这就像我想向东行驶100英里，而不仅仅是穿越树林，我要向北行驶20英里到高速公路上，然后以3倍的速度向东行驶100英里。 如果我直接去那里。 当人们强迫您直奔那儿时，有时您需要说：“等等，我需要检查地图并找到最快的路线。”准备性重构为我做到了。”
在Martin Fowler的网站和Refactoring.com上可以找到许多其他的代码重构方法。 最适合您的解决方案将取决于解决方案的大小和范围，必须执行重构的时间范围以及可用于协助整个过程的人员数量。
您什么时候不需要重构早些时候，我们强调了重构永远不会影响应用程序的性能，而只是起到清理作用。 但是，有时候从一开始就需要彻底修改应用程序。 在这些情况下，重构是不必要的，因为仅从头开始将更加有效。
另一个明智的选择是跳过重构，这是如果您试图在设定的时间范围内将产品推向市场。 重构就像搜遍了众所周知的兔子洞：一旦开始，它就会变得非常耗时。 在时间紧迫的时间表中添加任何其他编码或测试，将会给您的客户带来挫败感和额外费用.
代码重构的最佳实践关于代码重构，有几种最佳实践和建议。 解决此问题的最明智的方法之一是应用敏捷方法，一次执行一个步骤，然后进行测试。 这就是为什么这么多使用敏捷方法的开发人员大力支持代码重构的原因。
将重构过程分解为可管理的部分，并在进行其他更新之前及时进行测试，始终可以带来更高质量的应用程序和更好的整体开发体验。
以下是一些其他最佳做法：
在添加任何新功能之前先进行重构每当要求您向现有解决方案添加新功能或更新时，执行重构始终是一个好主意。是的，这需要更长的时间才能完成该项目，但这也将减少您或产品所有者将来必须处理的技术债务。
仔细计划您的重构项目和时间表代码重构中最困难的部分之一就是找到适当的时间。
考虑一下您的总体目标。您是否只想更改变量名以提高可读性？还是要进行全面清理？在合理的时间范围内优化代码的最佳方法是什么？
重构的最重要结果是不仅代码清洁器而且它实际上可以工作。请记住，这将花费比您想象的更长的时间，因此请相应地进行计划，并给自己一点时间。
经常测试重构时，您要做的最后一件事是在过程中弄乱了某些东西，并创建了会影响产品功能的错误或问题。这就是为什么在整个重构过程中必须进行测试的原因。
在开始任何重构项目之前，请确保已进行适当的测试。
让您的质量检查团队参与其中让您的质量检查和测试团队参与重构过程始终是一个好主意。每当您对现有代码进行更改时，即使是作为清理项目，也可能影响测试结果。
重构期间进行的分类更改可能会导致旧测试失败。另外，可能必须为过时的旧版软件系统创建新的测试。深度测试和回归测试都应作为重构工作的一部分进行。这将确保解决方案的功能不会受到任何影响。
使用敏捷方法进行编程和测试的开发团队很可能已经在同一页面上，涉及重构。
专注于进步，而不是完美所有代码最终都会变成可怕的旧代码。
接受一个事实，那就是您将永远不会百分百满意。您当前重构的代码将在不久的将来变得过时和过时，并且需要重新进行重构。
您必须开始考虑将重构作为正在进行的维护项目。就像您整个星期必须打扫和整理房屋一样，您将需要在许多不同的场合打扫和整理代码。
尝试重构自动化与大多数流程一样，自动化程度越高，重构就变得越容易，越快。
使某些或所有重构过程自动化的方法在开发人员中越来越流行。有许多捷径和工具可以减少重构的痛苦。阅读马丁·福勒（Martin Fowler）的书可以学到很多。
Eclipse和IntelliJ IDEA是两个具有内置自动重构支持的IDE（集成开发环境）。由于重构快捷方式仍然是开发社区的主要关注点，因此在不久的将来，您将在其他IDE中寻求更多的重构自动化。
结论将代码重构视为保持整洁有序的房子。拥有整洁，井井有条的房屋后，您的压力就会减轻，因为一切都变得更容易找到和操作。另一方面，没有多余杂物的房屋会导致混乱和压力大的环境。
书面代码也是如此。将其作为定期对代码进行“春季大扫除”的重点，您将获得更好的产品以及更加和平与高效的工作环境。
