How to convince a colleague that code duplication

问题:

A colleague of mine was implementing a new feature in a project we work on together and he did it by taking a file containing the implementation of a similar feature from the same project, creating a copy of it renaming all the global declarations and slightly modifying the implementation. So we ended up with two large files that are almost identical apart from renaming.

I tried to explain that it makes our project more difficult to maintain but he doesn't want to change anything saying that it is easier for him to program in such way and that there is no reason to fix the code if it "ain't broke".

How can I convince him that such code duplication is a bad thing?

It is related to this questions, but I am more interested in the answers targeted to a technical person (another programmer), for example a reference to an authoritative source like a book would be great. I have already tried simple arguments and haven't succeeded.

回答1:

Ask him what will he do when he finds a bug in his code. How many places will he now need to fix it in?

You can also show him the answers to this question (Why is “copy and paste” of code dangerous?).

回答2:

When he desires coffee, make him get it one sip at a time from the coffee pot instead of an entire cup. This is especially effective if he adds cream and sugar which will have to be dolled out in minuscule portions. This should illustrate how repetitive tasks are very cumbersome and tiring (like correcting 20 pieces of code rather than one).

Then, send him a link to this posting so he can see all the other people that have your back.

回答3:

There are two options here:

1. He's a rational person that simply doesn't have too much experience. In this case, you can possibly rationalize your argument, maybe by showing him a clearer example of code duplication someone else in your code. You can also find a bug in the original copy (or even better, a few bugs), and tell him now his code IS broken and he must fix it.

2. He's a stubborn ass: Then you should not waste energy on him. Go to his boss and let the boss take care of it. Some people are just like that.

While the first option is obviously much better, sometimes you don't have a choice. And if you will be the one who will eventually need to maintain his code at 3AM in the morning because some important client starts shouting on the other side of the earth - then it's definitely your problem, and your boss should handle it.

And finally, if your boss thinks you're wrong, you're probably in the wrong place.

回答4:

Give him a copy of Refactoring.

回答5:

Improve your version of the code so much that he is frustrated with jealousy, then say - if you had just linked to my code...

回答6:

Your co-worker is optimizing his short term effectiveness by sacrificing the longer term effectiveness of the organization (e.g., the rest of his co-workers as well as himself). Any changes required in the first file are likely required in the second one, but nobody will remember... and that will cause 2 cycles of find and fix, rather than one.

You could run a clone detector over the code and simply exhibit the results to his manager.

See Wikipedia on duplicate code for a list.

You can see samples of clone detecion for various languages using our CloneDR detector. It is designed to find an detect big blocks of code with consistent renames and it can show exactly what happened.

回答7:

Because when you find a bug, you need to change it in two places. Because when you want to add a new feature, you need to add it in two places.

回答8:

Appeal to your boss on technical grounds. If the boss agrees with your colleague's methods/and/or doesn't make him fix it, then there aint much you can do if appealing to reason doesn't work.

回答9:

It is not about making your friend fix this right now. It is about growing your team.

Make him realize that he is being unfair to the team & the project. If he is still not agreeing to it, get him a cup of coffee and ask him to sit by sipping it, while you could take on his keyboard and actually fix the code in front of him.

He might get ashamed and not do it next time(big win). I have used this 4 times and it has always worked!

Good luck.

回答10:

There are lots of valid reasons not to duplicate the code, but just ask... does your team want to maintain 100K lines of code (with code duplications), or 50K lines of code? It may seem code duplication at this point is minimal, which is why your coworker doesn't see the importance of DRY concept, but imagine if s/he duplicates more and more code for the next 5 years. Who is going to maintain that code? Your team? What if s/he leaves the job one day? Do your team want to maintain this crap? :) If not, then you already made a very compelling case not to duplicate the code, not to mention "more duplications" = "more prone to having more bugs in the future".

回答11:

Tell him that you never know where an application can go in a business... A simple test application can sometimes get modified over and over, and finally end up being used a lot... I've seen this often in small companies. And then, instead of starting everyting over and waste time on things that could have been fixed before, you could simply do it now, short and sweet, while it can be...

回答12:

He's probably assuming that it aint broke, and won't be. Also, the perfect is the enemy of the good. I don't think he's oblivious to the dangers of copy/paste, he just has a different assessment of the potential for error than you.

Perhaps you could break it for him, to show how easy it is. If you can't, perhaps he's right.

回答13:

If he is superior (or supervisor) to you, ask more explanations - its possible to know more about the context... maybe doesnt worth to refactor the code (maybe is a small project).

If he is equal to you, you can report to your superior, by proposing this solution (which is a better one).

If you are superior to him, just "ask" him to do your way...

回答14:

First, acknowledge that he's right: copy-paste is indeed faster now.

Then, say that the problem is the cost in the long run, and that the cost will increase because with duplication, the system isn't as well-ordered as it could be. He's introducing disorder, clutter, and the more disorder you have, the harder it is to work with a system. Applying some effort now to organize it better will (usually) pay off in the long term. It's just like keeping your desk or room organized.

This is Ivar Jakobson's idea of software entropy