您如何以及多久重构一次代码？

Question

我的问题模糊地与this one有关。但是，它没有涉及技术或实践。

我正在阅读 The Pragmatic Programmer ，它强烈主张尽可能多地重构代码。但是，它没有详细说明如何做到这一点以及频率如何。你们如何重构你的代码，以及你多久重构一次？

Answer 1

何时何地需要。

重构本身没有意义，它是一种缓解进一步发展的工具。只有重构才能获得优势。一个永远不会进化和测试的小型库是不重构的完美候选者，任何投入重构的时间都不会回报。您的系统/程序中将会发展，需要维护并且难以阅读的部分是重构的明确候选者。

总是考虑投资回报率（投资回报率），如果你开始重构你现在认为可能会更好的一切，那么明天你会再次重构，也许有一段时间你会有时间实际执行一些真正的进步。

Answer 2

它有点像清洁房子，你应该每天都去接受并完成需要做的小任务以保持清洁。然后（每周一次左右）你需要几个小时，从上到下给房子一个很好的清洁。最后（每年一次左右）你做一个很好的春季大扫除，把所有垃圾拖走，重新开始。

重构是关于保持一个干净的代码库，这是永远不会完成的永久性任务。

Answer 3

只有在测试用例覆盖了代码时才进行重构。

Answer 4

每当我看到代码重复时。

每当我看到更简单的算法/启发式的机会时。

越接近发布版本越来越少了。）

我喜欢可以帮助您分析代码库的工具，并且可以告诉您未使用的成员，不必要的可见性（公共与受保护与内部与私有等）

我主要在.NET工作，ReSharper很棒，可以实现这一目标以及自动执行多种类型的重构操作。我认为有许多其他语言的类似工具。

Answer 5

一般来说，当我正在努力增强系统的一部分时，我会重构代码，而且我知道我正在重构的代码部分将要进行测试。

如果我看到一些我知道需要处理的东西，并且它不是当前版本的一部分，那么我暂时不管它并将它插入下一个版本。这对我们来说并不是什么大不了的事，因为我们每个月大约发布一次，所以我们发现的错误代码可以等待一段时间（假设它不会导致生产中的问题），直到我们有时间进行彻底审查需要做什么。

Answer 6

最重要的是永远不要告诉你的老板/客户你是在重构。始终将重构包括在正常的工作流中。不值得不断加剧解释为什么值得付出代价。

Answer 7

当我写第一遍代码时，我通常会尽量避免让自己陷入困境，对可能的重用场景进行过深的思考。然后，随着越来越多的重用场景出现，我进入开发的越多，我就越重构我的旧代码以提高其抽象和重用水平。

所以真的是一个迭代过程;我越是越过并使用我已经为新目的编写的代码，我发现有必要进行重构。

Answer 8

每当我添加新功能或特别是在更改现有功能时，我都会寻找重构机会

Answer 9

我不是因为重构而重构的粉丝。我总是尽量保持代码尽可能干净，避免使用快捷方式，并在第一时间进行操作。每次我添加一个新功能时，我都会根据需要随时重构，并将其视为功能实现的一部分。

如果你有能力以这种方式工作，就不需要经常进行大规模和“可怕”的重构，就像不经常进行小规模清理一样。

当然，当项目范围发生变化时，无论代码的形状如何，通常都需要重构，但代码更精简，重构更轻松，更快。

Answer 10

关于重构有许多谚语和经验法则。一个常见的问题是The Rule of Three

在职业生涯中，我们在进行重构时的灵活性显然低于我们在个人项目中的灵活性。由于更改会为测试人员带来风险并创建工作（即使您将所有回归测试都自动化，移动到生产的更改会在您的流程中为人类创建一些工作，除了更改代码的人员之外），您必须在决定重构的内容和时间时计算成本与收益比。

在决定重构的内容和方法时，我会记住以下几点，特别是在我处理将要投入生产的代码时：

1. 重构的目标是什么？性能？复杂性降低了？再利用？
2. 这种变化的影响程度如何？高影响力的变化往往会带来更多与之相关的测试，并带来更高的风险。
3. 可以干净地执行重构吗？不完整的重构可以引入比它带走的更多的熵。例如，您有一些方法可以成为一个很好的实用程序类。如果引入实用程序类，是否可以通过调用实用程序类替换所有现有（可能是复制和粘贴）方法？还有另一个具有类似功能的现有实用程序类吗

