Question

我想听听有关方法中少量代码复制的意见检查相同的条件 e.g。

While(condition){
...... do x 

}

通常，如果有任何这种复制，我会重构代码，因为它可以使版本控制成为一场噩梦，如果条件发生变化，例如你必须改变每个实例，这不是一件好事。然而，如果条件相对简单并仅在3种方法中使用，那么重构是明智的，

总结一下，人们在重构代码中划清界限吗？

Answer 1

重构不是免费的。对代码的任何更改都可能引入错误。因此，每个有意识的开发人员都会考虑他是否有时间仔细检查这些变化，并且在很多情况下决定不重构。

Answer 2

这取决于两件事，即IMO - 重复的大小（涉及多少行），以及重复的位置 - 它们在上下文方面的“接近”程度。

如果你在同一个类中的几个方法中有重复的代码，那么我会考虑将一行的重复项提取到一个单独的方法中（假设所讨论的行是一个易于识别，易于隔离，相当解耦的部分码）。

或者，如果我在一个项目的一个部分中有一些代码，并且在一个（几乎）不相关的区域中有一个几乎完全相同的代码段，那么我就不会将其考虑在内，因为未来分歧的范围似乎很高。 ..

Answer 3

重构的关键是在需要时执行此操作。在上面的示例中，如果您有3个不同的while循环具有相同的条件，那么将来您可能想要不同的条件，如果您已经重构，那么您已经引入了潜在的错误情况。

这是一个判断问题，同样的条件三次似乎没问题，相同条件10次是一个明显的重构，但转折点在哪里？

Answer 4

我个人通常对重构非常积极。我相信如果你定期清理你的代码，你最需要做一些小而简单的重构。如果你离开它一段时间，它会变得如此混乱，难以维护。

在您的特定情况下，如果条件具有合理的商业含义，我肯定会重构，因为它会使代码更具可读性。但即使这是一个技术性问题，我也会考虑重构，只要提取函数或属性即可。

理想情况下，您应该进行单元测试以确保您的重构仍然正确，因此执行此操作的成本应该是几分钟，通常小于编写此响应。

Answer 5

一个常见的经验法则是Martin Fowler在开创性工作Rule of Three中引入的Refactoring。规则说两个基本相同的东西可以保留，但是一旦你添加了第三个，你就应该重构它们。

除了提及未来的更改之外，重构有助于提高可读性，并且可以使意图更加明显。