过早重构? [英] Premature refactoring?

问题描述

我们都听说过过早优化，但您如何看待过早重构?在你看来有这样的事情吗?这就是我的意思.

We have all heard of premature optimization, but what do you think about premature refactoring? Is there any such thing in your opinion? Here is what I am getting at.

首先，阅读 Martin Fowler 的开创性著作"重构" 彻底改变了我在编程方面的生活.

First off, reading Martin Fowler's seminal work "Refactoring" quite literally changed my life in regards to programming.

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

One thing that I have noticed, however, is that if I start refactoring a class or framework too quickly, I sometimes find myself coded into a corner so-to-speak. Now, I suspect that the issue is not really refactoring per se, but maybe premature/poor design decisions/assumptions.

您对这个问题有什么想法、见解和/或意见?您对这个问题有什么建议或常见的反模式吗?

What are your thoughts, insights and/or opinions on this issue? Do you have any advice or common anti-patterns related to this issue?

通过阅读您的回答并更多地反思这个问题，我想我已经意识到我在这种情况下的问题实际上是过早的设计"问题，而不一定是过早的重构"问题.在编码过程的早期，我一直在朝着那个方向进行设计和重构而感到内疚.我的一点耐心保持一定程度的设计不可知论并专注于重构干净的代码将使我远离这些设计兔子的踪迹.

From reading your answers and reflecting on this issue more, I think I have come to the realization that my problem in this case is really an issue of "premature design" and not necessarily "premature refactoring". I have been guilty of assuming a design and refactoring in that direction to early in the coding process. A little patience on my part to maintain a level of design agnosticism and focus on refactoring towards clean code would keep me from heading down these design rabbit trails.

推荐答案

其实我的想法正好相反.

I actually think the opposite.

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

The earlier you start thinking about whether or not your design needs refactoring, the better. Refactor constantly, so it's never a large issue.

我还发现，我在早期重构得越多，我就越能在前期更干净地编写代码.我倾向于创建较少的大型方法，并且问题较少.

I've also found that the more I refactor early on, the better I've gotten about writing code more cleanly up front. I tend to create fewer large methods, and have fewer problems.

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

However, if you find yourself "refactoring" yourself into a corner, I'd expect that is more a matter of lack of initial design or lack of planning for the scope of use of a class. Try writing out how you want to use the class or framework before you start writing the code - it may help you avoid that issue. This is also I think one advantage to test driven design - it helps you force yourself to look at using your object before it's written.

记住，技术上的重构永远不应该把你锁在角落里——它是关于在不改变类的使用方式的情况下重新设计内部结构.如果您通过重构来陷害自己，则说明您的初始设计存在缺陷.

Remember, refactoring technically should NEVER lock you into a corner - it's about reworking the internals without changing how a class is used. If your trapping yourself by refactoring, it means your initial design was flawed.

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

Chances are you'll find that, over time, this issue gets better and better. Your class and framework design will probably end up more flexible.

这篇关于过早重构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！