什么是重构，什么不是

有时候，一个程序员会来找我，并解释说他们不喜欢某些东西的设计，并且“我们将需要进行大量的重构”才能使其正确。 喔喔 这听起来不好。 而且听起来也不像是重构……。

最初由Martin Fowler和Kent Beck定义的重构是

对软件的内部结构进行了更改，使其更易于理解，并且在不更改其可观察到的行为的情况下进行了更便宜的修改……这是一种清理代码的规范方法，可最大程度地减少引入错误的机会。

进行重构是为了填补捷径，消除重复和无效代码，并使设计和逻辑清晰。 为了更好，更清楚地使用编程语言。 要利用您现在拥有但程序员没有的信息，或者他们没有利用当时的信息。 始终简化代码并使之易于理解。 始终使将来的更改更容易，更安全。

修复您在过程中发现的所有错误都不会重构。 优化不是重构。 加强错误处理和添加防御性代码不会重构。 使代码更具可测试性并不是重构-尽管重构可能会发生这种情况。 所有这些都是好事。 但是它们没有重构。

程序员，尤其是维护代码的程序员，一直在清理代码作为工作的一部分。 完成工作是很自然的，而且通常是必要的。 Martin Fowler和其他人所做的是使重组代码的规范化 ，并记录一系列常见且经过验证的重构模式-目标和步骤。

重构很简单。 首先在可能的地方编写测试，以防止自己犯错。 通过小的，独立且安全的步骤对代码进行结构更改，并在每个步骤之后测试代码，以确保您没有更改行为–它仍然起作用，只是外观不同。 现代IDE中的重构模式和重构工具使重构变得容易，安全和廉价。

重构不是结束本身

重构被认为是一种支持对代码进行更改的实践。 您可以在进行更改之前重构代码，以便可以确认对代码的理解，并可以更轻松，更安全地进行更改。回归测试您的重构工作。 然后进行修复或更改。 再次测试。 之后，也许可以重构更多的代码，以使更改的意图更加清晰。 并再次测试所有内容。 重构，然后更改。 或更改，然后重构。

您没有决定进行重构，而是因为要执行其他操作而进行重构，而重构有助于您完成其他操作。

重构工作的范围应由您需要进行的更改或修正来决定-要使更改更安全，更清洁，您需要做什么？ 换句话说：不要为了重构而重构。 不要重构您未更改或准备更改的代码。

从头开始进行重构以了解

迈克尔·费瑟（Michael Feather）的《有效地使用旧版代码》一书中也进行了从头重构； 马丁·福勒（Martin Fowler）所说的“重构以理解”。 在这里，您可以获取不了解（或无法忍受）的代码并进行清理，以便在开始实际更改代码或更改代码之前可以更好地了解发生了什么帮助调试它。 弄清变量和方法的真正含义后，重命名它们，删除不希望看的代码（或认为不起作用的代码），分解复杂的条件语句，将长的例程分解为较小的例程，以便获得所需的代码到处走。

不要费心检查和测试所有这些更改。 关键是要快速行动–这是一个快速而肮脏的原型，可让您深入了解代码及其工作方式。 从中学习并扔掉。 从头重构还可以让您测试不同的重构方法，并了解有关重构技术的更多信息。 迈克尔·费瑟斯（Michael Feathers）建议您在此过程中对任何不明显或特别有用的内容进行记录，以便以后可以回来并按规定进行小规模的测试，并做适当的工作。

那“大规模”重构又如何呢？

通过进行简单而明显的重构更改，您可以在可理解性和可维护性方面获得巨大回报：消除重复，更改变量和方法名称使其更有意义，提取方法以使代码更易于理解和可重用，简化条件逻辑，替代魔术。带有命名常量的数字，将通用代码一起移动。

像这样的较小的内联重构和更基本的设计重构（Martin Fowler称之为“大重构”）之间存在很大的差异。 大而昂贵的变更会带来大量技术风险。 这并不是在工作时清理代码并改进设计：这是根本的重新设计。

有些人喜欢将系统的重新设计或重写，重新平台化或重新设计称为“ 大规模重构 ”，因为从技术上讲，您并不是在改变行为–业务逻辑以及输入和输出保持不变，而这仅仅是“正在改变”的设计和实现。 区别似乎在于您可以重写代码，甚至可以重写整个系统，并且只要逐步执行，您仍可以将其称为“重构”，无论您是用新代码缓慢扼杀旧系统，还是大型大规模更改系统的体系结构 。

“大规模重构”更改可能很难看。 他们可能需要数周或数月（或数年）才能完成，需要更改代码的许多不同部分。 它们需要分解并分多个步骤释放，这需要临时的脚手架和弯路，尤其是当您在短时间的敏捷冲刺中工作时。 这是诸如“ 按抽象分支”之类的实践发挥作用的地方，可帮助您长期管理代码中的更改。

同时，您必须继续使用旧代码和新代码，从而使代码更难遵循，更难更改，更脆弱，更容易出错-与重构应该实现的相反。 有时，这可能会永远持续下去–过渡工作永远不会完成，因为大部分收益都是很早就实现的，或者是因为提出这个想法的顾问继续从事其他工作，或者预算被削减了，而您坚持维护Frankensystem。

这是重构–不是

将这种繁重的项目与按需重构的原则混合在一起是错误的。 它们是根本不同的工作，具有不同的成本和风险。 它混淆了人们认为重构是什么以及应该如何进行重构。

重构可以而且应该集中在如何编写和维护代码上，这是日常开发活动的一部分，例如编写测试和检查代码。 它应该安静，连续和隐式地完成。 它成为工作成本的一部分，并汇总到估算和风险评估中。 如果做得正确，则无需进行解释或说明。

作为更改的一部分，重构需要花费几分钟或一两个小时，这只是工作的一部分。 重构可能需要几天甚至更长的时间才能进行重构。 它正在重写或重新设计。 如果您必须留出明确的时间段（或整个冲刺！）来重构代码，如果您需要获得许可或进行代码清理的业务案例，那么您就无需重构-即使您正在使用重构技术和工具，您正在做其他事情。

一些程序员认为，以重构的名义，为了未来和他们的手艺，对代码进行根本和重大的更改，重新构想和重写，这是他们的权利和责任。 有时重新设计和重写代码是正确的事情。 但是要诚实和清楚。 不要将其隐藏在重构的名称下。

参考： 什么是重构，什么不是重构，来自Building Real Software博客的JCG合作伙伴 Jim Bird。

翻译自: https://www.javacodegeeks.com/2012/04/what-refactoring-is-and-what-it-isnt.html