4 Answers
4

The code has to work before it can be reused. So that implies design and (primary) function should come before consideration of code reuse.

It's good to be thinking of reuse, and reusing components you've already written. But it can sometimes be just as fast, if not faster, just to write the code and get it working. After you have solved the original problem, you can refactor the code to make it more reusable.

Sometimes I find that copy & pasting few lines of code is a better solution. Even in human language, when you wanna say a sentence you said before just with a slight variation, you'll repeat it with the variation, because it makes less trouble for anyone.

However, if your large module needs to be used in a slightly different way that it doesn't support, don't clone it just to modify few lines because it's very probable that you will want to extend the functionality that both the base and the clone share in the future. Instead, just make it configurable or export the functionality that both the base and the clone share into another module that they will both use.

This is from my experience, but still believe it can be applied and goes along the lines of what GlenH7 mentioned.

I work between 3 companies doing various projects. The companies are sisters of each other with some standard practices and work methodology, but are also unique in a lot of ways. With that said, I generally begin each project fresh and want to just get it done or show progress. Then if I run in to a scenario where I remember a piece of code or functionality that I wrote for a previous project, I'll do one of two things (time dependent):

Fastest Method
Copy the previous code from the the other project (don't have a lot of time) in to my current project.

Second-Fastest Method
Copy the previous code and place it in to a common library, then include that library in the current project (to make moving forward easier).

2b. If I make changes to the other (original) project, I'll refactor it to use the new library [but generally won't do so unless I have to re-touch that project].

Just be warned, test the heck out of the common libraries. Common libraries mean creating dependencies. Dependencies create points of failure. Although you may need something tweaked slightly for your current implementation, you don't know how it will change anything else using that library.

Why use a single implementation of something when you can have four or five that are identical? Your "fastest" method is only fastest in the very near term.
–
CalebAug 7 '12 at 19:12

@Caleb: Agreed. Never said it was elegant just that deadlines are deadlines. During a refactor I will recognize multiple projects using the same code and go through and break them out in to their own libraries. But when I need to get it out the door, copy-paste works. It also gives me flexibility to make modifications for that one project and I keep those changes in mind when I break the library out and want to make it both solid and flexible.
–
Brad ChristieAug 7 '12 at 20:25