Refactor not DRY: why we are not afraid of code duplication
- Development DRY News Team
The DRY (Don’t Repeat Yourself) principle is one of the cornerstones of the modern software development and the crucial part of refactoring. Unfortunately, many developers get it completely wrong.
When a new software project goes on, the codebase grows significantly over time, as the new features are added. In order to ensure maximum usability and transparency of the code, it is refactored to comply with the requirement of having the absolute minimum of functions and values needed to run it. This seems to fall in the line with the DRY principle:
“Every knowledge piece must have a single unambiguous, authoritative representation within a system.”
Note, however, that this definition does not say anything about code, even though being related specifically to the software development. It is all about KNOWLEDGE, meaning the use cases, the functions, the algorithms — not the lines of code. This makes all the difference in the world in our eyes.
We do agree that excessive duplication is unnecessary — yet we stand firm that early refactoring is rather harmful, not helpful. Even if the logic of 2 pieces of code is similar, the results they should produce are quite rarely the same, so they should not be combined. As a matter of fact, unnecessary standardization of code almost always leads to poor handling of edge cases, bad code readability or overall performance issues.
Quite the contrary, having multiple similar (yet not same) pieces of code allows for greater flexibility and provides a greater field for maneuver when the development goes on. As the codebase grows and the developers add more depth to the product features, the cases where refactoring is needed will emerge on their own, while the cases where DRYing is rather harmful will also present themselves.
This is why at IT Svit we do not emphasize the early refactoring as a rule of thumb. For example, if a project requires 400 man/hours only, devoting 50 hours to the code DRYing is obviously redundant. We refactor the code to ensure it runs well under any conditions, performs all the required functions and is modular enough to permit simple upgrades when needed. Even if there are several duplicating pieces of code we leave them be and just make sure they perform varying functions.
Final thoughts on why IT Svit does not favor DRY over functionality
Following this paradigm ensures we provide functional and clean code under budget and on time. As IT Svit is one of the top 15 managed services providers worldwide (and one of the leading IT outsourcing companies in Ukraine according to Clutch), we quite often get to support and maintain the websites and apps we develop.
Thus said, it is in our best interests to provide high-quality products, as it will be our responsibility to ensure their stable performance in production. This is why we do favor functionality over DRYing and are not afraid of code duplication when it is needed.
What’s your opinion on the topic? Did you have an experience of too intense refactoring? Please share your thoughts in the comments below, and if you need a sound project to be developed and delivered on time — contact IT Svit team, we will be glad to assist!
Feel free to browse through the latest insights and hints on the DevOps, Big Data, Machine Learning and Blockchain from IT Svit!
What if the transition to the cloud does not increase your profits?
The biggest fallacy of nowadays world is the so-called Productivity paradox, which states that the increase in investments in the IT operations does not lead to the growth of productivity.
Guide to AWS platform migration: AWS migration best practices
One of the most common tasks we perform at IT Svit is cloud migration from AWS to GCP, Azure, DigitalOcean and vice versa, or from legacy infrastructure to the cloud.
What if a company could really inspire self-development in employees?
There are tons of materials from multiple experts and gurus, who promise to teach businesses to inspire their teams, to make the employees grow and become more productive. However, their methods rarely work. Why so? We describe our vision of why conventional employee engagement practices fail, and how to really inspire the employees to self-development.
What your DevOps team will look like in 3 years
DevOps continues to gain momentum. This isn’t exactly news, as the term itself was coined about eight years ago, and prominent companies like Google, Amazon, Microsoft, and Netflix have made their share of meaningful donations to its development.