So… not how I started out coding!So, what is refactoring?Refactoring in software development can seem like an unnecessary step, until you have had to wade through code (that you might have written!) so bogged down with logic it is almost impossible to read or make sense of.
Refactoring this mess can take you from going down the rabbit hole every time you revisit the codebase to being able to easily understand and navigate very complex problems in a fraction of the time.
All it takes is a little bit of elbow grease and some patience.
Let’s take a look at how you might go about this.
Modularization is your friendThink of how you might begin white boarding a complex problem you don’t know how to solve yet.
As you logic through the steps of the approach, you might think “Oh this could be solved with a recursive call” or “Hey I could add this variable to my result every time”.
Instead of writing out the full code of the approach, you could write the name of a function inside your initial function called “recursiveCall” and pass it the relevant data.
This allows you to move on and “finish” the real white boarding problem by showing what you would do with the data returned from the recursive function.
If you have time, you can revisit the recursive function and define it outside of the initial problem function, creating a modularized “Helper Function”.
This is refactoring by extraction!.You are not changing the purpose or result of the function itself, you are purely breaking down the problem into smaller component parts that function on their own.
What the heck is “g(x, b, c)”, and what does it do??Have you ever come across code like this?.This is the perfect example of a small refactor task that could make your code base INFINITELY more understandable to anyone other than yourself.
Name things what they are!.Have a function that calculates the total yield of grapes in a vineyard per year?.Name the function “yearlyGrapeYield”.
Have a function that sums the number of people, animals, and vendors at a pet show?.Name it “petShowCreaturesSum(people, animals, vendors)”.
Welcome to refactoring by renaming!.As simple as that.
Hmm, I think I used that variable somewhere…I am definitely guilty of being too fast and loose with variables.
But why not??.Aren’t variables another form of clarity, to name results according to their place and purpose in the function?.Have you ever gone back and tried to follow the logic of the function only to be totally confused about the value of the mountains of variables, nonetheless understand the actual result of the function?Why not use… wait for it… NO VARIABLES.
Or at least only a few.
When necessary.
Many times, we don’t actually need variables.
We could use the actual value of the variable and it wouldn’t make the code any less readable or clear looking.
Inline variables take away a level of abstraction, creating a clearer picture of what each part of your code is doing and where it came from.
Loops in loops in loops in loopsLoops driving you loopy??.Remember that each loop does actually serve its own purpose.
The logic of understanding how each part of the loop works on its own can be determined through explaining the multi-level loop’s purpose to a rubber duck.
“Ok, duck.
I am looping through all artists in New York City to find those that deal in sculpture, and have had a show at The Noguchi Museum within the past year.
”This could look something like this:Speak this out loud to your duck.
Sounds very close to the earlier sentence doesn’t it?.Using split loop refactoring can make a complex sorting/filtering/mapping/etc.
function much easier to understand.
Ok, some of this sounds doable, but when do I refactor?Go ahead and write working code in any way that makes you happy.
Only after you have a solution should you think about how to optimize your solution for others.
That being said, if your code is littered with nonsense variable names and complex loops, it might benefit everyone if you refactor in smaller steps during each stage of a project.
One approach is to keep track of when a particular part of a program is confusing or too complex and at three strikes, it is time to refactor it.
One thing to remember after all of this…How will you know your code has been properly refactored?It still works!.Have you heard the old adage, “Commit early, commit often”?. More details