Refactoring and Testing Your Code: ‘Find’, ‘Rewind’ and ‘DRY’ — Here’s the ‘Why’

For most software engineers, the expression ‘DRY’ is nothing new, its an acronym describing a coding methodology for optimizing and producing readable code — ‘Don’t Repeat Yourself’. However, for new programmers getting their fingertips wet, its a conceptually difficult thing to grasp, understandably so, since not many, if any, have actually had to code a “fully functioning” program before.

When you start to code, in the beginning, it's easy to rely on the good old copy and paste method we discovered from the right mouse click — ‘oh I can just use that bit of code from earlier and paste it into this part of this method and this other part of this method’. It seems simple enough, it gets the job done, and that’s a success.

However, as you begin to write more complex code, with different classes, models, and/or databases, you’ll soon realize how much code you’re actually putting onto your terminal — read the line numbers, it gets intense.

It’s completely normal in the early stages; it’s easy to get overwhelmed by the chunks of code and as you start to debug your program, you could get lost in the matrix.

Which pill will you choose, Red or Blue?

One path will take you down a convoluted route of trying to make sense of error messages, dot methods, objects, and key-words. While the other will help you view your code in a legible and organic fashion.

We’ve already been introduced to the idea of keeping your code ‘DRY’, but what if I introduced you to a method I call, ‘Find and Rewind’.

In my experience, it’s easy to become so goal-oriented while building an application (or anything really), that I skip steps or miss mistakes along the way, and before I know it, I have a semi-functional piece of work, that kinda does what it was intended to do.

What helped me was to take that goal-oriented framework and apply it to very small parts of the code that were giving me issues. Whenever I was met with an error issue, I’d find the line that it provided, take a moment to see if it looked alright, and then I’d go back a few methods — or even to the beginning of the application — to see if I could see how that error arrived, make a few adjustments, test the code, and repeat the steps until I was satisfied.

That’s the ‘Rewind’.

Even though it’s great that your program will tell you where it’s meeting the issue in your code, it doesn’t necessarily mean that's where the issue started. Taking the time to slow down and review your program could really help you in more ways than one.

Here are a few ways:

• It’ll help you familiarize yourself with the flow of data moving between your methods
• It’ll give you an opportunity to notice where different methods function or require inputs in similar methods — this is where you can refactor your code or ‘DRY’ out your code. Creating a method that will format the output that this, this, and this method require, or conversely, creating a method that will format the input for this, this, and this method will not only save up screen space, but it’ll help free up your brain from having to process what’s happening. And who knows, maybe you’ll be able to use that helper method again later down the road.
• It’ll give you a chance to test the integrity of other parts of your code. Therefore providing you insight into where there are weaknesses and where there is fidelity.
• It’ll show you where your method names are confusing. If you can’t figure out what the method does by its name, then it's likely the next person won’t either, so it's a good time to rename it — once you can figure out what it does.
• It’ll help you find that stray comma or missing keyword that threw off your code 40 lines later.

Furthermore, ‘Find and Rewind’ isn’t just a tool that can be used to find errors, but a manner in which to refactor your code. I recently realized at the end of a test that I needed to adjust the output of a helper method that I had placed in multiple methods in multiple files. It would have taken me ages and too much mental energy to properly locate where I had planted it, but luckily I realized that my VS Code had a find_method built-in.

Thank goodness.

I used this built-in function to locate each part of my code that used this method and did a ‘Rewind’ — going back to methods upstream of the methods I had isolated — and tested every stage along the way to ensure it behaved in the manner it was intended to.

And since I had refactored it earlier in the building process, it was easy, organic and streamlined my productivity, saving me time and stress.

So to wrap up the story, choose the path that will make it easier on yourself.

• ‘Find and Rewind’ — utilize the tools available to you (like your error messages and find/replace tools) to sort through and isolate areas of concern, and check the flow of information upstream to them to gain a clearer picture of where and how the issue(s) came to be. Take this time to refactor and optimize your code.
• ‘DRY’ — refactoring your work allows for fewer lines of code complicating the readability of your methods and frees up mental processing. Doing so will allow you to continue towards your goal without getting bogged down by what you already did. View similarities between methods as areas of opportunity for building methods (tools) that you’ll be able to use again and again, honing and sharpening your code’s functionality as a whole.

Although it’s easy to want to keep moving forward to the finish line, taking the time to ‘Find’, ‘Rewind’ and ‘Dry’ out your code will be incredibly rewarding, not just at the end of the road, but every step of the way.