重构：这仅仅是清理代码的幻想吗？[关闭]

在马丁·福勒（Martin Fowler）的书《重构：改进现有代码的设计》问世之前，我们习惯将对代码的主要更改称为“重新架构”，而将较小的更改称为“清理”。IMO，重构技术都是常识/我们一直在做的显而易见的事情。

您认为重构曾经是新事物吗？也许只是一种诱使管理人员分配时间进行代码清理的方法？

重构比丘陵还要古老，所以不，它不是什么新鲜事物。

重构并没有清除。可以，但不仅限于清理。

它在保留行为的同时调整了应用程序的体系结构（无论是大规模还是小规模）。

这意味着，尽管您的应用程序的某些部分昨天可能已经很干净了，但是今天的新功能需要调整该部分以适应新功能。

您不想破坏现有功能，因此可以在保留行为的同时调整应用程序的结构-这就是重构。

这表示无论对代码进行什么更改，都应该始终运行其测试...以防万一。

这只是整理代码。本质上，程序员（尤其是Martin Fowler）注意到，每次整理代码时，他们往往会执行相同的任务。他们定义并标记了整理方法和相关的代码问题，并为之加油！重构诞生了。

设计模式是相同的-人们注意到他们倾向于一遍又一遍地使用相同的方法来解决特定问题。他们标记并定义了这些方法，现在看来您不是真正的程序员，除非您仅在代码中使用相同的十几个模式。

重构没有魔术。这只是描述旧习惯的一组新术语。

我们在公司中做三件事，为这三件事分配时间：

• 重构：在于更改代码结构，从而保持行为。

示例：将一个丑陋且难以理解的100行方法拆分为四种可重复使用的方法，每种方法可以做四件事，每个方法25行。

• 清除：进行少量修改以使代码更具可读性，而不修改其行为或结构。

示例：在确保不再需要此代码后，删除注释的代码。

• 实施StyleCop / FxCop规则：检查代码是否与StyleCop或FxCop规则的默认集合匹配，如果不匹配，则对其进行修改以匹配这些规则。

实施例：将Culture.Invariant在string.Format（或其他培养物，其是更合适）。

因此，就我而言，重构与清理大不相同。在做清理工作，我没有再次运行单元测试：如果代码工作之前，它会清除后工作。换句话说，这不是因为我删除了空行或添加了注释，代码将停止工作。另一方面，当我重构旧代码的复杂部分时，我可能会犯一些错误，因此我必须在重构后运行单元测试。

重构为您的代码增加了知识。如果您知道某个东西的名称不正确，则可以给它起一个更好的名字。如果您知道可以做得更好，则可以将其更改为更好的东西。

这是很多步骤，无论大小，都有望使程序更好。

我同意“重构是花哨的单词，可以清理代码”，但不赞成。人们使用花哨的单词是有原因的：有时是因为他们想显得聪明，有时是因为他们传达了更大或更精确的含义，而恕我直言的重构（即使偶尔被滥用）通常是指后者。

“清理”可能意味着从“重新格式化”到“重写大块”的任何内容。

“重构”特别是指“对代码进行少量的增量更改，以保持相同的功能，同时将其转换为更好的设计”。在您做的事情上有很多最佳实践：有些是临时的，但是有一些通用的原则，例如使用单元测试，将部分函数提取到新函数或类中，等等，人们可以并且应该学习。

您说“只是把技巧管理分配给代码清理时间”。但是，如果说“重构”正确地传达了这样一个概念，那就是现在进行稳定的透明投资将在将来提高效率，这不是“把戏”，而是清晰有效的沟通。

重构是对代码的编码，而归一化是对关系数据的编码。这是一个将概念抽象为更清晰，更清晰和更有效的表示形式的应用程序过程。

这取决于您如何理解术语重构。对于大多数人来说，这是在不改变行为的情况下改善结构的过程。如果您同意，那么是的，在本书问世之前就已经完成了。我知道，因为（在许多其他事情中）我在写本书之前重命名类，提取类和提取方法。我并不是说它是重构的，但实质上，我在做完全相同的事情。

对我来说，个人重构就是人们现在所说的“自动代码重构”，即：支持IDE内的各种重构技术。这是对我之前所做的事情的真正改进（确实非常痛苦）。我可以在一堂课中进行更改，而不必担心这将如何影响软件的其余部分。我认为Martin将重构技术正式化，直到可以将其表示为算法，然后在各种IDE中实现为止。

因此，如果您将重构理解为一个过程，那么它并不是什么新鲜事物。如果您将其视为自动化，那么它是一项巨大的改进。尝试在一个相当大的项目中重命名几个核心类（实际上，不是通过IDE的重构选项），以了解原因：）

重构的确是代码“清理”，但也重构了代码。在我的团队中，重构通常是后者。当我们遇到“重构”情况时，我们会分配时间来重构代码，例如，使其与新的体系结构或信息模型保持一致，或者使其效率更高。

代码“清理”是我们连续执行的工作，没有为其专门分配时间。对我来说，“清除”通常是重命名，清除注释等。

我会说不。

重构过程中可能需要清理，但这不是本质。

清除是基于先前代码不干净的假设进行的。实际上，即使原始代码已经干净，开发人员也可以重构其代码。

DRY是重构背后的关键驱动力。

在将新代码添加到现有代码库中时，由于DRY原理，自然可以完成重构。

我的0.02

清理代码就像整理房子，重构就像拆掉一堵墙，可能把它放在其他地方一样

当其他人打扫您的房子时，您什么也找不到，因为目标是使事情变得干净整洁。重构将建立并标记房间，壁橱，橱柜，架子，垃圾箱等。它仍然可以容纳大部分相同的东西（您仍然可以在厨房里做一个烤奶酪三明治，然后在客厅里吃它），但是应该这样做更容易找到，并且可能有放置新事物的有效场所。

术语“重构”是从代数中优雅地借用的。这意味着简化术语以产生相同的结果。它不仅优雅，而且是革命性的-它要求对代码进行严格的有限处理，其程度令许多人感到惊讶。因此，该术语本身意义重大且很有帮助。

否。重构是在不改变行为的情况下改善结构。从严格意义上讲，重构需要良好的测试纪律。当您“清理”时，这不一定是必需的。

两者在边缘有些重叠，但对我来说，这是打扫房屋和重塑房屋之间的区别。对我来说，清理并不意味着结构上的改变，而重构却意味着。

“重构”与“重构”实际上是相同的东西，但是具有“功能不变”的更强含义。就重新架构的目标而言，这一点也更加清楚，它通常是将通用代码“分解”为可重用的块。