Answer 11

有重复级别和级别。

我经常重构以删除重复。我没有寻找进行复制，但是如果我看到它，我会解决它。我一直在使用Extract Method来使方法更小，并遵循所有ReSharper建议或警告（我将ReSharper配置为将我可能忽略的任何内容放入提示中）。这也是一个好处，因为你习惯于在顶部看到漂亮开朗的绿色广场，告诉你一切都很好。当它是一种不同的颜色时，你知道出了问题。

更大的重构（OP可能关注的那种），我在很大程度上像对待一个新功能一样对待。我将尝试就它的重要性达成共识，并相应地安排它。除非所涉及的代码具有高度的单元测试覆盖率，否则我不会做出这样的改变。 “如果它没有经过测试，那么它就会被打破”是墨菲定律的必然结果。此外，如果它已经被破坏，那么我不会通过重构覆盖不良的代码来使情况变得更糟。

我也不重构使代码适合某种模式，或者更容易修改以备将来使用。当未来到来时，它会以一些失败的单元测试到达，除非我做出改变，否则不会成功。如果没有这样的测试，那么我无法判断我的更改是否破坏了什么，所以我不会重构。

Answer 12

每当我推动 - 否则我的同事会接受我的案子，他们也应该这样做。

（这是DVCS的另一个好处：我可以在不推送的情况下提交正确但错误的因素代码。）

Answer 13

一直以来。每当我看到方法或变量的更好名称时，每当我看到应该内联或提取的内容等时，我都非常依赖Eclipse的自动重构来安全地进行这些更改。更大，非自动化的重构发生的频率较低，但是当我看到它们的需要时，并且只有坚实的测试覆盖率。

Answer 14

特定于VS 2008和C＃

一直以来。我倾向于使用StyleCop和Code Analysis永久运行代码。甚至使用Resharper，如果我在任何地方看到红色，那么现在是重构的时候了。当然，我只使用这些工具来简化操作并迫使我这样做。

然而，按照我的规则，我只重构自己的代码和新代码。其他人编写的遗留代码和代码在指示之前不会受到影响。

Answer 15

我认为重构代码有多种决定因素。其中一些可以是美学，常见功能或业务流程。

例如，我目前正致力于从我们的几个实用程序（Java Swing）中重构常见功能。每个实用程序在顶部都有相同的菜单栏。但是如果我需要添加一个菜单项，我需要为所有实用程序（复制/粘贴）执行此操作。所以我创建了一个菜单栏对象，让每个实用程序只使用这个对象。现在，如果我添加一个菜单项，它们都会立即更新。

现在，这些公用事业的开发将在世界各地进行，而不仅仅是我。所以我想要做的就是打破更多的共性，这样当一个新的开发人员在一个实用工具上工作时，他们可以专注于肉和土豆，现在关注它的Swing方面。

我还将几个数据验证和数据插入程序重构为较小的数据。这有助于打破应用程序中的业务逻辑，并可以帮助“区域化”到您需要的位置。例如，应用程序中有一个步骤确定是否可以将行插入数据库。我没有做这一步，而是将其设为10，其中包括读取数据，验证正确的大小和数据类型，我在标签中显示的内容等等。现在更改特定部分的业务逻辑更容易

Answer 16

我经常重构。经典的场景是当我结束编写大方法时，我喜欢将它们分成小块。还有很多其他的，它们的发生频率很高。重构有助于我在快速编码之间保持平衡，但保持我的代码尽可能整洁。

Answer 17

除了真正 - 非常紧张的情况，你必须完成一些事情现在然后我总是在我写下来的东西时一直睁大眼睛进行重构。有时我有空闲时间，我会尝试重新重构旧代码，以防错过。

Answer 18

每当我不开发新代码时，我都会重构。我也会在任何时候重构，我发现任何瓶颈。

• 展开慢循环
• 将变量定义移动到函数的头部。
• 用经过验证的更快的算法取代速度较慢的'原型'算法。