Why Code Clones are Dangerous?
At the first sight, code clones don’t seem dangerous. For example, if to consider the given problem from app performance testing services, clones’ impact on it just boils down to an increase in the code that causes, the so-called, end-application “bloating”. Such “bloating” faces with the additional RAM volume that is essential for the application running. If not go to extremes (when 90% of your code – are useless clones), in general, clones poorly affect the final performance of the application.
But there is also a downside: clones can adversely influence the productivity of your work as it is not strange. Let’s consider this problem from the ease of app support and development. If your application has clones, in the event of a change in functionality or bug fixes that affect work with these clones, the developer must make the same changes. If the developer knows where this event to make changes is good. And if not?
Why Do Clones Appear?
To understand this, let us understand the nature of the appearance of clones:
- If the developer possesses an “Indian” mindset, he or she causes problems for himself. This kind of developer needs to be educated.
- If the dedicated testing team works on the project. Even in cases when the work of each one clearly defined, what happens is that two developers independently write similar pieces of code.
Clones’ Impact on Productivity
Let’s imagine, the bug appeared in some app functionality, then your lead who redirects this task for you. You know that your functionality uses this file, you write edit method that works with this file, and with a sense of accomplishment are aware this hotfix on your tests. On the next day, you get test results, and you are surprised to discover that the server still experiencing errors when working with this file. It turns out that your patches are only partially solved the problem because there is a clone, which has not been fixed.
Bottom line: you lost day and bug fixed entirely.
Comments are closed.
