我们都听说过过早优化，但是您如何看待过早重构？你认为有这样的事情吗？这就是我的意思。
首先，阅读 Martin Fowler 的开创性著作《重构》从字面上改变了我在编程方面的生活。
然而，我注意到的一件事是，如果我开始过快地重构一个类或框架，我有时会发现自己被编码到一个角落里。现在，我怀疑问题本身并不是真正的重构，而可能是过早/糟糕的设计决策/假设。
您对这个问题有什么想法、见解和/或意见？您对此问题有什么建议或常见的反模式吗？
编辑：
通过阅读您的答案并更多地反思这个问题，我想我已经意识到我在这种情况下的问题实际上是一个“过早的设计”问题，而不一定是“过早的重构”。在编码过程的早期，我一直在假设一个设计并朝那个方向重构。保持一定程度的设计不可知论并专注于重构以实现干净的代码，我有一点耐心，这将使我不会走上这些设计兔子的道路。
其实我的想法正好相反。
你越早开始考虑你的设计是否需要重构越好。不断地重构，所以它从来都不是一个大问题。
我还发现，我越早重构，就越能更好地提前编写代码。我倾向于创建更少的大型方法，并且问题更少。
但是，如果您发现自己将自己“重构”到了一个角落，我认为这更多的是缺乏初始设计或缺乏对类的使用范围的规划。在开始编写代码之前，试着写出你想如何使用类或框架——它可以帮助你避免这个问题。这也是我认为测试驱动设计的一个优势——它可以帮助你强迫自己在编写对象之前考虑使用它。
请记住，从技术上讲，重构永远不应该把你锁在角落里——它是在不改变类使用方式的情况下重新设计内部结构。如果你用重构来困住自己，那意味着你最初的设计是有缺陷的。
您可能会发现，随着时间的推移，这个问题会变得越来越好。您的类和框架设计最终可能会更加灵活。
我们都听说过过早优化，但是您对过早重构有什么看法？你认为有这样的事情吗？
就在这里。重构是一种偿还在整个开发过程中累积的技术债务的方法。然而，仅仅积累技术债务并不一定是坏事。
要了解原因，假设您正在为 IRS 编写纳税申报表分析软件。突然，在最后一刻引入了新的规定，打破了你最初的几个假设。尽管您设计得很好，但您的领域模型至少在一个重要的地方已经从根本上转移到了您的脚下。现在是 4 月 14 日，该项目明天必须上线，无论是地狱还是高潮。你做什么工作？
在这种情况下，第一个选项是更好的选择。假设您以前几乎没有技术债务，那么现在收下您的资金并在以后还清是值得的。当然，这是一项商业决策，而不是设计决策。
我认为重构过早是可能的。
设计的具体细节是代码本身。设计的最后阶段在您编写代码时就存在，它有时会存在缺陷，随着代码的发展，您会看到这一点。如果你过早地重构，就很难改变有缺陷的设计。
例如，当你意识到它是垃圾或方向错误时删除一个长函数比删除一个格式良好的函数及其使用的函数和它们使用的函数等要容易得多，同时确保您不会破坏重构中的其他内容。
可以说，也许您应该花更多的时间进行设计，但敏捷过程中的一个关键要素是编码是设计过程的一部分，并且在大多数情况下，在设计中付出了一些合理的努力后，最好继续用它。
编辑回应评论： -
在您编写代码之前，设计尚未完成。我们无法解决预编码设计中的所有问题，敏捷背后的全部意义在于编码就是解决问题。如果非代码设计在编码之前预先解决了所有问题，则无需重新分解，我们只需一步将设计转换为分解良好的代码。
任何人都记得 1980 年代末和 1990 年代初的结构化设计方法，在您编写一行代码之前，您可以在巧妙的图表中解决所有问题？
过早重构是没有单元测试的重构。那时你还没有准备好进行重构。首先进行一些单元测试，然后开始考虑重构。否则，您将（可能）伤害项目多于帮助。
我认为任何“1.0”项目都容易受到这种......我们称之为“迭代设计”。如果在开始设计对象之前没有明确的规范，您可能会想到许多设计和解决问题的方法。
所以，我认为克服这个特定问题是在开始编写代码之前清楚地设计事物。
视情况而定，有几个有前途的解决方案可以解决这类问题。
如果问题是您决定可以以某种方式优化某些东西，并且您提取了一种方法或某些东西并意识到由于该决定，您被迫以一种复杂的方式对其他所有内容进行编码，那么问题可能是您没有在设计过程中想得不够远。如果有一个精心编写和计划好的规范，你会提前知道这个问题（除非你没有阅读规范，但这是另一个问题:)）
根据具体情况，快速原型制作也可以解决这个问题，因为当您开始实际工作时，您将对这些实现细节有更好的了解。
我坚信不断重构。没有理由等到某个特定时间开始重构。
任何时候你看到一些应该做得更好的事情，重构。
请记住这一点。我认识一个开发人员（一个纯粹的天才），他进行了如此多的重构（他非常聪明，总能找到更好的方法）他从未完成过一个项目。
过早优化不好的原因是优化通常会导致更糟糕的设计。与重构不同，重构会带来更好、更简洁的设计，如果做得深思熟虑和正确的话。我学到的对我分析重构有用性有用的是首先查看我们的 UML 图以可视化更改，然后首先为类编写代码文档（例如 Javadoc），并在任何实际代码之前添加存根。当然，经验对此有很大帮助，如果有疑问，请询问您最喜欢的建筑师；）