Don’t travel the same road twice

By Diego | Software Practices

Oct 11

This is another post rambling about software practices, and also a very short one. My own perspective of why you should strive to write code once, and reuse elsewhere.  And how you can achieve it easily.

Over and over you will hear recommendations about this. Don’t write the same code twice. This basically means thinking a little bit about what parts of your code can be extracted as functions, classes or other chunks of code that can be called and reused from multiple places.

This is a great practice, as it will allow you not only to reuse the code, but also to keep the bugs to the lowest. A specific action on your code will be only performed in one place, so if you detect a bug there, it will be only there and not replicated among several other parts.

All sounds awesome. But this requires some habits on daily basis. The sooner you acquire these habits, the better.

You need to understand from the start that this practice will require you to spend time improving your code. In my own experience, the thought that I have to fight the most is my own eagerness to get more features or tasks done now. When you are improving your code and refactoring to not repeat certain patterns, you are not getting more done. It’s just the same stuff done differently. It’s ok to think this way because, actually, is true! Nothing new get’s done. But think again for a minute. What you are actually doing is “investing”. No new features are being coded now, but by performing this refactor, you will get a lot of benefits in the future. Less bugs, and more reuse, meaning… your coding will speed up after some cycles of these refactors.

The easiest way to start coding with this practice is to start as simple as possible. Code as you always do, but paying attention to the patterns that start to repeat. As soon as you find yourself copying and pasting blocks of code and replacing some variables here and there, you know there’s an opportunity. Don’t let that one go away! Refactor your chunk into something that you can reuse. How? In the simplest way possible. Don’t overthink it. Do try to see beyond your current use cases for the reusable code. If you find yourself overwhelmed by the simple idea of creating a reusable piece of code, something has gone wrong. This is also a point where I had problems several times in the past. Trying to create a super library to be reused in every project, every time, to deal with every possibility. That’s overdoing it! It causes more harm than good, and you will end up frustrated and going back to copy pasting.

Keep your refactors simple. They should work well for your cases, and don’t over engineer them. There will be plenty of new opportunities later for adding more flexibility and more cases to cover with your new reusable code. Refactoring for code reuse doesn’t mean you do it once to cover every case. It means you do it several times as new cases become evident. Let your code be your guide. Make your reusable code to be useful for you, now. Build it up one step at a time, and pretty soon you will have a great set of tools improving your project, and maybe several projects too.

A pretty short rambling today, most suited as a reminder for myself rather than preaching from a pedestal. Now that this post is out, I should be true to my own counsel, and follow every time the opportunity arises. You can hold me accountable now ;).

I didn’t find anything in this song to relate to this post topic, except from some words in the title… but I like it anyways. Here it goes:

 

Follow

About the Author

I’m a software engineer and work as an independent software developer and consultant. Software development is my passion. I usually find some time to write in between my work and my other interests, sports and PC gaming!