代码复制和重构

Question

我希望听到关于 检查相同条件 （例如，相同条件）的方法中的少量代码复制的意见。

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

} 

通常情况下，如果有任何此类复制的我会重构代码，因为它可以使版本的噩梦，如果有什么例如病情变化，你必须改变每一个实例，而不是一个很好的工作要做。 但是，如果条件相对简单并且只在3种方法中使用，那么重构是否明智呢？

因此，总结人们在重构代码中的位置？

Answer 1

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

Answer 2

它取决于2件事情，IMO - 重复的大小（涉及多少行）以及重复的地点 - 它们在上下文中的关系如何。

如果你在同一个类的几个方法中有重复的代码，那么我会考虑将单个行的重复项提取到一个单独的方法中（假设所讨论的行是一个易于识别的，容易隔离的，相当不耦合的块的代码）。另外，如果我在项目的某个部分有一些代码，并且在一个（几乎）不相关的区域有几乎相同的代码段，那么我不会考虑这一点，因为未来发散的范围看起来很高。 ...

Answer 3

重构的关键是要做到这一点，当你需要来。在上面的例子中，如果你有3个不同的while循环具有相同的条件，谁将在未来说你可能需要不同的条件，如果你已经重构了，那么你已经引入了一个潜在的错误情况。

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

Answer 4

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

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

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

Answer 5

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

除了提到将来的更改更容易，重构有助于提高可读性，并且可以使意图更加明显。