问在重构之前进行设计是什么时候的实际？

EN

如果重构是我们的主要目标，那么我们是否应该将重构限制在使其可测试所必需的范围内呢？

如果这是你唯一的目标，答案显然是肯定的--你为什么要把时间花在你没有目标的事情上呢？

然而，可测试性很少是一个独占的目标。在编写可能存在很长时间的代码时，您和您的团队通常会有其他目标，比如可读性或可扩展性，而重构是实现这些目标的方法。

在重构开始之前，预先设想和决定设计更改是否可行？

在我工作的地方，我们通常不把大多数重构看作是一个独立的步骤，或者是自己证明自己是正确的。相反，如果我们想修复一个bug，添加一个新特性或优化资源使用，我们将检查代码中涉及的区域是否是

• 具有足够的可读性，可以对错误、修复或计划的扩展进行推理。
• 可扩展到可以添加新特性和
• 可测试性足以确保以前的代码更改可以通过自动测试进行验证。

如果不是的话，就必须在代码进行重构之前、之后或之间进行重构--这些重构本质上是任何编码工作的一部分，在任何人的个人日历中都找不到一个单独计划的步骤。因此，与团队就孤立的重构进行大量讨论是没有意义的，这显然是实现真正的主要目标--在软件中引入新特性，以及从软件中删除bugs -是明智的。别忘了，重构本身不是目的，而是达到目的的手段。

这并不意味着您不应该与其他团队成员讨论更大的重构。如果您不确定重构的成本/效益关系，或者您要更改代码库中的名称(在数百个地方使用)，或者如果您看到了破坏事物的风险，那么预先讨论显然是有意义的。但是，讨论每一个小的、次要的重构，比如更改局部变量的名称，提取一个小的函数，或者事先与整个团队一起添加或改进注释，都是毫无意义的。让查看您的拉请求的审阅者检查这些更改是完全足够的。

在哪里准确划定界限，哪些问题“足够大”，可以预先与团队讨论，哪些不是，这是你需要与你的团队自己解决的问题。

最后，让我们看看你们“引进工厂”的例子。我们必须找出成立工厂的原因：

• 它是为了增加可测试性，例如允许生成模拟对象，还是让复杂的对象创建过程单独测试？
• 或者是为了实现特定的扩展，并且预先使系统更易于扩展，会降低工作量吗？例如，通过引入一些通用或抽象工厂，允许引入更改较少的基类的新子类？
• 或者你只是认为它是一种战略重构，为某些子类引入不同的建筑代码，但却没有明显的直接效益？

具体而言，最后一个原因显然不是由直接的特性添加、错误修复或明显的改进所驱动的，因此是与您的同事讨论的好人选。