如何重构快速发展的代码？

Question

我有一些研究代码是真正的老鼠窝，到处都是代码重复，显然需要重构。但是，随着我对主题的新变化提出并使它们适合代码库，代码库也在不断发展。我推迟重构这么久的原因是因为我觉得我花了几天时间提出好的抽象，看看哪些设计模式适合哪里，等等，我想尝试一些新的无法预料的想法，使我的抽象完全不合适。换句话说，由于代码的演变速度，我真的不知道抽象线在哪里，即使没有（近似）重复的缺乏，代码的一般混乱使得添加内容成为真实的痛。有哪些一般的最佳做法可以应对这种情况？

Answer 1

不要花这么长时间的重构！

当您要对一段代码进行更改时，请考虑重构它以使更改更容易。

进行更改后，再次重构以清除该更改造成的损害。

在这两种情况下，让重构变小并快速完成，然后继续。

您无需始终保持代码原始状态，但请记住，如果您有合理的代码可以使用快速（并且如果您有良好的单元测试） ，当然）。

Answer 2

测试驱动开发：

红色，绿色，重构。冲洗，重复。

由于这是每个周期中的一个步骤，你会注意到很多通常都是轻微的重构。这就是应该的样子。

Answer 3

我的情况非常熟悉。在进行调查编码时，您通常不知道“正确”的抽象是什么，正如您所说，它可以随着每一个新想法而改变。
其他海报建议：

• 持续的小型重构，有助于避免陷入鼠巢情况
• 测试驱动开发，有助于找到良好的，可重复使用的抽象。重要的是要注意TDD不是关于测试而不是做好设计！

然而，对于调查研究代码，还有另一种策略：原型。这似乎是您目前正在做的事情：尽快编码来证明一个概念。这没有什么不对，但原型应该总是扔掉。调整它直到你拥有所有必要的输入和知识，然后抛出 远离代码并重新开始TDD和连续重构，以及所有其他“做正确的事情”策略。

不要保留任何代码。不要复制粘贴任何东西。不要再回头了。重新开始你的新知识。

Answer 4

一次清理一下代码。总是当你触摸一个班级时，试着让你的班级在你触摸之前保持清洁（"the boy scout rule"）。重构最好以非常小的步骤完成，但经常进行。

重命名一些变量，拆分方法等等只需几秒钟或几分钟。大型重构，例如拆分或加入课程，可能需要一两个小时（并且您只需要一小步，所以所有测试至少每五分钟通过一次 - 否则您已输入Refactoring Hell并且您应该恢复到最后知道的工作状态）。如果你需要几天或几周来重构某些东西，那么它就不再是“重构”了 - 它更像是重写。

有关此主题的文章： http://blog.objectmentor.com/articles/2007/07/20/whats-your-unit-of-measure

Answer 5

至少把它放在像Git这样的分布式SCM中，这样当你破坏一些重构时，你可以在更改之前分开反转时间以找到提交，以及能够处理更改并在分支中提交它们而不会干扰和其他人一起工作。

Gits Branch merge非常适合这样的事情，如果2个人并行进行不兼容的更改而你不必担心其余的代码，你就会很容易理解。

由于上述原因，我还会在存储库 中创建一个单独的分支，用于重新分解代码，并定期更新代码。这样，不仅其他人不会干扰您的进度，而且他们可以密切关注它并看到它的变化，最终会击中主分支，以便他们可以先发制人地围绕这些变化进行编码。

Answer 6

如果你已经知道哪里有重复，你不需要几天时间来重构它。

Answer 7

有时重写是唯一的选择。情况似乎如此。

Answer 8

CloneDR在大型源系统中找到重复的代码，包括精确副本和接近未命中，由langauge语法参数化。它支持Java，C＃，COBOL，C ++，PHP和许多其他语言。

当它显示一组找到的克隆的参数化抽象时，它基本上建议你使用实现的抽象重构代码（作为方法，函数，类，...... ）。

因此，运行CloneDR会获得一个列表，列出要添加到代码中的潜在抽象，并通过抽象调用替换克隆实例，重构代码，从而（稍微）清理它。

更值得注意的是，当它显示每个克隆站点使用的参数绑定需要调用抽象时，它通常会显示一个错误的克隆实例，当绑定的参数在概念上不一致时很容易识别。如果参数被绑定到名为YYYY-MM-DD的变量，并且其中一个是YY-MM-DD，则“它的4位数年份”参数类型看起来被违反，在这种情况下，Y2K修复被破坏。因此，检查克隆绑定通常会发现错误。

Answer 9

这是科学计算中一个非常普遍的问题。减少代码大小和复杂性的一些最有效的想法需要利用假设，科学要求您不断改变这些假设。

您所能做的就是尝试重新编写代码，并尽量不要将自己写入任何角落。还要与善于理解不弄乱的价值的人一起工作。