refactoring - 过早重构？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我们都听说过premature optimization ，但是您对过早重构有何看法？您认为有这样的事情吗？这就是我的意思。

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

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

您对此问题有什么想法、见解和/或意见？您有与此问题相关的任何建议或常见反模式吗？

编辑:

通过阅读您的答案并更多地思考这个问题，我想我已经意识到我在这种情况下的问题实际上是“过早设计”的问题，而不一定是“过早重构”的问题。我一直在编码过程的早期就朝着这个方向进行设计和重构而感到内疚。如果我有一点耐心来保持一定程度的设计不可知论并专注于重构干净的代码，那么我就不会走上这些设计兔子之路。

Answer 1

我实际上认为相反。

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

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

但是，如果您发现自己“重构”自己陷入困境，我认为这更多是由于缺乏初始设计或缺乏对类的使用范围的规划的问题。在开始编写代码之前尝试写出您想要如何使用类或框架 - 它可能会帮助您避免这个问题。我认为这也是测试驱动设计的一个优点 - 它可以帮助您强制自己在编写对象之前考虑使用它。

请记住，从技术上讲，重构永远不应该将您困在角落——它是在不改变类的使用方式的情况下重新设计内部结构。如果你因重构而陷入困境，这意味着你最初的设计是有缺陷的。

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