过早的重构？

Question

我们都听说过premature optimization，但您对过早的重构有什么看法？你认为有这样的事吗？这是我得到的。

首先，阅读Martin Fowler的开创性作品"Refactoring"完全改变了我在编程方面的生活。

然而，我注意到的一件事是，如果我开始过快地重构一个类或框架，我有时会发现自己被编码到一个角落里就可以说了。现在，我怀疑这个问题本身并不是真正的重构，但可能是过早/糟糕的设计决策/假设。

您对此问题有何看法，见解和/或意见？您对此问题有任何建议或共同的反模式吗？

修改

从阅读你的答案并更多地反思这个问题，我想我已经意识到我在这种情况下的问题确实是“过早设计”的问题，而不一定是“过早的重构”。在编码过程的早期，我一直在设计和重构这个方向。对我保持一定程度的设计不可知论并专注于对清洁代码的重构，我有点耐心，这将使我无法走下这些设计兔子的道路。

Answer 1

我实际上认为相反。

越早开始考虑您的设计是否需要重构，就越好。不断重构，所以这绝不是一个大问题。

我还发现，我在早期重构的越多，我就越能更清晰地编写代码。我倾向于创建更少的大型方法，并且问题更少。

然而，如果你发现自己“重构”自己到了一个角落，我希望这更多的是缺乏初始设计或缺乏对课程使用范围的规划。在开始编写代码之前，尝试写出如何使用类或框架 - 它可以帮助您避免该问题。这也是我认为测试驱动设计的一个优点 - 它可以帮助你强迫自己在编写之前使用你的对象。

请记住，技术上的重构应该永远不会让你陷入困境 - 这是关于重新修改内部结构而不改变类的使用方式。如果你通过重构来捕获自己，那就意味着你的初始设计存在缺陷。

您可能会发现，随着时间的推移，这个问题会变得越来越好。您的类和框架设计可能会更灵活。

Answer 2

  

我们都听说过早熟优化，但你对早熟重构有什么看法？你认为有这样的事吗？

是的，有。重构是支付技术债务的一种方式，它在您的开发过程的整个生命周期中累积。然而，仅仅累积技术债务并不一定是坏事。

要了解原因，请假设您正在为IRS编写纳税申报分析软件。突然之间，在最后一刻引入了新的规定，打破了几个原始的假设。虽然你设计得很好，但你的领域模式已经从根本上从至少一个重要的地方转移到了你的脚下。这是4月14日，该项目必须明天上线，地狱或高水位。你做什么的？

• 如果以一些中等技术债务为代价实施螺母和螺栓解决方案，您的系统将变得更加严格，并且无法承受另一轮这些变化。但该网站可以上线并继续前进，并且没有延迟交付的风险;你有信心可以做出必要的改变。
• 另一方面，如果您花时间重构解决方案，以便现在以更复杂和灵活的方式支持新设计，那么您将适应未来的变化。但是你冒着贵公司旗舰产品的风险而不顾时机;你不确定重新设计是否需要比今天更长的时间。

在这种情况下，第一个选项是更好的选择。假设您之前几乎没有技术债务，那么现在就拿下你的块并稍后付清它是值得的。当然，这是一个商业决策，而不是设计决策。

Answer 3

我认为有可能过早重构。

设计的末端是代码本身。设计的最后阶段随着代码的存在而存在，它有时会有缺陷，随着代码的发展，你会看到它。如果你过早地重构，就会更难改变有缺陷的设计。

例如，当你意识到它是垃圾或走错方向时，删除一个很好的格式良好的函数及其使用的函数和它们使用的函数等，就更容易删除单个long函数。 ，同时确保你不会破坏重构中的其他东西。

可以说也许你应该花更多的时间来设计，但敏捷过程中的关键因素是编码是设计过程的一部分，在大多数情况下，在设计上付出了一些合理的努力，最好是继续吧。

修改回复评论： -

在您编写代码之前，设计不会完成。我们无法解决预编码设计中的所有问题，敏捷背后的重点是编码 解决问题。如果非代码设计在编码之前预先解决了所有问题，就不需要重新因素，我们只需一步就将设计转换为精心设计的代码。

任何人都记得20世纪80年代末和90年代初的结构化设计方法，在你编写一行代码之前，你在聪明的图表中解决了所有问题吗？

Answer 4

过早重构是在没有单元测试的情况下进行重构。那时您还没准备好进行重构。首先得到一些单元测试，然后开始考虑重构。否则你会（可能）伤害项目而不是帮助。

Answer 5

我认为任何“1.0”项目都容易受到这种情况的影响......我们称之为“迭代设计”。如果在开始设计对象之前没有明确的规范，您可能会想到许多设计和方法来解决问题。

因此，我认为克服这个具体问题是在开始编写代码之前清楚地设计一些东西。

Answer 6

根据具体情况，这类问题有很多有希望的解决方案。

如果问题在于您决定某些事情可以以某种方式进行优化并且您提取某个方法或某些内容并意识到由于该决定，您将被迫以复杂的方式对其他所有内容进行编码，问题可能就是你在设计过程中没有想太多。如果有一个编写良好且计划好的规范，你会提前知道这个问题（除非你没有阅读规范，但这是另一个问题:)）

根据具体情况，快速原型设计也可以解决这个问题，因为当您开始处理真实事物时，您将更好地了解这些实现细节。

Answer 7

我坚信不断的重构。没有理由等到某个特定时间开始重构。

任何时候你都会看到应该做得更好的事情，重构。

请记住这一点。我认识一个开发人员（一个纯粹的天才）如此重构（他非常聪明，总能找到更好的方法）他从未完成一个项目。

Answer 8

过早优化不好的原因是优化通常会导致更糟糕的设计。与重构不同，后者可以提供更好，更清洁的设计，如果做得周到和正确的话。我学到的对于分析重构的有用性有用的是首先查看我们的UML图来可视化更改，然后首先为类编写代码文档（例如Javadoc），并在任何实际代码之前添加存根。当然，经验对此有很大帮助，如果有疑问，请询问您最喜欢的建筑师;）