Refactor Until You Feel Almost Comfortable

Link: Refactor Until You Feel Almost Comfortable

How do you know when you’ve refactored enough and when you’ve refactored too much? I asked Sandi Metz about this once; here is a paraphrase of her answer:

“Refactor until you feel you are one step behind the solution you want. Avoid your comfort zone. And while you might see extractions that would probably get you to a better design, don’t apply them until you see the need two or three different times. Remember that duplication is cheaper than the wrong abstraction. The best refactors will then naturally arise from the repeated inconveniences, instead of from unbacked ideas of what could potentially be better.”

The key point here: “Remember that duplication is cheaper than the wrong abstraction”.

Rewriting a class that is rarely used to make it more open for extension might be fun but very unlikely to reap benefits both in the short and the long term. Such a refactor can (and probably should) be avoided.

As Joe Ferris said in our blog post and “Ruby Science” book, extracting classes decrease the amount of complexity in each object but increases the overall complexity of the application. Extracting too many classes will create extra indirections that developers will have to navigate.

Good read. In my young age, I met a programmer that extract everything to the extreme abstract functions, which indeed is very difficult to read and use.