build, extract, refactor
Read 38 times
#refactoring
#development
#learning
Towards the midpoint of last year, I rediscovered one of the developers I found when I started my journey - Mark Tellez. I’ll admit, back then I was arrogant and didn’t take what he was doing in those old videos seriously, and then he just went off the map.
In his livestreams he’d work on either client work or a suggestion from the chat. In everything he made he kept repeating these words: ”build, extract, refactor”
He didn’t just say them, no. He’d say them and explain to us what they meant in real time…
build, extract, refactor
As developers we tend to rush to componentise things from the onset - sometimes when it’s not necessary. This is what build, extract, refactor is meant to address
build
Mark says just build it. Wherever you are in your project, build it. Make it work, don’t worry about structure. Your first and most important job is to have it built and working.
extract
As you’re building, you’re going to get to a point where things become too unruly. By this point, you should have noticed a structure forming all on its own - you didn’t have to pre-emptively create one.
It is at this point you then start creating your components using the structure that has presented itself.
refactor
After you have taken the lead from your project and created your components, then comes the time to refactor them.
”Don’t force it, the structure will reveal itself” ~ Mark Tellez
Why build, extract, refactor?
Now you could be asking yourself; “Why bother doing this? The way I’ve been making components works just fine”
You wouldn’t be wrong asking those questions at all.
But riddle me this; Have you ever been working on a project and you encounter an error that you can’t seem to figure out where exactly it’s originating from? Only for you to discover it’s from a file you componentised a while ago.
You could have avoided this by employing some elements of build, extract, refactor as you will have utilised the intrinsic structure of the project and not a pre-imposed one. Because you have let the project decide, things will have connected logically and tracing of errors is not as difficult.
Conclusion
Now I am not saying this is the be all end all way of building/structuring your projects, no. I am just presenting something you could consider…
Mark wasn’t available for the start of this year, he had family responsibilities to handle, I am grateful for all the knowledge he imparted on me the past few months.
To this day, I have not come across a developer who will answer your questions in real-time as he’s showing why one method is better than the other. One who will take a suggestion and build that suggestion as you watch.
Thank you Mark.
Thank you for reading, let’s connect!
Thank you for visiting this little corner of mine. Let’s connect on Twitter, Polywork and LinkedIn