Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Where i work, people (consultants) feel pressed to release features as fast as possible. So instead of spending too much time on thinking about how to do things the right way or because they don't want to break anything, code gets copied from different modules and modified.
It's not easy to prevent this, since the code base is open to the whole company. Lots of people work on this.
Now that the mess is there already, what is the best way to remove those redundancies without breaking too much?
One part of the answer is Refactoring.
First, start writing unit tests to ensure that you don't accidentally break anything with your changes. Then start improving the design, removing duplications etc. in small steps, running your unit tests after each step, fixing any problems if any of the tests fail, or reverting immediately if you run into a bigger problem than you can solve easily.
The other part is education.
People must be taught not to leave bad code behind. This is certainly a long term battle, as habits and thought processes are hard (sometimes even impossible) to change. However, without it, you will just continue to get an endless supply of bad code screaming to be refactored.
You may choose to do group code reviews to open discussion about good and bad coding habits, and spread the merits of the former. It is not enough to say "you must (not) write code like this", you need to convince people with logic and hard facts. Like "if you have this piece of method duplicated over the codebase n times, what do you think the chances are that if a bug is found in that method, it will be fixed in each copy of the method code?"
Your company may also need to revise the incentives and acceptance criteria for the consultants - if they can get away with writing sloppy code, they will surely keep choosing the easier path. If the company keeps valuing "fast delivery" over long term maintainability, nothing will change :-( So you may need to discuss this with management as well. One way to make them understand is this: refactoring means keeping the code clean, easy to understand and maintain. Omitting refactoring is like amassing debt on your credit card. You can get away with it for a while, but if you are not actively managing your buying habits and debts, it will inevitably crumble on your shoulders one day. In the life of a software project, bankruptcy is when the project becomes unmaintainable: it becomes easier to rewrite it from scratch than to add a new feature to the existing codebase. Or users get so fed up with the inferior level of support and features that they simply switch to the competition.
As part of education like @Peter said, you can introduce a copy & paste detector like PMD and use it as part of your build cycly to help enforce this part of your coding standards.
Make sure that your projects coding standard covers this pattern so that you have a baseline to start discussions from.
people (consultants) feel pressed to release features as fast as possible
You don't have a technical problem, you have a social problem. Indeed, you have a management problem.
It's not easy to prevent this, since the code base is open to the whole company. Lots of people work on this.
The "code base is open to the whole company" is a non-issue. Doesn't matter.
What matters is that there's a management reward system in place for copy-and-paste. The root cause is that people are rewarded (i.e., paid or praised or promoted or extended) for copy-and-paste.
You cannot break this without fundamentally changing the culture from "pressed to release features as fast as possible" to "rewarded for making the appropriate, well-tested code-base changes."
You have to
Start at the top, with the managers that reinforce the rewards. You have to expose the current practice and document the costs and risks. You have to propose an alternative that reduces costs and risks.
You have to relentlessly document and expose cost and risk for the rest of your tenure at that organization. Relentless. Fact-based. Cost and Risk. Every week more cost and more risk from copy-and-paste.
You'll have to help managers take credit the new approach which will make them look good and you will be ignored.
It's very important to reduce copy-and-paste. But it's hard to change an organization's culture. You have to provide a lot of facts and you have to make the case over and over again to manager's who don't agree with you.
I have a code base now that was starting to rot from that. I had over 10 static functions per module that were basically identical to the same static functions in other modules. Each one behaved just differently enough to warrant a new incarnation in the sake of doing things as quickly as possible.
Today, I had to add yet another feature and I just couldn't take it any more. I created a new library, combined the 100 + functions into 10 reentrant functions that slightly alter their behavior based on bit flags and then wrote a series of tests to make sure any changes to that library didn't break anything else.
Total time spent: 4 hours. I was ready to go on a 20 hour marathon if needed and was surprised at how quickly I brought a growing mess under control. As a bonus, it was easier to subsequently fix a bunch of header dependency issues. Additionally, since a lot of our proprietary stuff is now in static objects for linking, we can give our customers who get access to source code more than we did previously.
My advice: bite the bullet and re-factor that mess now before doing so really gets bad. It probably won't take as long as you think, but create a new branch for yourself just in case.
Additionally, you can still copy / paste to get features out the door while fixing the fundamental issue. When you're done, just rip out the pasted stuff and use the new library instead.
I agree with the answers given so far. You should:
But on the other hand you need to look at what causes people to copy paste and fix that.
So I think to stop the copy/paste pattern you need to make reuse easier.
read Framework Design Guidelines
Hope this helps.
There is a strong "copy paste considered harmful" attitude. I think it's good, but goes a little bit too far. Copy paste as an exercise in discovering the similarities and differences between two methods or classes - as a step in the process of triangulation - I think is healthy. But stopping short of complete triangulation - of eliminating the duplication introduced by copy paste - is indeed harmful.
If you can find ways to use that more nuanced attitude, to tell developers not "that's bad!", but rather "that's incomplete, can you work with me to complete the refactoring?", then you may find yourself holding more constructive conversations.
I'm concerned with the same problem here, and my take on it is: Don't try to avoid it upfront, just refactor when it gets too bad.
The module I'm currently working on startet as a copy of another module, now I'm changing everything that needs to be different. Once this is done, and the new module is finished, I will compare it with the original module and find out which parts are more-or-less unchanged and should be moved to a library, abstract parent class etc.
Whoever is in charge is at fault. One person can't be expected to review every line of code, but they do set the standards and the timeframes.
Contractors (or anyone who is short-term on a project) can be put into the position where they are only compensated for making it work the first time. There is some incentive to get it done ASAP. The copied code may never need to be modified and if it is it won't be by them.
You could try and force them to fix it on their own time. Then they'll start doing it from the beginning, but then take an innordinant amout of time to get things done. I think AmmoQ has the right idea of refactoring things that are causing problems.
The only way to eliminate copy/paste code is (IMHO) code reviews, have a person (or preferably more) to check through the code and when they find code that seems to be from a copy/paste action let the programmer refactor.
As suggested this is mainly an problem in the organization. Try to start by educating people (don't forget the direct management layer above your position). It helps very much to start to get one or two people on your train and let the virus spread. When the majority thinks this is a good idea get it described and try to introduce reviews to guarantee it stays this way. This is a very slow and tedious process but it just can't change fast. At first it will cost extra time so it is important management knows and supports the long term goal.
@Anders K. Reviews are a good means to keep the practice in place. When forcing people to write code they don't believe in it creates a lot of friction. They will fall back in the old habbit as soon as the can. I firmly believe you should start with education to gain momentum.
