One of the more annoying aspects of working with a predecessor’s codebase is seeing cut and pasted code all over concrete implementations that can so easily be refactored into the base class implementation.  Many books tell us that refactoring upwards is a good thing for a number of obvious reasons.  Code reuse, behavioural predictability and simpler maintenance are the most often quoted.

On a recent project I have seen no less than 12 places IN THE SAME CLASS where the SAME CODE has been cut and pasted.  This suggests that the author of these unnecessary method implementations did not have a firm grasp on what the original code was doing.  Rather than make what would have been a fairly lightweight modification to the existing implementation the author chickened out and simply duplicated the code in a another method (or 10). Oh, and unit tests were nonexistent, proving that the author did not attempt to understand the existing code, properly check the existing behaviour nor modify what was there carefully. This deficiency makes matters much, much worse.

When code like this is released into production, all hell breaks loose.  As the code does not have any unit testing at all, proof of implementation was left to integration testing which is notoriously unreliable because it is very time consuming.  The end result, as has been proven by a recent release with such code was that it needed 9, yes that’s right, NINE, patches in the first month after release.  The main issue was that Defects seen were caused by subtly different implementations of each cut&paste method implementation.

The message here? DON’T DO THIS UNLESS YOU WANT TO LOOSE YOUR JOB.