我们都听说过过早优化 http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize，但是您对过早重构有何看法？您认为有这样的事情吗？这就是我的意思。
首先，阅读马丁·福勒的开创性著作“重构” http://refactoring.com/确实改变了我在编程方面的生活。
然而，我注意到的一件事是，如果我太快地开始重构类或框架，我有时会发现自己被编码到可以说的角落里。现在，我怀疑问题本身并不是真正的重构，而可能是不成熟/糟糕的设计决策/假设。
您对此问题有什么想法、见解和/或意见？您有与此问题相关的任何建议或常见反模式吗？
EDIT:
通过阅读您的答案并更多地反思这个问题，我想我已经意识到我在这种情况下的问题实际上是“过早设计”的问题，而不一定是“过早重构”的问题。我一直在编码过程的早期就朝着这个方向进行设计和重构而感到内疚。如果我有一点耐心来保持一定程度的设计不可知论并专注于重构干净的代码，这将阻止我走上这些设计兔子之路。
我实际上认为相反。
你越早开始考虑你的设计是否需要重构越好。不断重构，所以这从来都不是一个大问题。
我还发现，早期重构得越多，我就能更好地提前更清晰地编写代码。我倾向于创建较少的大型方法，并且遇到的问题也较少。
但是，如果您发现自己“重构”自己陷入困境，我认为这更多是由于缺乏初始设计或缺乏对类的使用范围的规划的问题。在开始编写代码之前尝试写出您想要如何使用类或框架 - 它可能会帮助您避免这个问题。我认为这也是测试驱动设计的优点之一——它可以帮助您强迫自己在编写对象之前考虑如何使用它。
请记住，从技术上讲，重构永远不应该让您陷入困境——它是在不改变类的使用方式的情况下重新设计内部结构。如果你因重构而陷入困境，这意味着你最初的设计是有缺陷的。
您很可能会发现，随着时间的推移，这个问题会变得越来越好。您的类和框架设计最终可能会更加灵活。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
