Don't overabstract the things

What if I? should we move this? should we recreate this component?

...

A few days ago, I started to build some components to a large app, and I didn't can avoid a whirl of thoughts, about what is the better approach to build my components, or what is the better way to improve the existents and why not reuse the old ones?

But I forgot one thing, we ALWAYS need a starter point.

So, my coworker said something like:

"Slow down, Fanny. We don't need overabstract the things."

The painful abstraction

Each abstraction adds benefits and costs. When we don't have a deep knowledge about the things, probably we'll pay a cost using an approach for a problem that don't exists, we cannot enjoy properly of the benefits. And this is essential to use abstractions effectively.

I was passing for a problem that is very common among developers: The premature abstraction.

Being premature

Some people talked with me about premature things, but I didn't have a complete understand about. But here's what I found in this situation, you are premature, when you add abstractions in your code, before you really understand the problem, and the possible scenarios.

My point is not say that abstract things is bad, on the contrary, but if I would follow this direction, probably I would leave the things hard to maintain, or unwieldly.

The goal of have an abstraction is to provide an easy way to use things, or fix bugs, and even thought understand the code without the need to look for specific details of implementations.

So, I'll leave here my advice: Sometimes the best thing that you need to do, is delay your abstraction, and start with a simple approach, after this, you probably will gain a better idea of what you need.

HackerNews - The cost of abstraction
Minimal Surface API
The Wet Codebase