The Evil of Duplication

You have a certain feature or update you want to make to your code and you find yourself copying another person’s code or using almost the same code you have written before to create the new feature. You justify this by saying that the client cannot wait. You go ahead and push the code and it gets deployed. You hardly find time to come back and refactor that code. You make your system become more difficult to work on as you have added redundant code to your code base.

You simply leave a set of technical debt every time you think the client cannot wait for something. The idea is not to disregard the speed at which the client wants something delivered but it must not be done at the expense of destroying the foundation upon which clean and clear code has evolved. To move at a very fast pace, you need to uphold the ethics of not duplicating code. Immediately you see a set of code that looks to do almost the same thing, kindly factor it out into a single method or function and proceed with that. It is rather necessary to do so constantly to keep our code clean and clear at all time.

The art of Duplicating code seems to make the current work go fast but it is also for the moment. In the future, you spent more time understanding what the whole code was doing rather than if you had a single set of code that does it. Remember to always use the Single Responsibility Principle when writing your code. Ensure that your code solves a single problem. If your code can solve a single problem, then you could simply call up the method whenever you need it in another section of your code.

To write duplicated code is to use up more space and make the program difficult to understand for programmers who are just joining the field. Even for programmers who are familiar with the code, it takes more cognitive energy to fully understand what is going on. So when next you consider duplicating code, remember the stress it took to have the current level of clean and clear code in your project and how a poorly designed program could make it look really bad.

The problem with a good code is that it is easily corrupted with bad codes and design. Ensure that the quality of your code base is always improving rather than deteriorate. It pays to keep our code clean and clear at all times to give us a good idea of how to navigate our code base whenever we need to.

Never let the need to solve today’s problem create bigger problems for you tomorrow. It pays to solve the issue once and for all. It might not really seem like a big deal to you, but to the other developer who would continue the project tomorrow. It would mean big. The other programmer would really wish you did not write a lot of the bad code you wrote.

Even if you are not the one writing the duplicated code, but you see someone writing it, take a few moment to explain to the developer why duplicated code can be every very bad for the code base

Leave a Reply

Your email address will not be published. Required fields are marked *